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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130207133133.GC21707@redhat.com>
Date:	Thu, 7 Feb 2013 15:31:33 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Wanlong Gao <gaowanlong@...fujitsu.com>, asias@...hat.com,
	Rusty Russell <rusty@...tcorp.com.au>, kvm@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [RFC PATCH 0/8] virtio: new API for addition of buffers,
 scatterlist changes

On Thu, Feb 07, 2013 at 02:20:53PM +0100, Paolo Bonzini wrote:
> 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

Yes but why is the optimization worth it?
It makes sense if all we want to do is add a single buffer
in one go, this would give us virtqueue_add_buf_single.

But if we are building up an s/g list anyway,
speeding up one of the entries a tiny bit
seems very unlikely to be measureable.
No?

> >>>> 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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/