qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Faster, generic IO/DMA model with vectored AIO?
Date: Sun, 28 Oct 2007 19:10:28 +0000	[thread overview]
Message-ID: <20071028191028.GF14076@mail.shareable.org> (raw)
In-Reply-To: <f43fc5580710280209t162399f2weec2b93ad1c757da@mail.gmail.com>

Blue Swirl wrote:
> Currently scsi-disk provides a buffer. For true zero copy, this needs
> to be changed so that instead the buffer is provided by the caller at
> each stage until we reach the host memory. But I'll use the scsi-disk
> buffer for now.

This might actually work in Qemu.

But in general, a zero-copy I/O interface needs to allow for the
possibility that either the source of data, or the sink, might need to
be in charge of buffer allocations for a particular sequence.
Otherwise you get situations where the data has to be copied to meet a
technical constraint of a source of a sink, and the copy could have
been avoided if the addresses were allocated to meet that constraint
in the first place.  The most common technical constraint is probably
the need for large contiguous blocks.

I deal with this in my own program by having an I/O call from source
to sink for requesting memory (through a chain of sources/sinks like
your example if necessary), but only when the source is preparing to
do an I/O and hasn't yet prepared the data.  If the data is already
prepared before setting up the I/O for a write, then there's no point
asking the sink to allocate memory, and if it has to anyway (e.g. if
it needs a large contiguous block), that's an unavoidable copy anyway.

A couple of examples of sinks with constraints are:

   - Can't use writev().  E.g. you're using a slightly old Linux
     kernel, want to do AIO, and it doesn't have async writev(), only async
     write().

   - Writing to sound card through memory-mapped ring buffer.  The
     sink is the code which opens /dev/dsp, and then it can provide
     buffers for zero-copy only if it picks the address where data
     will be prepared.

   - Async I/O using "database writer" style separate processes which
     actually do the writes synchronously, and the data is passed to
     them using shared memory.  For this, the sink is the code which
     sends a request to one of the writer processes, and it must use a
     buffer which is in the mapped shared memory.

-- Jamie

  reply	other threads:[~2007-10-28 21:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-27 12:56 [Qemu-devel] Faster, generic IO/DMA model with vectored AIO? Blue Swirl
2007-10-27 16:53 ` [Qemu-devel] " Blue Swirl
2007-10-28  1:29 ` [Qemu-devel] " Paul Brook
2007-10-28  9:09   ` Blue Swirl
2007-10-28 19:10     ` Jamie Lokier [this message]
2007-10-29 19:33       ` Blue Swirl
2007-10-30 20:09         ` Blue Swirl
2007-10-28 20:55     ` Blue Swirl

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=20071028191028.GF14076@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.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 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).