LWN: Comments on "vringfd()"

vringfd()

jzbiciak — Mon, 14 Apr 2008 20:36:00 +0000

The text makes it sound like poll() blocks unconditionally.  Is that the case in general with
this interface, or (as is normally the case) just an option if you set a non-zero timeout?

wrong article!

astrophoenix — Mon, 14 Apr 2008 19:37:26 +0000

I was trying to reply to the syncookies article, not this one. sorry.

hashed?

astrophoenix — Mon, 14 Apr 2008 19:36:23 +0000

forgive me if I sound ignorant, but this sentence doesn't make sense to 
me:

"This encoded information is cryptographically hashed with a secret key 
to form the sequence number of the SYN-ACK and sent to the client."

Shouldn't it read something like "encrypted with a secret key", rather 
than "cryptographically hashed with a secret key"? I was thinking if it 
was hashed, the kernel wouldn't be able to decode it when the ack comes 
in.

vringfd()

aliguori — Sat, 12 Apr 2008 21:54:19 +0000

The immediate use-case is to allow a high performance virtual network device backend to be
implemented in userspace for KVM.

In general, it's just a standardized ring queue between kernel and userspace.  Ring queues are
lock-less and efficient when shared between two CPUs.  They are good at batching and
implementing zero-copy IO.

vringfd() will be most immediately useful for tun/tap users.  Of course, it's easy to envision
a vringfd() interface for block IO.

vringfd()

liljencrantz — Fri, 11 Apr 2008 07:54:20 +0000

Am I correct in assuming that the point of this interface is to allow for fast, zero copy data
transmition between kernel and userspace? What are the use cases for it? A new, faster type of
IPC? FUSE modules with nearly the same performance as in-kernel filesystems? Making it
possible to move parts of the network stack to userspace?