Reconsidering network channels [LWN.net]

Reconsidering network channels

Posted Jul 27, 2006 13:48 UTC (Thu) by cventers (subscriber, #31465) [Link]

If someone's prepared to offer up a well-tested alternative to netfilter
that supports all netfilter does (and maybe more), and that will work in
a new netchannel framework, then perhaps one barrier will be removed.

But netfilter is a _long_ way from obscure; particularly, think of all of
the SOHO routers out there and you end up counting a _lot_ of netfilter
users.

But offer a "fast path?"

Posted Jul 27, 2006 17:32 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

I think the point to which the original poster here may have been referring is that allowing netfilter design considerations to dictate the availability
of some optional "fast path" code might not be the best strategy.

Many systems are dedicated to very narrow purposes (and put into an
infrastructure which guarantees that only certain classes of packets will
reach them. (Think of systems arrayed behind a load-balancer).

In those cases it might be appropriate to have a netchannels option to offer the fastest processing of that traffic. Essentially the "classifier" has been scaled out to a different system entirely (the load balancer).

Reconsidering network channels

Posted Jul 28, 2006 18:39 UTC (Fri) by PlaguedByPenguins (subscriber, #3577) [Link]

some people already want a total absence of anything like netfilter.
by this I don't just mean being able to turn it off in .config, but also that netfilter requirements do not impact upon the structure of the driver and hence the speed of the NIC.

as people in netdev mentioned (more in the RDMA threads than netchannels), nobody in their right mind would ever dream of using netfilter on their sub 10microsecond cluster interconnects.
so users are already split into two camps - those who want to use fast hardware, and those with gigE and slower who might want to do routing and netfiltering. as low latency hardware like Infiniband and Myrinet goes more mainstream this split will become more evident.

if netchannels can only be architected so that it's usefully fast when netfilter isn't required then that's more than fine for the whole class of users who already turn off netfilter. it can go into the kernel so that netchannels only appears when netfilter is off, and people who care about performance (like me) would probably use it.
anybody who turns off netfilter in the .config already knows what they are doing and what they are losing when they do it.

as netfilter already can be turned off it follows that you should be able to write drivers and infrastructure that only works when netfilter is off. I don't see a problem with this... ???

cheers,
robin