From: Rusty Russell <rusty@rustcorp.com.au> To: Paolo Bonzini <pbonzini@redhat.com> Cc: linux-kernel@vger.kernel.org, Wanlong Gao <gaowanlong@cn.fujitsu.com>, asias@redhat.com, mst@redhat.com, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes Date: Tue, 19 Feb 2013 18:19:11 +1030 [thread overview] Message-ID: <87ehgciw08.fsf@rustcorp.com.au> (raw) In-Reply-To: <511CAD19.2010902@redhat.com> Paolo Bonzini <pbonzini@redhat.com> writes: >> virtio_ring: virtqueue_add_sgs, to add multiple sgs. >> >> virtio_scsi and virtio_blk can really use these, to avoid their current >> hack of copying the whole sg array. >> >> Signed-off-by: Ruty Russell <rusty@rustcorp.com.au> > > It's much better than the other prototype you had posted, but I still > dislike this... You pay for additional counting of scatterlists when > the caller knows the number of buffers Yes, but I like the API simplicity. We could use an array of sg_table, which is what you have in virtio_scsi anyway, but I doubt it's measurable on benchmarks. > and the nested loops aren't free, either. I think they'll win over multiple function calls :) But modulo devastating benchmarks, this wins. Because the three-part API is really, really ugly. It *looks* like a generic "start - work ... work - end" API, but it's not. Because you need to declare exactly what you're doing in virtqueue_start_buf! And that's OK, because noone wants a generic API like that. > > + sg_unmark_end(sg + out + in); > > + if (out && in) > > + sg_unmark_end(sg + out); > > What's this second sg_unmark_end block for? Doesn't it access after the > end of sg? If you wanted it to be sg_mark_end, that must be: > > if (out) > sg_mark_end(sg + out - 1); > if (in) > sg_mark_end(sg + out + in - 1); > > with a corresponding unmark afterwards. Thanks, I fixed that after I actually tested it :) But as we clean them every time, we don't need to unmark: /* Workaround until callers pass well-formed sgs. */ for (i = 0; i < out + in; i++) sg_unmark_end(sg + i); sg_mark_end(sg + out + in - 1); if (out && in) sg_mark_end(sg + out - 1); return virtqueue_add_sgs(_vq, sgs, out ? 1 : 0, in ? 1 : 0, data, gfp); This is a workaround until all callers fixed / replaced, of course. > Another problem is that you cannot pass "truncated" scatterlists. You > must ensure there is an end marker on the last item. I'm not sure if > the kernel ensures that, given that for_each_sg takes explicitly the > number of scatterlist elements; and it is not as trivial as > "sg_mark_end(foo + nsg - 1);" if the upper layers hand you a chained > scatterlist. Makes you wonder why they have end markers at all. But yes, the block layer does the right thing with end markers in blk_bio_map_sg(), which seems to carry through. Cheers, Rusty. PS. Patchbomb coming, lightly tested.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au> To: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org, mst@redhat.com, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes Date: Tue, 19 Feb 2013 18:19:11 +1030 [thread overview] Message-ID: <87ehgciw08.fsf@rustcorp.com.au> (raw) In-Reply-To: <511CAD19.2010902@redhat.com> Paolo Bonzini <pbonzini@redhat.com> writes: >> virtio_ring: virtqueue_add_sgs, to add multiple sgs. >> >> virtio_scsi and virtio_blk can really use these, to avoid their current >> hack of copying the whole sg array. >> >> Signed-off-by: Ruty Russell <rusty@rustcorp.com.au> > > It's much better than the other prototype you had posted, but I still > dislike this... You pay for additional counting of scatterlists when > the caller knows the number of buffers Yes, but I like the API simplicity. We could use an array of sg_table, which is what you have in virtio_scsi anyway, but I doubt it's measurable on benchmarks. > and the nested loops aren't free, either. I think they'll win over multiple function calls :) But modulo devastating benchmarks, this wins. Because the three-part API is really, really ugly. It *looks* like a generic "start - work ... work - end" API, but it's not. Because you need to declare exactly what you're doing in virtqueue_start_buf! And that's OK, because noone wants a generic API like that. > > + sg_unmark_end(sg + out + in); > > + if (out && in) > > + sg_unmark_end(sg + out); > > What's this second sg_unmark_end block for? Doesn't it access after the > end of sg? If you wanted it to be sg_mark_end, that must be: > > if (out) > sg_mark_end(sg + out - 1); > if (in) > sg_mark_end(sg + out + in - 1); > > with a corresponding unmark afterwards. Thanks, I fixed that after I actually tested it :) But as we clean them every time, we don't need to unmark: /* Workaround until callers pass well-formed sgs. */ for (i = 0; i < out + in; i++) sg_unmark_end(sg + i); sg_mark_end(sg + out + in - 1); if (out && in) sg_mark_end(sg + out - 1); return virtqueue_add_sgs(_vq, sgs, out ? 1 : 0, in ? 1 : 0, data, gfp); This is a workaround until all callers fixed / replaced, of course. > Another problem is that you cannot pass "truncated" scatterlists. You > must ensure there is an end marker on the last item. I'm not sure if > the kernel ensures that, given that for_each_sg takes explicitly the > number of scatterlist elements; and it is not as trivial as > "sg_mark_end(foo + nsg - 1);" if the upper layers hand you a chained > scatterlist. Makes you wonder why they have end markers at all. But yes, the block layer does the right thing with end markers in blk_bio_map_sg(), which seems to carry through. Cheers, Rusty. PS. Patchbomb coming, lightly tested.
next prev parent reply other threads:[~2013-02-19 8:02 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 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 [this message] 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=87ehgciw08.fsf@rustcorp.com.au \ --to=rusty@rustcorp.com.au \ --cc=asias@redhat.com \ --cc=gaowanlong@cn.fujitsu.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=pbonzini@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.