Best option to process packet ACL

Ze Claudio Pastore zclaudio at bsd.com.br
Fri May 6 23:49:23 UTC 2016


2016-05-05 3:27 GMT-03:00 Julian Elischer <julian at freebsd.org>:

> On 29/04/2016 5:21 AM, Ze Claudio Pastore wrote:
>
>> 2016-04-28 14:46 GMT-03:00 Jim Thompson <jim at netgate.com>:
>>
>> 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.
>>>>
>>> ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information but
>> on
>> a request basis not per packet, depending on other previous criteria I
>> will
>> them split the processing, I am running a proxy so I am not looking to
>> replace my ACL needs by something else, only want to discuss how to better
>> process it, I have previous information from L7 affinity, headers, request
>> which helps me split some load, now I happen to need to filter it, it's
>> not
>> a firewall, it's much like a squid based ACL need where you look for L3
>> info on a different moment, ipfw/pf won't do it for me, ordinary firewall
>> fits somethwere else in the topology not in this application.
>>
> ok so you have  a bunch of options.
> If DPDK works for you, have you looked at netmap?
>
> If you are only interested in examining the first packet and then passing
> everything to a proxy, then use ipfw fwd, with a stateful rule.
> use a table with that rule if you have a number of filtering criteria.
> use multiple table and multiple fwd destinations.
>  since we don't know what criteria, for how many rules it's hard to say..
>
>
> you could feed everything into a netgraph module attached to your
> interface and write special purpose code.


hello mr elischer

I was generally looking to discuss the best generic approach to test the
acl match criterias taking best benefit on more CPUs
as I mentioned I am looking for tipical L3 information but on a L7 payload,
per request before I apply other application based criterias like headers,
x-forwarded-for, etc, I know it looks like I need a firewall but it's in a
different moment, a different application, that's why I'm interested on a
discussion on how to best match ACL criterias and how to share the load
among cpus

denis suggested some stuff I am trying and measuring the performance
benefits vs workload added, i'm still working on some numbers i'll share
later

i already have a typical networking firewall with ipfw in front of the
environment, in a different box, but know i really need to match acls based
on application needs not simple/plain network needs anymore, pretty much
like a squid L3 based acl, but squid does not bring multithreaded
suggestions for acl, I found several discussions on how people use external
acl hooks to benefit performance so no good code examples there too

i think if we keep the conversation in the usual firewall subject, my
question would be what if I wanted ipfw to be multithreaded, how to do
this? is the current approach the best one? does ipfw/pf/iptables works
like mr denis mentioned it looks like, based on interrupt on multithreaded
network drivers?

say, like, if I run a monothreaded network NIC like rl(4) or vr(4) no
matter if I have 1 or 36 CPUs, kernel based firewall will only benefit from
1, that's correct? what if I wanted to make it multithreaded, would I
thread batches of rules? thread per packet? thread per match criteria?
thread somehow else? not to thread? thread by other criteria?

that is the discussion i tried to promote

:)


More information about the freebsd-hackers mailing list