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 17:06:26 +0200 [thread overview] Message-ID: <20121218150626.GC27400@redhat.com> (raw) In-Reply-To: <50D07E6F.6040701@redhat.com> On Tue, Dec 18, 2012 at 03:32:15PM +0100, Paolo Bonzini wrote: > Il 18/12/2012 14:59, Michael S. Tsirkin ha scritto: > >>> 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? > > virtqueue_add_buf could be slower if it used the new API. That's > because of the overhead of writing and reading from struct > virtqueue_buf, instead of using variables in registers. Yes but we'll get rid of virtqueue_buf. > >> On the other hand moving it there would eliminate the dependency > >> on virtio_ring.h. Rusty, what do you think? > >> > >>> 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. > > > > Try adding a _single variant. You might see unrolling a loop gives > > more of a benefit than this whole optimization. > > Makes sense, I'll try. However, note that I *do* need the > infrastructure in this patch because virtio-scsi could never use a > hypothetical virtqueue_add_buf_single; requests always have at least 2 > buffers for the headers. > > However I could add virtqueue_add_sg_single and use it for those > headers. Right. > The I/O buffer can keep using virtqueue_add_sg. > > Paolo
WARNING: multiple messages have this Message-ID (diff)
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 17:06:26 +0200 [thread overview] Message-ID: <20121218150626.GC27400@redhat.com> (raw) In-Reply-To: <50D07E6F.6040701@redhat.com> On Tue, Dec 18, 2012 at 03:32:15PM +0100, Paolo Bonzini wrote: > Il 18/12/2012 14:59, Michael S. Tsirkin ha scritto: > >>> 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? > > virtqueue_add_buf could be slower if it used the new API. That's > because of the overhead of writing and reading from struct > virtqueue_buf, instead of using variables in registers. Yes but we'll get rid of virtqueue_buf. > >> On the other hand moving it there would eliminate the dependency > >> on virtio_ring.h. Rusty, what do you think? > >> > >>> 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. > > > > Try adding a _single variant. You might see unrolling a loop gives > > more of a benefit than this whole optimization. > > Makes sense, I'll try. However, note that I *do* need the > infrastructure in this patch because virtio-scsi could never use a > hypothetical virtqueue_add_buf_single; requests always have at least 2 > buffers for the headers. > > However I could add virtqueue_add_sg_single and use it for those > headers. Right. > The I/O buffer can keep using virtqueue_add_sg. > > Paolo
next prev parent reply other threads:[~2012-12-18 15:03 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 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 [this message] 2012-12-18 15:06 ` Michael S. Tsirkin 2012-12-19 10:47 ` Stefan Hajnoczi 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 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=20121218150626.GC27400@redhat.com \ --to=mst@redhat.com \ --cc=asias@redhat.com \ --cc=gaowanlong@cn.fujitsu.com \ --cc=hutao@cn.fujitsu.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=nab@linux-iscsi.org \ --cc=pbonzini@redhat.com \ --cc=rusty@rustcorp.com.au \ --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: linkBe 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.