Messages in this thread | | | Date | Fri, 10 Oct 2003 10:41:29 -0400 | From | Karim Yaghmour <> | Subject | Re: [PATCH][RFC] relayfs (1/4) (Documentation) |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |