From: "Michael S. Tsirkin" <mst@redhat.com> To: Paolo Bonzini <pbonzini@redhat.com> Cc: linux-kernel@vger.kernel.org, Wanlong Gao <gaowanlong@cn.fujitsu.com>, asias@redhat.com, Rusty Russell <rusty@rustcorp.com.au>, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 1/9] virtio: add functions for piecewise addition of buffers Date: Tue, 12 Feb 2013 18:13:26 +0200 [thread overview] Message-ID: <20130212161326.GB4373@redhat.com> (raw) In-Reply-To: <511A6457.80609@redhat.com> On Tue, Feb 12, 2013 at 04:48:39PM +0100, Paolo Bonzini wrote: > Il 12/02/2013 16:43, Michael S. Tsirkin ha scritto: > > On Tue, Feb 12, 2013 at 04:32:27PM +0100, Paolo Bonzini wrote: > >> Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto: > >>>>> +/** > >>>>> + * virtqueue_start_buf - start building buffer for the other end > >>>>> + * @vq: the struct virtqueue we're talking about. > >>>>> + * @data: the token identifying the buffer. > >>>>> + * @nents: the number of buffers that will be added > >>> This function starts building one buffer, number of buffers > >>> is a bit weird here. > >> > >> Ok. > >> > >>>>> + * @nsg: the number of sg lists that will be added > >>> This means number of calls to add_sg ? Not sure why this matters. > >>> How about we pass in in_num/out_num - that is total # of sg, > >>> same as add_buf? > >> > >> It is used to choose between direct and indirect. > > > > total number of in and out should be enough for this, no? > > Originally, I used nsg/nents because I wanted to use mixed direct and > indirect buffers. nsg/nents let me choose between full direct (nsg == > nents), mixed (num_free >= nsg), full indirect (num_free < nsg). Then I > had to give up because QEMU does not support it, but I still would like > to keep that open in the API. Problem is it does not seem to make sense in the API. > In this series, however, I am still using nsg to choose between direct > and indirect. I would like to use dirtect for small scatterlists, even > if they are surrounded by a request/response headers/footers. Shouldn't we base this on total number of s/g entries? I don't see why does it matter how many calls you use to build up the list. > >>>>> +/** > >>>>> + * virtqueue_add_sg - add sglist to buffer being built > >>>>> + * @_vq: the virtqueue for which the buffer is being built > >>>>> + * @sgl: the description of the buffer(s). > >>>>> + * @nents: the number of items to process in sgl > >>>>> + * @dir: whether the sgl is read or written (DMA_TO_DEVICE/DMA_FROM_DEVICE only) > >>>>> + * > >>>>> + * Note that, unlike virtqueue_add_buf, this function follows chained > >>>>> + * scatterlists, and stops before the @nents-th item if a scatterlist item > >>>>> + * has a marker. > >>>>> + * > >>>>> + * Caller must ensure we don't call this with other virtqueue operations > >>>>> + * at the same time (except where noted). > >>> Hmm so if you want to add in and out, need separate calls? > >>> in_num/out_num would be nicer? > >> > >> If you want to add in and out just use virtqueue_add_buf... > > > > I thought the point of this one is maximum flexibility. > > Maximum flexibility does not include doing everything in one call (the > other way round in fact: you already need to wrap with start/end, hence > doing one or two extra add_sg calls is not important). > > Paolo My point is, we have exactly same number of parameters: in + out instead of nsg + direction, and we get more functionality. -- MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com> To: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 1/9] virtio: add functions for piecewise addition of buffers Date: Tue, 12 Feb 2013 18:13:26 +0200 [thread overview] Message-ID: <20130212161326.GB4373@redhat.com> (raw) In-Reply-To: <511A6457.80609@redhat.com> On Tue, Feb 12, 2013 at 04:48:39PM +0100, Paolo Bonzini wrote: > Il 12/02/2013 16:43, Michael S. Tsirkin ha scritto: > > On Tue, Feb 12, 2013 at 04:32:27PM +0100, Paolo Bonzini wrote: > >> Il 12/02/2013 15:56, Michael S. Tsirkin ha scritto: > >>>>> +/** > >>>>> + * virtqueue_start_buf - start building buffer for the other end > >>>>> + * @vq: the struct virtqueue we're talking about. > >>>>> + * @data: the token identifying the buffer. > >>>>> + * @nents: the number of buffers that will be added > >>> This function starts building one buffer, number of buffers > >>> is a bit weird here. > >> > >> Ok. > >> > >>>>> + * @nsg: the number of sg lists that will be added > >>> This means number of calls to add_sg ? Not sure why this matters. > >>> How about we pass in in_num/out_num - that is total # of sg, > >>> same as add_buf? > >> > >> It is used to choose between direct and indirect. > > > > total number of in and out should be enough for this, no? > > Originally, I used nsg/nents because I wanted to use mixed direct and > indirect buffers. nsg/nents let me choose between full direct (nsg == > nents), mixed (num_free >= nsg), full indirect (num_free < nsg). Then I > had to give up because QEMU does not support it, but I still would like > to keep that open in the API. Problem is it does not seem to make sense in the API. > In this series, however, I am still using nsg to choose between direct > and indirect. I would like to use dirtect for small scatterlists, even > if they are surrounded by a request/response headers/footers. Shouldn't we base this on total number of s/g entries? I don't see why does it matter how many calls you use to build up the list. > >>>>> +/** > >>>>> + * virtqueue_add_sg - add sglist to buffer being built > >>>>> + * @_vq: the virtqueue for which the buffer is being built > >>>>> + * @sgl: the description of the buffer(s). > >>>>> + * @nents: the number of items to process in sgl > >>>>> + * @dir: whether the sgl is read or written (DMA_TO_DEVICE/DMA_FROM_DEVICE only) > >>>>> + * > >>>>> + * Note that, unlike virtqueue_add_buf, this function follows chained > >>>>> + * scatterlists, and stops before the @nents-th item if a scatterlist item > >>>>> + * has a marker. > >>>>> + * > >>>>> + * Caller must ensure we don't call this with other virtqueue operations > >>>>> + * at the same time (except where noted). > >>> Hmm so if you want to add in and out, need separate calls? > >>> in_num/out_num would be nicer? > >> > >> If you want to add in and out just use virtqueue_add_buf... > > > > I thought the point of this one is maximum flexibility. > > Maximum flexibility does not include doing everything in one call (the > other way round in fact: you already need to wrap with start/end, hence > doing one or two extra add_sg calls is not important). > > Paolo My point is, we have exactly same number of parameters: in + out instead of nsg + direction, and we get more functionality. -- MST
next prev parent reply other threads:[~2013-02-12 16:09 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-12 12:23 [PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 1/9] virtio: add functions for piecewise addition of buffers Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 14:56 ` Michael S. Tsirkin 2013-02-12 14:56 ` Michael S. Tsirkin 2013-02-12 15:32 ` Paolo Bonzini 2013-02-12 15:32 ` Paolo Bonzini 2013-02-12 15:43 ` Michael S. Tsirkin 2013-02-12 15:43 ` Michael S. Tsirkin 2013-02-12 15:48 ` Paolo Bonzini 2013-02-12 15:48 ` Paolo Bonzini 2013-02-12 16:13 ` Michael S. Tsirkin [this message] 2013-02-12 16:13 ` Michael S. Tsirkin 2013-02-12 16:17 ` Paolo Bonzini 2013-02-12 16:17 ` Paolo Bonzini 2013-02-12 16:35 ` Michael S. Tsirkin 2013-02-12 16:35 ` Michael S. Tsirkin 2013-02-12 16:57 ` Paolo Bonzini 2013-02-12 16:57 ` Paolo Bonzini 2013-02-12 17:34 ` Michael S. Tsirkin 2013-02-12 17:34 ` Michael S. Tsirkin 2013-02-12 18:04 ` Paolo Bonzini 2013-02-12 18:04 ` Paolo Bonzini 2013-02-12 18:23 ` Michael S. Tsirkin 2013-02-12 18:23 ` Michael S. Tsirkin 2013-02-12 20:08 ` Paolo Bonzini 2013-02-12 20:08 ` Paolo Bonzini 2013-02-12 20:49 ` Michael S. Tsirkin 2013-02-12 20:49 ` Michael S. Tsirkin 2013-02-13 8:06 ` Paolo Bonzini 2013-02-13 10:33 ` Michael S. Tsirkin 2013-02-12 18:03 ` [PATCH v2 " Paolo Bonzini 2013-02-12 18:03 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 2/9] virtio-blk: reorganize virtblk_add_req Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-17 6:38 ` Asias He 2013-02-17 6:38 ` Asias He 2013-02-12 12:23 ` [PATCH 3/9] virtio-blk: use virtqueue_start_buf on bio path Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-17 6:39 ` Asias He 2013-02-17 6:39 ` Asias He 2013-02-12 12:23 ` [PATCH 4/9] virtio-blk: use virtqueue_start_buf on req path Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-17 6:37 ` Asias He 2013-02-17 6:37 ` Asias He 2013-02-18 9:05 ` Paolo Bonzini 2013-02-18 9:05 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 5/9] scatterlist: introduce sg_unmark_end Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 6/9] virtio-net: unmark scatterlist ending after virtqueue_add_buf Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 7/9] virtio-scsi: use virtqueue_start_buf Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 8/9] virtio: introduce and use virtqueue_add_buf_single Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-12 12:23 ` [PATCH 9/9] virtio: reimplement virtqueue_add_buf using new functions Paolo Bonzini 2013-02-12 12:23 ` Paolo Bonzini 2013-02-14 6:00 ` [PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes Rusty Russell 2013-02-14 6:00 ` Rusty Russell 2013-02-14 9:23 ` Paolo Bonzini 2013-02-14 9:23 ` Paolo Bonzini 2013-02-15 18:04 ` Paolo Bonzini 2013-02-15 18:04 ` Paolo Bonzini 2013-02-19 7:49 ` Rusty Russell 2013-02-19 7:49 ` Rusty Russell 2013-02-19 9:11 ` Paolo Bonzini 2013-02-19 9:11 ` 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=20130212161326.GB4373@redhat.com \ --to=mst@redhat.com \ --cc=asias@redhat.com \ --cc=gaowanlong@cn.fujitsu.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pbonzini@redhat.com \ --cc=rusty@rustcorp.com.au \ --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.