Date: Thu, 28 Apr 2016 11:35:11 -0600 From: Alan Somers <asomers@freebsd.org> To: Ze 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: <CAOtMX2iKF2aaWF_PQESewMUFW4q=s3KC%2BJCEX7eakN3GKJ%2BEog@mail.gmail.com> In-Reply-To: <CAEGk6G6uy0n8VEY1qtH8x%2B%2Bh7523YYyWLwNwrMq4O36s33o0-g@mail.gmail.com> References: <CAEGk6G4aMU_qxDMb3tBqyLNmUNqd3%2BRjDRZ29wMx7pK_w=kkJg@mail.gmail.com> <CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA@mail.gmail.com> <CAEGk6G6uy0n8VEY1qtH8x%2B%2Bh7523YYyWLwNwrMq4O36s33o0-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Even if your application is not a traditional firewall, using pf or ipfw would save much development time compared to writing your own packet filter. They can be configured to do things like redirect packets to different ports. You can use that to offload packet filtering from your application to the firewall, and open multiple sockets in your application to receive prefiltered packets. Of course, pf/ipfw can't be used in combination with DPDK, as you discovered. Doesn't DPDK provide access to each queue of a multiqueue NIC? If so, you can create multiple filtering threads, and associate each thread to a single queue of your NIC. Good luck, you've got a lot of work ahead of you. On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore <zclaudio@bsd.com.br> wrote: > 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 withi= n > 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.c= om.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 rat= e. >>> >>> 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 >>> since >>> they don't matter anymore. >>> >>> 2) Create one thread to process a batch of rules, say, 8 rules per thre= ad >>> per request. Don't know if I would limit total number of threads and lo= ck >>> requests while threads ar e busy. >>> >>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's don= e, >>> 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 = 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 helpe= r. >> 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 tempor= ary >> rule based on the userland helper's decision. Applying the temporary ru= le >> 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?CAOtMX2iKF2aaWF_PQESewMUFW4q=s3KC%2BJCEX7eakN3GKJ%2BEog>