lkml.org 
[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:0.027 / U:60.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site