Date: Thu, 28 Apr 2016 14:20:02 -0300 From: Ze Claudio Pastore <zclaudio@bsd.com.br> To: Alan Somers <asomers@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Best option to process packet ACL Message-ID: <CAEGk6G6uy0n8VEY1qtH8x%2B%2Bh7523YYyWLwNwrMq4O36s33o0-g@mail.gmail.com> In-Reply-To: <CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA@mail.gmail.com> References: <CAEGk6G4aMU_qxDMb3tBqyLNmUNqd3%2BRjDRZ29wMx7pK_w=kkJg@mail.gmail.com> <CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Because actually, this is ot a packet firewall. When I mentioned pf/ipfw is only to reffer to ideas on how to best match each acl criteria. But my userland application is a proxy, ACL will handle L7 requests within the packets. I will filter based on the mentioned criteria but it will be processed at a different moment unrelated to packet in kernel. It's also DPDK enabled so it's mostly skipping the whole kernel. 2016-04-28 11:50 GMT-03:00 Alan Somers <asomers@freebsd.org>: > On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore <zclaudio@bsd.co= m.br> > 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) >> >> 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. >> >> 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. >> >> 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 sin= ce >> they don't matter anymore. >> >> 2) Create one thread to process a batch of rules, say, 8 rules per threa= d >> per request. Don't know if I would limit total number of threads and loc= k >> 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 >> application >> 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 c= an > 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 t= o > do with it. In realistic applications, pf or ipfw also creates a tempora= ry > rule based on the userland helper's decision. Applying the temporary rul= e > 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?CAEGk6G6uy0n8VEY1qtH8x%2B%2Bh7523YYyWLwNwrMq4O36s33o0-g>