search for: scatterlists

OK, so I've spent a few days benchmarking. Turns out 80% of virtio_add_buf cases are uni-directional (including the always-performance-sensitive networking code), and that gets no performance penalty (though tests with real networking would be appreciated!). I'm not reposting all the "convert driver to virtio_add_outbuf()" patches: just the scsi one which I didn't have

OK, so I've spent a few days benchmarking. Turns out 80% of virtio_add_buf cases are uni-directional (including the always-performance-sensitive networking code), and that gets no performance penalty (though tests with real networking would be appreciated!). I'm not reposting all the "convert driver to virtio_add_outbuf()" patches: just the scsi one which I didn't have

...ut, total_in, out_sgs, in_sgs, data, gfp); + return virtqueue_add(_vq, sgs, total_sg, out_sgs, in_sgs, data, gfp); } EXPORT_SYMBOL_GPL(virtqueue_add_sgs); /** * virtqueue_add_outbuf - expose output buffers to other end * @vq: the struct virtqueue we're talking about. - * @sgs: array of scatterlists (need not be terminated!) - * @num: the number of scatterlists readable by other side + * @sg: scatterlist (must be well-formed and terminated!) + * @num: the number of entries in @sg readable by other side * @data: the token identifying the buffer. * @gfp: how to do memory allocations (if nece...

Andy Lutomirski <luto at amacapital.net> writes: > The only unusual thing about virtio's use of scatterlists is that > two of the APIs accept scatterlists that might not be terminated. > Using function pointers to handle this case is overkill; for_each_sg > can do it. > > There's a small subtlely here: for_each_sg assumes that the provided > count is correct, but, because of the way...

Andy Lutomirski <luto at amacapital.net> writes: > The only unusual thing about virtio's use of scatterlists is that > two of the APIs accept scatterlists that might not be terminated. > Using function pointers to handle this case is overkill; for_each_sg > can do it. > > There's a small subtlely here: for_each_sg assumes that the provided > count is correct, but, because of the way...

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the upper SCSI layers. This series adds a different set of APIs for addin...

The virtqueue_add_buf function has two limitations: 1) it requires the caller to provide all the buffers in a single call; 2) it does not support chained scatterlists: the buffers must be provided as an array of struct scatterlist. Because of these limitations, virtio-scsi has to copy each request into a scatterlist internal to the driver. It cannot just use the one that was prepared by the upper SCSI layers. This series adds a different set of APIs for addin...

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

The only unusual thing about virtio's use of scatterlists is that two of the APIs accept scatterlists that might not be terminated. Using function pointers to handle this case is overkill; for_each_sg can do it. There's a small subtlely here: for_each_sg assumes that the provided count is correct, but, because of the way that virtio_ring handles mult...

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.7-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver,...

Most device drivers do not need to perform any postprocessing on the scatterlists they receive from higher-level drivers (e.g. the block or SCSI layer), because they translate the request metadata directly from the various C structs into the data that is required by the device. virtio devices however do this translation in two steps: a device-specific step in the device driver,...

Rather than handing a scatterlist[] and out and in numbers to virtqueue_add_buf(), hand two separate ones which can be chained. I shall refrain from ranting about what a disgusting hack chained scatterlists are. I'll just note that this doesn't make things simpler (see diff). The scatterlists we use can be too large for the stack, so we put them in our device struct and reuse them. But in many cases we don't want to pay the cost of sg_init_table() as we don't know how many elements...

Rather than handing a scatterlist[] and out and in numbers to virtqueue_add_buf(), hand two separate ones which can be chained. I shall refrain from ranting about what a disgusting hack chained scatterlists are. I'll just note that this doesn't make things simpler (see diff). The scatterlists we use can be too large for the stack, so we put them in our device struct and reuse them. But in many cases we don't want to pay the cost of sg_init_table() as we don't know how many elements...

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

From: Longpeng(Mike) <longpeng2 at huawei.com> commit b02989f37fc5e865ceeee9070907e4493b3a21e2 upstream. The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by

From: Longpeng(Mike) <longpeng2 at huawei.com> commit b02989f37fc5e865ceeee9070907e4493b3a21e2 upstream. The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by