LPC: Making the net go faster (Briefly: user-space network queues) [LWN.net]

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Sep 15, 2011 16:15 UTC (Thu) by mjthayer (guest, #39183)
Parent article: LPC: Making the net go faster

From the article:
> There are numerous details to be dealt with, including the usual hangups for the channels idea: firewall processing and such.

I am a networking ignoramus, so please excuse the following if necessary. I thought though that firewalling normally involves taking a decision about whether to allow or forbid a particular connection as a whole. Can't the packet sequence for a particular connection simply be assigned to a particular user-space buffer after (if) that connection has been allowed?

to post comments

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Sep 15, 2011 17:14 UTC (Thu) by appie (guest, #34002) [Link] (1 responses)

The idea behind network channels is to push (packet) processing out of the kernel towards the application. Over simplified: a direct pipe between incoming packets at the hardware level and the application. Packet processing won't be done by the kernel (again, oversimplified), hence no firewall checks.
Firewalls would have to be implemented in user space, in e.g. a library, every application connecting tot a network channel would need to link to that library and explicitly do it's own firewalling.

Also see: Van Jacobson's network channels

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Sep 23, 2011 13:26 UTC (Fri) by slashdot (guest, #22014) [Link]

Then put the firewall in the hardware too.

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Sep 15, 2011 23:00 UTC (Thu) by skitching (guest, #36856) [Link] (2 responses)

There are two types of firewalling: plain address/port checks that are applied when a connection is opened, and "stateful firewalling" where the actual data stream is inspected.

Stateful firewalls can do things like allow HTTP GET/PUT operations, but block other HTTP methods. Sadly, the corporate email at my current employer does this, which prevents all subversion access to external subversion repositories :-(. However it can be useful.

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Sep 16, 2011 9:09 UTC (Fri) by mjthayer (guest, #39183) [Link]

> There are two types of firewalling: plain address/port checks that are applied when a connection is opened, and "stateful firewalling" where the actual data stream is inspected.

I agree, that sort of firewall cannot be implemented by just allowing or disallowing connections when they are first made. If you don't want an additional data copy it might work if the card is writing to a shared memory buffer which is only made available to the application once the firewall has given the green light. That would slow things down quite a bit, but I think if you want to inspect data that closely you have to live with that anyway (or use an external firewall). Having the receiver process itself doing the inspection as suggested by appie above [1] is probably not really an option here, as this sort of firewall is most likely there to stop the user doing things they may want to do but you (for some value of you) don't.

[1] http://lwn.net/Articles/459118/

LPC: Making the net go faster (Briefly: user-space network queues)

Posted Jan 6, 2012 20:41 UTC (Fri) by whacker (subscriber, #55546) [Link]

> Sadly, the corporate email at my current employer does this, which prevents all subversion access to external subversion repositories :-(. However it can be useful.

This sort of thing is likely being done by a http proxy in userspace than a stateful firewall in the kernel.