From owner-freebsd-hackers@freebsd.org Thu May 5 06:20:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B59B2E59F for ; Thu, 5 May 2016 06:20:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A464A1CE4 for ; Thu, 5 May 2016 06:20:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u456KrKo098900 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 23:20:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Best option to process packet ACL To: =?UTF-8?Q?Z=c3=a9_Claudio_Pastore?= , freebsd-hackers@freebsd.org References: From: Julian Elischer Message-ID: Date: Thu, 5 May 2016 14:20:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 06:20:59 -0000 On 28/04/2016 3:21 AM, Zé Claudio Pastore wrote: > Hello everyone, > > I would like to hear your suggestion regarding the best approach to process > IP packets for filtering, in such a way I can avoid lowering my pps rate. > > Today a have a simple application proxies http application. It's dual > threaded on a 4 core system with low CPU power. The current application > uses two threads, one for control and one for data flow processing. > > I need to implement a simple set of stateless filtering, I will process > only: > > - src-ip > - dst-ip > - src-port > - dst-port > - iplen > - proto (tcp/udp/other) why does a simple firewall not suffice? you say in another email, that you are more like a proxy.. then why not use the proxy support? (ipfw fwd) you are being a little secretive about this so it's hard to tell you what to do except that there are SO MANY ways of doing things with networking in FreeBSD that there will probably be several answers. > > My current rate of requests per second is high, around 200K. I have no idea > how I can leverage the IDLE CPUs the best way to implement this ACL > filtering trying not to impact on the pps rate I have today. 200k is not that high unless you are running on a Raspberry-pi. > I have implemented it serial today (not threaded) and I get 40% performance > loss. I will handle max 128 filter rules, this is a decision which is made. > This is going to be first match wins. so what's wrong with a firewall? > > My current plans are to test: > > 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip, > etc) the first thread that returns false to parent thread I stop processing > that rule and go to the next, and tell all other threads to die/exit since > they don't matter anymore. > > 2) Create one thread to process a batch of rules, say, 8 rules per thread > per request. Don't know if I would limit total number of threads and lock > requests while threads ar e busy. > > 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done, > how multithreaded it is and what is done on each thread. you could do prepossessing with ipfw and the 'divert' facility feeding to a user process. you could use netgraph in about a dozen ways (writing your own module would be trivial, there are already about 50 to chose from as examples (not to mention the "sample" module). you could do preprocessing with pcap and use that interface. you could use netmap and have the packets turn up in your memory for examination. will you be looking at a subset of packets through an interface or everything on an interface? > > 4) Other suggestion? > > This is going to run FreeBSD 11, I use libevent2 on the current application > so far. need more information. also probably better in freebsd-net@ > > Thanks. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >