LWN: Comments on "LPC: Making the net go faster"

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

whacker — Fri, 06 Jan 2012 20:41:05 +0000

> 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.

LPC: Making the net go faster

realbright — Mon, 19 Dec 2011 03:05:01 +0000

Regarding unetq,
I think, we have already got a well-made infra. For packet hooking called netfilter.
Which will be a winner? Kernel module netfilter or unetq?

LPC: Making the net go faster

Lennie — Fri, 18 Nov 2011 21:47:08 +0000

I think it might be this page ?:

https://code.google.com/p/kernel/wiki/ProjectUnetq

LPC: Making the net go faster

andika — Mon, 03 Oct 2011 11:00:04 +0000

http://code.google.com/p/kernel/wiki/unetq

Page "unetq" Not Found

Select an existing page from the project's list.

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

slashdot — Fri, 23 Sep 2011 13:26:54 +0000

Then put the firewall in the hardware too.

LPC: Making the net go faster

dbarv — Sat, 17 Sep 2011 17:01:05 +0000

TCP fast open seems to reinvent T/TCP (http://en.wikipedia.org/wiki/T/TCP). Maybe the related security problems will be avoided...

Already available in the kernel: See IBverbs API

clameter — Fri, 16 Sep 2011 15:21:46 +0000

The IBverbs API implements something along the lines discussed here and it works with several Ethernet NICs as well.

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

mjthayer — Fri, 16 Sep 2011 09:09:09 +0000

> 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)

skitching — Thu, 15 Sep 2011 23:00:42 +0000

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)

appie — Thu, 15 Sep 2011 17:14:44 +0000

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)

mjthayer — Thu, 15 Sep 2011 16:15:47 +0000

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?