Displaying 20 results from an estimated 11000 matches similar to: "[RFC] virtio: Support releasing lock during kick"
2011 Nov 03
1
[PATCH 2 of 5] virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf
Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -171,7 +171,7 @@ static bool
2011 Nov 03
1
[PATCH 2 of 5] virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf
Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -171,7 +171,7 @@ static bool
2010 Apr 12
10
[PATCH 0/6] virtio: virtqueue ops cleanup
virtqueue ops were introduced in the hope that we'll
have multiple implementations besides virtio_ring,
but none have surfaced so far, and given that
existing virtio ring is deployed in production
we are likely stuck with it now, so this layer just
adds complexity and overhead.
Further, the need to pass vq twice to each call
(as in dev->vq->vq_ops->kick(dev->vq) ) adds potential
2010 Apr 12
10
[PATCH 0/6] virtio: virtqueue ops cleanup
virtqueue ops were introduced in the hope that we'll
have multiple implementations besides virtio_ring,
but none have surfaced so far, and given that
existing virtio ring is deployed in production
we are likely stuck with it now, so this layer just
adds complexity and overhead.
Further, the need to pass vq twice to each call
(as in dev->vq->vq_ops->kick(dev->vq) ) adds potential
2013 Jan 02
0
[PATCH] virtio: use chained scatterlists
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
2013 Jan 02
0
[PATCH] virtio: use chained scatterlists
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
2013 Feb 19
24
[PATCH 00/16] virtio ring rework.
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:
2013 Feb 19
24
[PATCH 00/16] virtio ring rework.
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:
2013 Mar 18
28
[PATCH 00/22] virtqueue_add_sgs, virtqueue_add_outbuf, virtqueue_add_inbuf
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
2013 Mar 18
28
[PATCH 00/22] virtqueue_add_sgs, virtqueue_add_outbuf, virtqueue_add_inbuf
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
2013 Feb 12
12
[PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes
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, and generic
2013 Feb 12
12
[PATCH 0/9] virtio: new API for addition of buffers, scatterlist changes
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, and generic
2012 Dec 07
2
[PATCH 0/1] virtio: console: regression in virtqueue_add_buf() change
Hi Rusty,
The linux-next kernel was failing my virtio-console test suite for a
while. I looked into it today, and it's due to the
virtqueue_add_buf() change that doesn't return > 0 values anymore. I
found your commit that adjusts virtio_console.c, but you missed one
instance where the return value mattered, and as a result not enough
buffers were queued for the host to send in data.
2012 Dec 07
2
[PATCH 0/1] virtio: console: regression in virtqueue_add_buf() change
Hi Rusty,
The linux-next kernel was failing my virtio-console test suite for a
while. I looked into it today, and it's due to the
virtqueue_add_buf() change that doesn't return > 0 values anymore. I
found your commit that adjusts virtio_console.c, but you missed one
instance where the return value mattered, and as a result not enough
buffers were queued for the host to send in data.
2011 Nov 03
2
[PATCH 5 of 5] virtio: expose added descriptors immediately
A virtio driver does virtqueue_add_buf() multiple times before finally
calling virtqueue_kick(); previously we only exposed the added buffers
in the virtqueue_kick() call. This means we don't need a memory
barrier in virtqueue_add_buf(), but it reduces concurrency as the
device (ie. host) can't see the buffers until the kick.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
2011 Nov 03
2
[PATCH 5 of 5] virtio: expose added descriptors immediately
A virtio driver does virtqueue_add_buf() multiple times before finally
calling virtqueue_kick(); previously we only exposed the added buffers
in the virtqueue_kick() call. This means we don't need a memory
barrier in virtqueue_add_buf(), but it reduces concurrency as the
device (ie. host) can't see the buffers until the kick.
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
2013 Feb 07
11
[RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
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
2013 Feb 07
11
[RFC PATCH 0/8] virtio: new API for addition of buffers, scatterlist changes
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
2012 Aug 30
2
[PATCH v3 1/2] virtio-ring: Use threshold for switching to indirect descriptors
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect
descriptors even if we have plenty of space in the ring. This means that
we take a performance hit at all times due to the overhead of creating
indirect descriptors.
Instead, use it only after we're below a configurable offset.
Signed-off-by: Sasha Levin <levinsasha928 at gmail.com>
---
drivers/block/virtio_blk.c
2012 Aug 30
2
[PATCH v3 1/2] virtio-ring: Use threshold for switching to indirect descriptors
Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will use indirect
descriptors even if we have plenty of space in the ring. This means that
we take a performance hit at all times due to the overhead of creating
indirect descriptors.
Instead, use it only after we're below a configurable offset.
Signed-off-by: Sasha Levin <levinsasha928 at gmail.com>
---
drivers/block/virtio_blk.c