Re: [PATCH][RFC] relayfs (1/4) (Documentation)

[Karim Yaghmour <karim@opersys.com>]

David S. Miller wrote:
> Of course it can.  Look, netlink is used on routers to transfer
> hundreds of thousands of routing table entries in one fell swoop
> between a user process and the kernel every time the next hop Cisco
> has a BGP routing flap.
> 
> If you must have "enterprise wide client server" performance, we can
> add mmap() support to netlink sockets just like AF_PACKET sockets support
> such a thing.  But I _really_ doubt you need this and unlike netlink sockets
> relayfs has no queueing model, whereas not only does netlink have one it's
> been tested in real life.
> 
> You guys are really out of your mind if you don't just take the netlink
> printk thing I did months ago and just run with it.  When someone first
> told showed me this relayfs thing, I nearly passed out in disbelief that
> people are still even considering non-netlink solutions.

Well, it wouldn't be the first time I've been called crazy on this mailing
list, and it certainly wouldn't be the first time my craziness has had some
some ill effects on others ... ;)

But let's get to real stuff here.

The question isn't whether netlink can transfer hundreds of thousands of
data units in one fell swoop. The question is: is it more efficient than
relayfs at this? I contend that it isn't. Transferring hundreds of
thousands of data units is one thing, being able to sustain tens of
thousands of data units per second, doing it continuously for hours while
still having all this data committed to disk is a completely different story.

In addition, consider that a user may want to disable networking in his
kernel entirely and still want to be able to transfer huge amounts of
data from kernel space to user space. So is that user going to just have
to live with the old printk just because he doesn't want to have
networking? The fact is relayfs is a best-of-breed buffering mechanism
which can replace many ad-hoc buffering mechanisms already in the kernel.
And contrary to Netlink, it doesn't need to drag with it a huge subsystem
for it to work. It's simple, small, elegant, and uses an API which is
consistent what you'd expect from a buffering mechanism. This includes
callbacks for key conditions that you'd expect to have from a buffering
mechanism: buffer start (for N buffering), buffer end, delivery, resize
needed.

Heck, I can even log one entry in a relayfs buffer for every kmalloc,
alloc_skb, netlink_sndmsg, etc. without my transmission being recursive.
Fact is, relayfs' dependencies on other kernel facilities are lower than
netlink.

Finally, if you think that "mmap" is really unnecessary for what we're
trying to do, then I suggest you try porting something as demanding as
LTT on netlink and show us some numbers. Not to mention that by porting
LTT onto an netlink you'd then be unable to trace some portions of the
networking code ...

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145