Re: [RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes

[Paolo Bonzini <pbonzini@redhat.com>]

Il 07/02/2013 14:23, Michael S. Tsirkin ha scritto:
> On Thu, Feb 07, 2013 at 02:14:24PM +0100, Paolo Bonzini wrote:
>> Il 07/02/2013 14:09, Michael S. Tsirkin ha scritto:
>>>> One major difference between virtqueue_add_buf and virtqueue_add_sg
>>>> is that the latter uses scatterlist iterators, which follow chained
>>>> scatterlist structs and stop at ending markers.  In order to avoid code
>>>> duplication, and use the new API from virtqueue_add_buf (patch 8), we need
>>>> to change all existing callers of virtqueue_add_buf to provide well-formed
>>>> scatterlists.  This is what patches 2-7 do.  For virtio-blk it is easiest
>>>> to just switch to the new API, just like for virtio-scsi.  For virtio-net
>>>> the ending marker must be reset after calling virtqueue_add_buf, in
>>>> preparation for the next usage of the scatterlist.  Other drivers are
>>>> safe already.
>>>
>>> What are the changes as compared to the previous version?
>>> How about some comments made on the previous version?
>>> See e.g.
>>> https://patchwork.kernel.org/patch/1891541/
>>
>> Two changes: 1) added virtqueue_add_sg_single; 2) reimplemented
>> virtqueue_add_buf in terms of the new API, which requires virtio-blk and
>> virtio-net changes.
>>
>> The virtio-blk and virtio-net changes are based on some ideas in the
>> patch Rusty posted, but virtio-net is a bit simpler and virtio-blk was
>> redone from scratch.
>>
>>> Generally we have code for direct and indirect which is already
>>> painful. We do not want 4 more variants of this code.
>>
>> Yes, indeed, the other main difference is that I'm now reimplementing
>> virtqueue_add_buf using the new functions.  So:
>>
>> - we previously had 2 variants (direct/indirect)
>>
>> - v1 had 4 variants (direct/indirect x add_buf/add_sg)
>>
>> - v2 has 4 variants (direct/indirect x add_sg/add_sg_single)
> 
> single is never indirect so should have a single variant.

Single means *this piece* (for example a request header) is single.  It
could still end up in an indirect buffer because QEMU does not support
mixed direct/indirect buffers.

Paolo

>>>> This is an RFC for two reasons.  First, because I haven't done enough
>>>> testing yet (especially with all the variations on receiving that
>>>> virtio-net has).  Second, because I still have two struct vring_desc *
>>>> fields in virtqueue API, which is a layering violation.  I'm not really
>>>> sure how important that is and how to fix that---except by making the
>>>> fields void*.
>>>
>>> Hide the whole structure as part of vring struct, the problem will go
>>> away.
>>
>> Yes, that's the other possibility.  Will do for the next submission.
>>
>> Paolo
>>
>>>> Paolo
>>>> Paolo Bonzini (8):
>>>>   virtio: add functions for piecewise addition of buffers
>>>>   virtio-blk: reorganize virtblk_add_req
>>>>   virtio-blk: use virtqueue_start_buf on bio path
>>>>   virtio-blk: use virtqueue_start_buf on req path
>>>>   scatterlist: introduce sg_unmark_end
>>>>   virtio-net: unmark scatterlist ending after virtqueue_add_buf
>>>>   virtio-scsi: use virtqueue_start_buf
>>>>   virtio: reimplement virtqueue_add_buf using new functions
>>>>
>>>>  block/blk-integrity.c        |    2 +-
>>>>  block/blk-merge.c            |    2 +-
>>>>  drivers/block/virtio_blk.c   |  165 +++++++++--------
>>>>  drivers/net/virtio_net.c     |   21 ++-
>>>>  drivers/scsi/virtio_scsi.c   |  103 +++++------
>>>>  drivers/virtio/virtio_ring.c |  417 +++++++++++++++++++++++++++---------------
>>>>  include/linux/scatterlist.h  |   16 ++
>>>>  include/linux/virtio.h       |   25 +++
>>>>  8 files changed, 460 insertions(+), 291 deletions(-)