Best option to process packet ACL

[Jim Thompson]

If your application is already using DPDK then:

1) it’s not “mostly bypassing the kernel”, 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 ‘pf’ on slow hardware.

> On Apr 28, 2016, at 12:35 PM, Alan Somers <asomers at freebsd.org> wrote:
> 
> 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 at 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 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 at freebsd.org>:
>> 
>>> On Wed, Apr 27, 2016 at 1:21 PM, Zé Claudio Pastore <zclaudio at bsd.com.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
>>>> 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.
>>>> 
>>>> 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 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=8846
>>> 
>>> -Alan
>>> 
>> 
>> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"