[PATCH 0/5] High-speed tun receive and xmit - Kernel

This is a discussion on [PATCH 0/5] High-speed tun receive and xmit - Kernel ; > So I think it would be good to plonk the proposed interface on the table > and have a poke at it. Is it compat-safe? Is it extensible in a > backward-compatible fashion? Are there future-safe changes we should ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: [PATCH 0/5] High-speed tun receive and xmit

  1. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    > So I think it would be good to plonk the proposed interface on the table
    > and have a poke at it. Is it compat-safe? Is it extensible in a
    > backward-compatible fashion? Are there future-safe changes we should make
    > to it? Can Michael Kerrisk understand, review and document it? etc.
    >
    > You know what I'm saying What is the proposed interface?


    So, I'm not Michael, but I *did* make an attempt to document this
    interface - user and kernel sides - so that it could be more easily
    understood:

    http://lwn.net/Articles/276856/

    That was the previous posting, but a quick look suggests it hasn't
    changed *that* much in this round.

    jon
    --
    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/

  2. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    On Saturday 19 April 2008 20:22:15 Evgeniy Polyakov wrote:
    > Hi.
    >
    > On Fri, Apr 18, 2008 at 02:39:48PM +1000, Rusty Russell

    (rusty@rustcorp.com.au) wrote:
    > > +int vring_get_buffer(struct vring_info *vr,
    > > + struct iovec *in_iov,
    > > + unsigned int *num_in, unsigned long *in_len,
    > > + struct iovec *out_iov,
    > > + unsigned int *num_out, unsigned long *out_len)
    > > +{
    > > + unsigned int i, in = 0, out = 0;
    > > + unsigned long dummy;
    > > + u16 avail, last_avail, head;
    > > + struct vring_desc d;

    >
    > Should this whole function and vring_used_buffer() be protected with
    > vr->lock mutex?


    No; it's up to the caller to make sure that they are serialized. In the case
    of tun that happens naturally.

    There are two reasons not to grab the lock. It turns out that if we tried to
    lock here, we'd deadlock, since the callbacks are called under the lock.
    Secondly, it's possible to implement an atomic vring_used_buffer variant,
    which could fail: this would avoid using the thread most of the time.

    Hope that helps,
    Rusty.
    --
    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/

  3. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    On Sun, Apr 20, 2008 at 02:05:31AM +1000, Rusty Russell (rusty@rustcorp.com.au) wrote:
    > > Should this whole function and vring_used_buffer() be protected with
    > > vr->lock mutex?

    >
    > No; it's up to the caller to make sure that they are serialized. In the case
    > of tun that happens naturally.
    >
    > There are two reasons not to grab the lock. It turns out that if we tried to
    > lock here, we'd deadlock, since the callbacks are called under the lock.
    > Secondly, it's possible to implement an atomic vring_used_buffer variant,
    > which could fail: this would avoid using the thread most of the time.


    Yep, I decided that too. But it limits its usage to tun only or any
    other system where only single thread picks up results, so no generic
    userspace ring buffers?

    --
    Evgeniy Polyakov
    --
    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/

  4. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    On Saturday 19 April 2008 05:38:50 Michael Kerrisk wrote:
    > On 4/18/08, Andrew Morton wrote:
    > > This is may be our third high-bandwidth user/kernel interface to
    > > transport bulk data ("hbukittbd") which was implemented because its
    > > predecessors weren't quite right. In a year or two's time someone else
    > > will need a hbukittbd and will find that the existing three aren't quite
    > > right and will give us another one. One day we need to stop doing this
    > >


    If only there were some kind of, I don't know... summit... for kernel
    people...

    > > It could be that this person will look at Rusty's hbukittbd and find
    > > that it _could_ be tweaked to do what he wants, but it's already shipping
    > > and it's part of the kernel API and hence can't be made to do what he
    > > wants.


    Indeed. I marked it experimental because of these questions (ie. it's not yet
    kernel ABI). Getting everyone's attention is hard tho, so I figured we put
    it in as a device and moving to a syscall if and when we feel it's ready.

    > > So I think it would be good to plonk the proposed interface on the table
    > > and have a poke at it. Is it compat-safe? Is it extensible in a
    > > backward-compatible fashion? Are there future-safe changes we should
    > > make to it? Can Michael Kerrisk understand, review and document it?
    > > etc.

    >
    > Well, it helps if he's CCed....


    It is compat safe, and we've already extended it once, so I'm reasonably happy
    so far. If it were a syscall I'd add a flags arg, for the device it'd be an
    ioctl. Starting with the virtio ABI seemed a reasonable first step, because
    *we* can use this today even if noone else does.

    > I'm happy to work *with someone* on the documentation (pointless to do
    > it on my own -- how do I know what Rusty's *intended* behavior for the
    > interface is), and review, and testing.


    Document coming up...
    Rusty.
    --
    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/

  5. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    On Sunday 20 April 2008 02:33:22 Evgeniy Polyakov wrote:
    > On Sun, Apr 20, 2008 at 02:05:31AM +1000, Rusty Russell

    (rusty@rustcorp.com.au) wrote:
    > > There are two reasons not to grab the lock. It turns out that if we
    > > tried to lock here, we'd deadlock, since the callbacks are called under
    > > the lock. Secondly, it's possible to implement an atomic
    > > vring_used_buffer variant, which could fail: this would avoid using the
    > > thread most of the time.

    >
    > Yep, I decided that too. But it limits its usage to tun only or any
    > other system where only single thread picks up results, so no generic
    > userspace ring buffers?


    I don't think so, it just externalizes the locking. The mutex protects the
    attaching and detaching of the ops structure, some other lock or code
    protects simultenous kernel ring accesses.

    Cheers,
    Rusty.
    --
    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/

  6. Re: [PATCH 5/5] tun: vringfd xmit support.

    > On Sun, 20 Apr 2008 00:41:43 +1000 Rusty Russell wrote:
    > On Saturday 19 April 2008 05:06:34 Andrew Morton wrote:
    > > On Sat, 19 Apr 2008 01:15:15 +1000 Rusty Russell

    > wrote:
    > > > > What is the maximum numbet of pages which an unpriviliged user can
    > > > > concurrently pin with this code?
    > > >
    > > > Since only root can open the tun device, it's currently OK. The old code
    > > > kmalloced and copied: is there some mm-fu reason why pinning userspace
    > > > memory is worse?

    > >
    > > We generally try to avoid it - it allows users to dos the box.

    >
    > My question is: is pinning a page worse than allocating a (kernel) page in
    > some way?
    >


    I guess pinning is not as bad as straight-out allocating.

    Pinning is limited to the size of the program's VM. Pinning
    it at least pining something which is accounted and is exposed
    to admin tools.

    But they're both pretty similar in effect and risk.
    --
    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/

  7. Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

    From: Rusty Russell
    Date: Sun, 20 Apr 2008 02:41:14 +1000

    > If only there were some kind of, I don't know... summit... for kernel
    > people...


    I'm starting to disbelieve the myth that because we can discuss
    technical issues on mailing lists, we should talk primarily about
    process issues during the kernel summit.

    There is a distinct advantage to discussing and hashing things out in
    person. You can't say "screw you, your idea sucks" when you're face
    to face with the other person, whereas online it's way too easy.
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2