From: Rusty Russell <rusty@rustcorp.com.au>
To: Max Krasnyansky <maxk@qualcomm.com>
Cc: netdev@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 2/3] partial checksum and GSO support for tun/tap.
Date: Tue, 4 Mar 2008 18:47:45 +1100 [thread overview]
Message-ID: <200803041847.45500.rusty@rustcorp.com.au> (raw)
In-Reply-To: <47CCD930.3040200@qualcomm.com>
On Tuesday 04 March 2008 16:08:00 Max Krasnyansky wrote:
> > The problem with this approach is that for what I'm doing, the packets
> > aren't nicely arranged somewhere; they're in random process memory.
>
> That's fine. RX/TX descriptors would not contain the data itself. They'd
> contain pointers to actual packets (ie just like the NIC takes physical
> memory address and DMAs data in/out).
> The allows for sending/receiving packets without syscalls and fits nicely
> with the async schemes like GSO.
Yes, yes it does. That would be a very nice extension (it's orthogonal to
this patch though, so should we get Dave to take these for 2.6.25?).
And as it happens, virtio already has such a structure: virtio_ring. See
linux/virtio_ring.h.
> > The structure is for virtio, I'm just borrowing it for tap because it's
> > already there. We could rename it and move it out to its own header, but
> > if so we should do that before 2.6.25 is released.
>
> If we do the whole enchilada with the RX/TX rings then we probably do not
> even need it. I'm thinking that RX/TX descriptor would include everything
> you need for the GSO and stuff.
> I meant do not need it for the TUN/TAP driver that is. Is it used anywhere
> else ?
Just for the linux virtio drivers. Reusing it for tun/tap was an
afterthought. It just meant I could pass the same structure straight thru,
though, which is nice.
The userspace->kernel problem is very similar to the guest->host problem, so
it doesn't surprise me if we end up with very similar (identical?)
interfaces.
Take a look at virtio_ring.h, virtio_ring.c and Documentation/lguest/lguest.c
to see how we use it...
Cheers,
Rusty.
next prev parent reply other threads:[~2008-03-04 7:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 14:07 [PATCH 1/3] Cleanup and simplify virtnet header Rusty Russell
2008-01-23 14:10 ` [PATCH 2/3] partial checksum and GSO support for tun/tap Rusty Russell
2008-01-23 14:14 ` [PATCH 3/3] Interface to query tun/tap features Rusty Russell
2008-01-23 14:14 ` Rusty Russell
2008-02-08 5:07 ` Max Krasnyansky
2008-02-08 5:07 ` Max Krasnyansky
2008-02-08 5:39 ` [PATCH 2/3] partial checksum and GSO support for tun/tap Max Krasnyansky
2008-03-04 1:02 ` Rusty Russell
2008-03-04 1:02 ` Rusty Russell
2008-03-04 5:08 ` Max Krasnyansky
2008-03-04 7:47 ` Rusty Russell [this message]
2008-03-04 20:08 ` Max Krasnyanskiy
2008-03-04 20:08 ` Max Krasnyanskiy
2008-03-04 7:47 ` Rusty Russell
2008-02-08 5:39 ` Max Krasnyansky
2008-01-23 14:10 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200803041847.45500.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=herbert@gondor.apana.org.au \
--cc=maxk@qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.