All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net,
	Marcelo Tosatti <marcelo@kvack.org>,
	qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API
Date: Sun, 30 Mar 2008 18:19:53 +0000	[thread overview]
Message-ID: <200803301919.54780.paul@codesourcery.com> (raw)
In-Reply-To: <47EFA6E1.7020401@us.ibm.com>

On Sunday 30 March 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> > On Saturday 29 March 2008, Anthony Liguori wrote:
> >> This patch introduces a PCI DMA API and some generic code to support
> >> other DMA APIs.  Two types are introduced: PhysIOVector and IOVector.  A
> >> DMA API maps a PhysIOVector, which is composed of target_phys_addr_t,
> >> into an IOVector, which is composed of void *.
> >
> > Devices should not be using IOVector. They should either use the DMA copy
> > routines to copy from a PhysIOVector into a local buffer, or they should
> > pass a PhysIOVector to a block/network read/write routine. The DMA API
> > should allow devices to be agnostic about how DMA is implemented. They
> > should not be trying to manually implement zero copy.
>
> Someone has to do the translation of PhysIOVector => IOVector.  It
> doesn't seem logical to me to do it in the IO backend level because the
> block subsystem doesn't know how to do that translation.  You would have
> to pass the PhysIOVector although with a translation function and an
> opaque pointer.

The entity processing the data shouldn't need to know or care how the 
translation is done. PhysIOVector should describe everything it need to know.

> What could work is if the DMA API functions mapped PhysIOVector =>
> PhysIOVector and then the network and block subsystems could operate on
> a PhysIOVector.  I have patches that implement vector IO for net and
> block but didn't want to include them in this series to keep things simple.

IMHO this is the only sane way to implement zero-copy.

> >> This enables zero-copy IO to be preformed without introducing
> >> assumptions of phys_ram_base.  This API is at the PCI device level to
> >> enable support of per-device IOMMU remapping.
> >
> > By my reading it *requires* bridges be zero-copy.  For big-endian targets
> > we need to ability to byteswap accesses.
>
> You mean via ld/st_phys?  

By whatever means the bridge deems necessary. The whole point of the DMA API 
is that you're transferring a block of data. The API allows intermediate 
busses to transform that data (and address) without the block handler needing 
to know or care.

With your current scheme a byteswapping bus has to allocate a single large 
buffer for the whole vector, even if the device then ends up copying unto a 
local buffer in small chunks.

Paul

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

WARNING: multiple messages have this Message-ID (diff)
From: Paul Brook <paul@codesourcery.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net,
	Marcelo Tosatti <marcelo@kvack.org>,
	qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API
Date: Sun, 30 Mar 2008 18:19:53 +0000	[thread overview]
Message-ID: <200803301919.54780.paul@codesourcery.com> (raw)
In-Reply-To: <47EFA6E1.7020401@us.ibm.com>

On Sunday 30 March 2008, Anthony Liguori wrote:
> Paul Brook wrote:
> > On Saturday 29 March 2008, Anthony Liguori wrote:
> >> This patch introduces a PCI DMA API and some generic code to support
> >> other DMA APIs.  Two types are introduced: PhysIOVector and IOVector.  A
> >> DMA API maps a PhysIOVector, which is composed of target_phys_addr_t,
> >> into an IOVector, which is composed of void *.
> >
> > Devices should not be using IOVector. They should either use the DMA copy
> > routines to copy from a PhysIOVector into a local buffer, or they should
> > pass a PhysIOVector to a block/network read/write routine. The DMA API
> > should allow devices to be agnostic about how DMA is implemented. They
> > should not be trying to manually implement zero copy.
>
> Someone has to do the translation of PhysIOVector => IOVector.  It
> doesn't seem logical to me to do it in the IO backend level because the
> block subsystem doesn't know how to do that translation.  You would have
> to pass the PhysIOVector although with a translation function and an
> opaque pointer.

The entity processing the data shouldn't need to know or care how the 
translation is done. PhysIOVector should describe everything it need to know.

> What could work is if the DMA API functions mapped PhysIOVector =>
> PhysIOVector and then the network and block subsystems could operate on
> a PhysIOVector.  I have patches that implement vector IO for net and
> block but didn't want to include them in this series to keep things simple.

IMHO this is the only sane way to implement zero-copy.

> >> This enables zero-copy IO to be preformed without introducing
> >> assumptions of phys_ram_base.  This API is at the PCI device level to
> >> enable support of per-device IOMMU remapping.
> >
> > By my reading it *requires* bridges be zero-copy.  For big-endian targets
> > we need to ability to byteswap accesses.
>
> You mean via ld/st_phys?  

By whatever means the bridge deems necessary. The whole point of the DMA API 
is that you're transferring a block of data. The API allows intermediate 
busses to transform that data (and address) without the block handler needing 
to know or care.

With your current scheme a byteswapping bus has to allocate a single large 
buffer for the whole vector, even if the device then ends up copying unto a 
local buffer in small chunks.

Paul

  reply	other threads:[~2008-03-30 18:19 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-29 21:55 [PATCH 1/6] Use ram_addr_t for cpu_get_physical_page_desc Anthony Liguori
2008-03-29 21:55 ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 2/6] PCI DMA API Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30  7:06   ` Blue Swirl
2008-03-30  7:06     ` Blue Swirl
2008-03-30 14:44     ` Anthony Liguori
2008-03-30 14:44       ` Anthony Liguori
2008-03-30 14:49       ` Avi Kivity
2008-03-30 14:49         ` Avi Kivity
2008-03-30 14:56         ` Anthony Liguori
2008-03-30 14:56           ` [kvm-devel] " Anthony Liguori
2008-03-30 14:58       ` Blue Swirl
2008-03-30 14:58         ` Blue Swirl
2008-03-30 15:11         ` Anthony Liguori
2008-03-30 15:11           ` Anthony Liguori
2008-03-30 10:18   ` Paul Brook
2008-03-30 10:18     ` Paul Brook
2008-03-30 14:42     ` Anthony Liguori
2008-03-30 14:42       ` Anthony Liguori
2008-03-30 18:19       ` Paul Brook [this message]
2008-03-30 18:19         ` Paul Brook
2008-03-30 19:02         ` Anthony Liguori
2008-03-30 19:02           ` Anthony Liguori
2008-03-30 10:25   ` Avi Kivity
2008-03-30 10:25     ` [Qemu-devel] Re: [kvm-devel] " Avi Kivity
2008-03-30 14:49     ` Anthony Liguori
2008-03-30 14:49       ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 3/6] virtio for QEMU Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30 17:25   ` Dor Laor
2008-03-30 17:25     ` Dor Laor
2008-03-30 22:59     ` Anthony Liguori
2008-03-30 22:59       ` [kvm-devel] " Anthony Liguori
2008-04-05  3:09     ` Anthony Liguori
2008-04-05  3:09       ` Anthony Liguori
2008-03-29 21:55 ` [PATCH 4/6] virtio network driver Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-30 10:27   ` Paul Brook
2008-03-30 10:27     ` Paul Brook
2008-03-30 14:47     ` Anthony Liguori
2008-03-30 14:47       ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:55 ` [PATCH 5/6] virtio block driver Anthony Liguori
2008-03-29 21:55   ` [Qemu-devel] " Anthony Liguori
2008-03-29 21:56 ` [PATCH 6/6] virtio balloon driver Anthony Liguori
2008-03-29 21:56   ` [Qemu-devel] " Anthony Liguori

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=200803301919.54780.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=aliguori@us.ibm.com \
    --cc=aurelien@aurel32.net \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=marcelo@kvack.org \
    --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 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.