From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-scsi@vger.kernel.org, kvm@vger.kernel.org,
hutao@cn.fujitsu.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, stefanha@redhat.com
Subject: Re: [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers
Date: Tue, 18 Dec 2012 15:59:38 +0200 [thread overview]
Message-ID: <20121218135938.GG26110@redhat.com> (raw)
In-Reply-To: <50D07317.8050902@redhat.com>
On Tue, Dec 18, 2012 at 02:43:51PM +0100, Paolo Bonzini wrote:
> Il 18/12/2012 14:36, Michael S. Tsirkin ha scritto:
> > Some comments without arguing about whether the performance
> > benefit is worth it.
> >
> > On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
> >> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> >> index cf8adb1..39d56c4 100644
> >> --- a/include/linux/virtio.h
> >> +++ b/include/linux/virtio.h
> >> @@ -7,6 +7,7 @@
> >> #include <linux/spinlock.h>
> >> #include <linux/device.h>
> >> #include <linux/mod_devicetable.h>
> >> +#include <linux/dma-direction.h>
> >> #include <linux/gfp.h>
> >>
> >> /**
> >> @@ -40,6 +41,26 @@ int virtqueue_add_buf(struct virtqueue *vq,
> >> void *data,
> >> gfp_t gfp);
> >>
> >> +struct virtqueue_buf {
> >> + struct virtqueue *vq;
> >> + struct vring_desc *indirect, *tail;
> >
> > This is wrong: virtio.h does not include virito_ring.h,
> > and it shouldn't by design depend on it.
> >
> >> + int head;
> >> +};
> >> +
> >
> > Can't we track state internally to the virtqueue?
> > Exposing it seems to buy us nothing since you can't
> > call add_buf between start and end anyway.
>
> I wanted to keep the state for these functions separate from the rest.
> I don't think it makes much sense to move it to struct virtqueue unless
> virtqueue_add_buf is converted to use the new API (doesn't make much
> sense, could even be a tad slower).
Why would it be slower?
> On the other hand moving it there would eliminate the dependency on
> virtio_ring.h. Rusty, what do you think?
>
> >> +int virtqueue_start_buf(struct virtqueue *_vq,
> >> + struct virtqueue_buf *buf,
> >> + void *data,
> >> + unsigned int count,
> >> + unsigned int count_sg,
> >> + gfp_t gfp);
> >> +
> >> +void virtqueue_add_sg(struct virtqueue_buf *buf,
> >> + struct scatterlist sgl[],
> >> + unsigned int count,
> >> + enum dma_data_direction dir);
> >> +
> >
> > And idea: in practice virtio scsi seems to always call sg_init_one, no?
> > So how about we pass in void* or something and avoid using sg and count?
> > This would make it useful for -net BTW.
>
> It also passes the scatterlist from the LLD. It calls sg_init_one for
> the request/response headers.
>
> Paolo
Try adding a _single variant. You might see unrolling a loop
gives more of a benefit than this whole optimization.
> >> +void virtqueue_end_buf(struct virtqueue_buf *buf);
> >> +
> >> void virtqueue_kick(struct virtqueue *vq);
> >>
> >> bool virtqueue_kick_prepare(struct virtqueue *vq);
> >> --
> >> 1.7.1
> >>
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
gaowanlong@cn.fujitsu.com, hutao@cn.fujitsu.com,
linux-scsi@vger.kernel.org,
virtualization@lists.linux-foundation.org, rusty@rustcorp.com.au,
asias@redhat.com, stefanha@redhat.com, nab@linux-iscsi.org
Subject: Re: [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers
Date: Tue, 18 Dec 2012 15:59:38 +0200 [thread overview]
Message-ID: <20121218135938.GG26110@redhat.com> (raw)
In-Reply-To: <50D07317.8050902@redhat.com>
On Tue, Dec 18, 2012 at 02:43:51PM +0100, Paolo Bonzini wrote:
> Il 18/12/2012 14:36, Michael S. Tsirkin ha scritto:
> > Some comments without arguing about whether the performance
> > benefit is worth it.
> >
> > On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
> >> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> >> index cf8adb1..39d56c4 100644
> >> --- a/include/linux/virtio.h
> >> +++ b/include/linux/virtio.h
> >> @@ -7,6 +7,7 @@
> >> #include <linux/spinlock.h>
> >> #include <linux/device.h>
> >> #include <linux/mod_devicetable.h>
> >> +#include <linux/dma-direction.h>
> >> #include <linux/gfp.h>
> >>
> >> /**
> >> @@ -40,6 +41,26 @@ int virtqueue_add_buf(struct virtqueue *vq,
> >> void *data,
> >> gfp_t gfp);
> >>
> >> +struct virtqueue_buf {
> >> + struct virtqueue *vq;
> >> + struct vring_desc *indirect, *tail;
> >
> > This is wrong: virtio.h does not include virito_ring.h,
> > and it shouldn't by design depend on it.
> >
> >> + int head;
> >> +};
> >> +
> >
> > Can't we track state internally to the virtqueue?
> > Exposing it seems to buy us nothing since you can't
> > call add_buf between start and end anyway.
>
> I wanted to keep the state for these functions separate from the rest.
> I don't think it makes much sense to move it to struct virtqueue unless
> virtqueue_add_buf is converted to use the new API (doesn't make much
> sense, could even be a tad slower).
Why would it be slower?
> On the other hand moving it there would eliminate the dependency on
> virtio_ring.h. Rusty, what do you think?
>
> >> +int virtqueue_start_buf(struct virtqueue *_vq,
> >> + struct virtqueue_buf *buf,
> >> + void *data,
> >> + unsigned int count,
> >> + unsigned int count_sg,
> >> + gfp_t gfp);
> >> +
> >> +void virtqueue_add_sg(struct virtqueue_buf *buf,
> >> + struct scatterlist sgl[],
> >> + unsigned int count,
> >> + enum dma_data_direction dir);
> >> +
> >
> > And idea: in practice virtio scsi seems to always call sg_init_one, no?
> > So how about we pass in void* or something and avoid using sg and count?
> > This would make it useful for -net BTW.
>
> It also passes the scatterlist from the LLD. It calls sg_init_one for
> the request/response headers.
>
> Paolo
Try adding a _single variant. You might see unrolling a loop
gives more of a benefit than this whole optimization.
> >> +void virtqueue_end_buf(struct virtqueue_buf *buf);
> >> +
> >> void virtqueue_kick(struct virtqueue *vq);
> >>
> >> bool virtqueue_kick_prepare(struct virtqueue *vq);
> >> --
> >> 1.7.1
> >>
next prev parent reply other threads:[~2012-12-18 13:59 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-18 12:32 [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission Paolo Bonzini
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 12:32 ` [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers Paolo Bonzini
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 13:36 ` Michael S. Tsirkin
2012-12-18 13:36 ` Michael S. Tsirkin
2012-12-18 13:43 ` Paolo Bonzini
2012-12-18 13:43 ` Paolo Bonzini
2012-12-18 13:59 ` Michael S. Tsirkin [this message]
2012-12-18 13:59 ` Michael S. Tsirkin
2012-12-18 14:32 ` Paolo Bonzini
2012-12-18 14:32 ` Paolo Bonzini
2012-12-18 15:06 ` Michael S. Tsirkin
2012-12-18 15:06 ` Michael S. Tsirkin
2012-12-19 10:47 ` Stefan Hajnoczi
2012-12-19 12:04 ` Paolo Bonzini
2012-12-19 12:04 ` Paolo Bonzini
2012-12-19 12:40 ` Stefan Hajnoczi
2012-12-19 12:40 ` Stefan Hajnoczi
2012-12-19 16:51 ` Michael S. Tsirkin
2012-12-19 16:51 ` Michael S. Tsirkin
2012-12-19 16:52 ` Michael S. Tsirkin
2012-12-19 16:52 ` Michael S. Tsirkin
2012-12-19 10:47 ` Stefan Hajnoczi
2013-01-02 5:03 ` Rusty Russell
2013-01-02 5:03 ` Rusty Russell
2013-01-03 8:58 ` Wanlong Gao
2013-01-03 8:58 ` Wanlong Gao
2013-01-03 8:58 ` Wanlong Gao
2013-01-06 23:32 ` Rusty Russell
2013-01-06 23:32 ` Rusty Russell
2013-01-06 23:32 ` Rusty Russell
2013-01-03 9:22 ` Paolo Bonzini
2013-01-03 9:22 ` Paolo Bonzini
2013-01-07 0:02 ` Rusty Russell
2013-01-07 0:02 ` Rusty Russell
2013-01-07 14:27 ` Paolo Bonzini
2013-01-08 0:12 ` Rusty Russell
2013-01-08 0:12 ` Rusty Russell
2013-01-10 8:44 ` Paolo Bonzini
2012-12-18 12:32 ` [PATCH v2 2/5] virtio-scsi: use functions for piecewise composition " Paolo Bonzini
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 13:37 ` Michael S. Tsirkin
2012-12-18 13:37 ` Michael S. Tsirkin
2012-12-18 13:35 ` Paolo Bonzini
2012-12-18 13:35 ` Paolo Bonzini
2012-12-18 12:32 ` [PATCH v2 3/5] virtio-scsi: redo allocation of target data Paolo Bonzini
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 12:32 ` [PATCH v2 4/5] virtio-scsi: pass struct virtio_scsi to virtqueue completion function Paolo Bonzini
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 12:32 ` [PATCH v2 5/5] virtio-scsi: introduce multiqueue support Paolo Bonzini
2012-12-18 13:57 ` Michael S. Tsirkin
2012-12-18 13:57 ` Michael S. Tsirkin
2012-12-18 14:08 ` Paolo Bonzini
2012-12-18 14:08 ` Paolo Bonzini
2012-12-18 15:03 ` Michael S. Tsirkin
2012-12-18 15:03 ` Michael S. Tsirkin
2012-12-18 15:51 ` Paolo Bonzini
2012-12-18 15:51 ` Paolo Bonzini
2012-12-18 16:02 ` Michael S. Tsirkin
2012-12-18 16:02 ` Michael S. Tsirkin
2012-12-25 12:41 ` Wanlong Gao
2012-12-25 12:41 ` Wanlong Gao
2012-12-19 11:27 ` Stefan Hajnoczi
2012-12-19 11:27 ` Stefan Hajnoczi
2012-12-18 12:32 ` Paolo Bonzini
2012-12-18 13:42 ` [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission Michael S. Tsirkin
2012-12-18 13:42 ` Michael S. Tsirkin
2012-12-24 6:44 ` Wanlong Gao
2012-12-24 6:44 ` Wanlong Gao
2012-12-18 22:18 ` Rolf Eike Beer
2012-12-19 8:52 ` Paolo Bonzini
2012-12-19 8:52 ` Paolo Bonzini
2012-12-19 11:32 ` Michael S. Tsirkin
2012-12-19 11:32 ` Michael S. Tsirkin
2012-12-18 22:18 ` Rolf Eike Beer
2013-01-15 9:48 ` [PATCH 1/2] virtio-scsi: split out request queue set affinity function Wanlong Gao
2013-01-15 9:48 ` Wanlong Gao
2013-01-15 9:50 ` [PATCH 2/2] virtio-scsi: reset virtqueue affinity when doing cpu hotplug Wanlong Gao
2013-01-15 9:50 ` Wanlong Gao
2013-01-16 3:31 ` Rusty Russell
2013-01-16 3:31 ` Rusty Russell
2013-01-16 3:55 ` Wanlong Gao
2013-01-16 3:55 ` Wanlong Gao
2013-02-06 17:27 ` Paolo Bonzini
2013-02-06 17:27 ` Paolo Bonzini
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=20121218135938.GG26110@redhat.com \
--to=mst@redhat.com \
--cc=hutao@cn.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux-foundation.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.