netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Warfield <andy@cs.ubc.ca>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Jake Wires <Jake.Wires@citrix.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	NetDev <netdev@vger.kernel.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>,
	Daniel Stodden <Daniel.Stodden@citrix.com>
Subject: Using splice to carry Xen granted pages through the network stack?
Date: Wed, 15 Jul 2009 10:14:09 -0700	[thread overview]
Message-ID: <4A5E0E61.6020704@goop.org> (raw)

[ I originally sent this in March or so, but I don't think you
responded, and this still seems like an interesting idea. ]

Hi Jens,

In a thread from December last year ("Support for zero-copy TCP transmit
of user space data") you suggested using the splice machinery as a way
to implement zero-copy transmit for iscsi data.

I have a similar problem relating to doing zero-copy transmit of pages
granted from another Xen domain.  These are pages which are in some ways
similar to device mappings (they have no struct page unless we jump
through some hoops to give them one, for example) which are given to us
by another domain (virtual machine)'s network stack since they contain
data they want to transmit through our stack.  Once the stack has
finished with the pages we need to get them back to return to the
original domain (and definitely not let them get freed into the normal
kernel pool).

I've been looking a little bit at the splice stuff to work out how it
might be useful in this case.  One issue struct page; I guess we really
can't get away from having one for granted pages and still get the full
value of using splice (especially I can see also see it being useful on
the block side of the world as well).  So, we can jump through hoops for
that.

But the general plumbing of splice into the network stack seems to have
been an open issue since you introduced it 3 years ago (using as a
reference http://lwn.net/Articles/181169/).  Has any work been done on
this aspect since?  What would need to be done to do it?  Would it mean
wiring up a pipe_buffer_operations to operate with something like
Rusty's skb_shared_info destructor?

Thanks,
   J

             reply	other threads:[~2009-07-15 17:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-15 17:14 Jeremy Fitzhardinge [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-03-19  0:04 Using splice to carry Xen granted pages through the network stack? Jeremy Fitzhardinge

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=4A5E0E61.6020704@goop.org \
    --to=jeremy@goop.org \
    --cc=Daniel.Stodden@citrix.com \
    --cc=Jake.Wires@citrix.com \
    --cc=andy@cs.ubc.ca \
    --cc=chris.mason@oracle.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).