
The kernel connection multiplexer - signa11
http://lwn.net/Articles/657999/
======
rwmj
Like a lot of the comments on LWN, I'm having a hard time understanding why
this should go in the kernel, instead of just being a simple userspace
library. There doesn't even seem to be a performance argument for it, since
any userspace library can use iovecs to combine headers and messages to avoid
multiple system calls.

~~~
jws
At a glance, it seems like delivering a message to one of a pool of waiting
processes would be difficult to do in a library. If the process reads a large
swath of data it may get multiple messages and a fragment. If it reads a
fraction of a message then another process might steal the next few bytes.
You'd either end up with a reader lock and small reads to not read past the
first message, or introducing a demuxing process and doubling your work.

In the single process case there is also a potential performance win by not
waking processes to deliver a partial message only to have the process block
awaiting the rest.

------
aexaey
That sounds way over-engineered: Custom protocol-aware BPFs... why???

Why not just use the TCP "push" flag that is added exactly once per
application-level message on sender side; and on receiver side, buffer in-
kernel until "push" is encountered?

