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

[Anthony Liguori <aliguori@us.ibm.com>]

Blue Swirl wrote:
>
> 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?
>   

For you, yes, but not for me.  virtio scatter/gather lists can be very 
long.  The API tries not to make assumptions about who's allocating what 
so you should be able to get away without a dynamic allocation if you 
were sufficiently motivated.

> 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.
>   

Yes, the vector version of packet receive is tough.  I'll take a look at 
your patch.  Basically, you need to associate a set of RX vectors with 
each VLANClientState and then when it comes time to deliver a packet to 
the VLAN, before calling fd_read, see if there is an RX vector available 
for the client.

In the case of tap, I want to optimize further and do the initial 
readv() to one of the clients RX buffers and then copy that RX buffer to 
the rest of the clients if necessary.

Regards,

Anthony Liguori

>>> 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.
>