Date: Thu, 28 Apr 2016 08:50:59 -0600 From: Alan Somers <asomers@freebsd.org> To: =?UTF-8?Q?Z=C3=A9_Claudio_Pastore?= <zclaudio@bsd.com.br> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Best option to process packet ACL Message-ID: <CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA@mail.gmail.com> In-Reply-To: <CAEGk6G4aMU_qxDMb3tBqyLNmUNqd3%2BRjDRZ29wMx7pK_w=kkJg@mail.gmail.com> References: <CAEGk6G4aMU_qxDMb3tBqyLNmUNqd3%2BRjDRZ29wMx7pK_w=kkJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore <zclaudio@bsd.com.= br> wrote: > Hello everyone, > > I would like to hear your suggestion regarding the best approach to proce= ss > 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) > > My current rate of requests per second is high, around 200K. I have no id= ea > 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. > > I have implemented it serial today (not threaded) and I get 40% performan= ce > loss. I will handle max 128 filter rules, this is a decision which is mad= e. > This is going to be first match wins. > > 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 processi= ng > that rule and go to the next, and tell all other threads to die/exit sinc= e > 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. > > 4) Other suggestion? > > This is going to run FreeBSD 11, I use libevent2 on the current applicati= on > so far. > > Thanks. > _______________________________________________ > > Is there some reason why you can't simply use pf or ipfw? ipfw can do everything you described. pf can do most of it, but I'm not sure if pf can filter on iplen. If I were you, I wouldn't attempt to write my own userland firewall until I was absolutely sure that neither pf nor ipfw would work. If that's the case, then I would try using diverter sockets. With a diverter socket, pf or ipfw does most of the work, but when it encounters a packet it can't process it pushes it up to a userland helper. The userland helper processes the packet and then tells pf or ipfw what to do with it. In realistic applications, pf or ipfw also creates a temporary rule based on the userland helper's decision. Applying the temporary rule in the future is far faster than invoking the userland helper. After a certain amount of time, the temporary rule will expire again. Here's an example in action: http://daemonforums.org/showthread.php?t=3D8846 -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA>