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
next prev parent 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).