Scope for porting to network processors

Posted Mar 25, 2009 2:37 UTC (Wed) by alex (subscriber, #1355)
Parent article: Nftables: a new packet filtering engine

This is certainly an interesting approach. I wonder what sort of scope
there would be for porting the virtual nftables code to a network
processor? A lot of high end networking hardware works with custom
networking processors (CPU's tuned to packet inspection/direction).

On a slightly un-related note is the nftables VM sufficient enough to
replicate traffic shaping functionality?

Scope for porting to network processors

Posted Mar 25, 2009 3:32 UTC (Wed) by kaber (guest, #18366) [Link] (4 responses)

I intend to add support to use it for TC classification. But it won't do shaping itself, the classifiers will be attached to qdisc classes as today.

Traffic shaping

Posted Mar 26, 2009 20:27 UTC (Thu) by dion (guest, #2764) [Link] (3 responses)

Linux traffic shaping is a complete disaster area, anything that can be done to get it under some sort of control is good.

I've had the displeasure of having to set up traffic shaping on a couple of occasions and every time I had to read tons of incomplete documentation and outdated documentation.

I realize that there's always the danger of designing something like this to death, but it would be very cool if a proper, userfiendly integration with traffic shaping could be baked in this time around, the gulf between tc and iptables has been a an absolute catastrophe wrt. usability, mindshare and documentation.

Traffic shaping

Posted Mar 27, 2009 18:35 UTC (Fri) by kaber (guest, #18366) [Link] (2 responses)

Yes, I really want to have something useable for both myself.

I agree on the "designing to death" risk, but this is something that affects the API and because of that needs to be considered from the beginning. I'm about to finish the second-to-last missing part of the API (an API for maintaining sets independently of rules), hooking it up to TC will be the next and probably last bigger part.

Traffic shaping

Posted Mar 27, 2009 23:37 UTC (Fri) by rmayr (subscriber, #16880) [Link] (1 responses)

And please, please, *please* hook into ingress shaping as well. Yes, IMQ had bad code
quality, but it was understandable from a user point of view. IFB isn't and it doesn't work in
many cases important in practical scenarios. I have been dealing with ingress shaping for
the past 2 years and managed to get many Linux gateways deployed because of the
flexibility that combining netfilter marks with IMQ gave me. IFB so far doesn't seem to be a
capable replacement, and IMQ is broken with >= 2.6.27.

Traffic shaping is becoming more important by the month. It's time to let it become
manageable under Linux.

Traffic shaping

Posted Mar 28, 2009 13:25 UTC (Sat) by dion (guest, #2764) [Link]

I'd *so* like to second that! I've had the displeasure of having to do downstream traffic shaping systems with several downward interfaces and that means having to deal with an IFB interface or the silly limitations Linux has on ingress shaping at the moment.

Why is it that I can't simply pipe traffic via a queue from any arbitrary firewall rule?

Scope for porting to network processors

Posted Mar 26, 2009 0:05 UTC (Thu) by Thalience (subscriber, #4217) [Link] (1 responses)

The difficulty of running the nftables VM on a specialized filtering processor would depend entirely on what is the native instruction set for said processor.

Scope for porting to network processors

Posted Mar 28, 2009 20:03 UTC (Sat) by jzbiciak (guest, #5246) [Link]

It'd probably be more interesting to try to cross compile to the native instructions of such a processor.