Re: [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)

[Blue Swirl]

On 4/16/08, Anthony Liguori <address@hidden> wrote:
> Blue Swirl wrote:
>
> > On 4/16/08, Anthony Liguori <address@hidden> wrote:
> >
> >
> > > This patch introduces a DMA API and plumbs support through the DMA
> layer.  We
> > >  use a mostly opaque structure, IOVector to represent a scatter/gather
> list of
> > >  physical memory.  Associated with each IOVector is a read/write
> function and
> > >  an opaque pointer.  This allows arbitrary transformation/mapping of the
> > >  data while providing an easy mechanism to short-cut the zero-copy case
> > >  in the block/net backends.
> > >
> > >
> >
> > This looks much better also for Sparc uses. I converted pcnet to use
> > the IOVectors (see patch), it does not work yet but looks doable.
> >
> >
>
>  Excellent!

I fixed the bug, now pcnet works. Performance is improved by a few
percent. The problem was that the vector was not freed. Maybe dynamic
allocation is a bit fragile. In this case, the length of the vector is
known, so it could be allocated once at init time. But would this
work?

The next step would be to add a vector version for packet receive. For
ESP/SCSI, in addition to bdrv_readv/writev, AIO versions would need to
be added. Last year I made a patch (attached) that made SLIRP use my
version of IOVector, I could update it to this model.

> > IMHO the read/write functions should be a property of the bus so that
> > they are hidden from the device, for pcnet it does not matter as we
> > have to do the swapping anyway.
> >
> >
>
>  For an IOMMU that has a per-device mapping, the read/write functions have
> to operate on a per-device basis.

No, I meant that there could be a bus layer that did the memory access
and provided a specialized version of iovector_new without the
handlers. But I think we can live with this, if things get too ugly we
can add the layering later.

pcnet_prepare.diff
Description: plain/text

pcnet_dma_api.diff
Description: plain/text

slirp_iov.diff
Description: plain/text