Date: Thu, 28 Apr 2016 12:46:46 -0500 From: Jim Thompson <jim@netgate.com> To: Alan Somers <asomers@freebsd.org> Cc: Ze Claudio Pastore <zclaudio@bsd.com.br>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Best option to process packet ACL Message-ID: <D638A558-15C0-4834-868C-D0912F225444@netgate.com> In-Reply-To: <CAOtMX2iKF2aaWF_PQESewMUFW4q=s3KC%2BJCEX7eakN3GKJ%2BEog@mail.gmail.com> References: <CAEGk6G4aMU_qxDMb3tBqyLNmUNqd3%2BRjDRZ29wMx7pK_w=kkJg@mail.gmail.com> <CAOtMX2h8tRtGeTLageLWiiXAi-Ap4Q8jqWFD2uiCtF1uCzSmOA@mail.gmail.com> <CAEGk6G6uy0n8VEY1qtH8x%2B%2Bh7523YYyWLwNwrMq4O36s33o0-g@mail.gmail.com> <CAOtMX2iKF2aaWF_PQESewMUFW4q=s3KC%2BJCEX7eakN3GKJ%2BEog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If your application is already using DPDK then: 1) it=E2=80=99s not =E2=80=9Cmostly bypassing the kernel=E2=80=9D, it = *is* bypassing the kernel. 2) ACLs are already a thing in DPDK: = http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html 200Kpps is not a lot of load for even =E2=80=98pf=E2=80=99 on slow = hardware. > On Apr 28, 2016, at 12:35 PM, Alan Somers <asomers@freebsd.org> wrote: >=20 > 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. >=20 > 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. >=20 > Good luck, you've got a lot of work ahead of you. >=20 > On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore = <zclaudio@bsd.com.br> > wrote: >=20 >> Because actually, this is ot a packet firewall. >>=20 >> When I mentioned pf/ipfw is only to reffer to ideas on how to best = match >> each acl criteria. >>=20 >> 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. >>=20 >>=20 >>=20 >> 2016-04-28 11:50 GMT-03:00 Alan Somers <asomers@freebsd.org>: >>=20 >>> On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore = <zclaudio@bsd.com.br> >>> wrote: >>>=20 >>>> Hello everyone, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> I need to implement a simple set of stateless filtering, I will = process >>>> only: >>>>=20 >>>> - src-ip >>>> - dst-ip >>>> - src-port >>>> - dst-port >>>> - iplen >>>> - proto (tcp/udp/other) >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> My current plans are to test: >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 4) Other suggestion? >>>>=20 >>>> This is going to run FreeBSD 11, I use libevent2 on the current >>>> application >>>> so far. >>>>=20 >>>> Thanks. >>>> _______________________________________________ >>>>=20 >>>>=20 >>> 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. >>>=20 >>>=20 >>> Here's an example in action: >>> http://daemonforums.org/showthread.php?t=3D8846 >>>=20 >>> -Alan >>>=20 >>=20 >>=20 > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D638A558-15C0-4834-868C-D0912F225444>