search for: add_buf

...2 +- 8 files changed, 16 insertions(+), 12 deletions(-) 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 @@ -139,7 +139,7 @@ static bool do_req(struct request_queue } } - if (vblk->vq->vq_ops->add_buf(vblk->vq, vblk->sg, out, in, vbr)) { + if (vblk->vq->vq_ops->add_buf(vblk->vq, vblk->sg, out, in, vbr) < 0) { mempool_free(vbr, vblk->pool); return false; } diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c --- a/drivers/char/h...

...2 +- 8 files changed, 16 insertions(+), 12 deletions(-) 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 @@ -139,7 +139,7 @@ static bool do_req(struct request_queue } } - if (vblk->vq->vq_ops->add_buf(vblk->vq, vblk->sg, out, in, vbr)) { + if (vblk->vq->vq_ops->add_buf(vblk->vq, vblk->sg, out, in, vbr) < 0) { mempool_free(vbr, vblk->pool); return false; } diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c --- a/drivers/char/h...

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux/vi...

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux/vi...

On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote: > This patch is a subset of an already upstream patch, but this portion > is useful in earlier releases. > > Please consider for the 2.6.32 and 2.6.33 stable trees. > > If the add_buf operation fails, indicate failure to the caller. > > Signed-off-by: Bruce Rogers <brogers at novell.com> > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Actually this code looks strange: Note that add_buf inicates out of memory condition with a positive return value...

On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote: > This patch is a subset of an already upstream patch, but this portion > is useful in earlier releases. > > Please consider for the 2.6.32 and 2.6.33 stable trees. > > If the add_buf operation fails, indicate failure to the caller. > > Signed-off-by: Bruce Rogers <brogers at novell.com> > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Actually this code looks strange: Note that add_buf inicates out of memory condition with a positive return value...

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

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

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- v2: return true/false instead of 1/0 drivers/virtio/virtio...

This helper returns 1 if a call to add_buf will not fail with -ENOSPC. This will help callers that do while(1) { alloc() if (add_buf()) { free(); break; } } This will result in one less alloc/free exercise. Signed-off-by: Amit Shah <amit.shah at redhat.com> --- v2: return true/false instead of 1/0 drivers/virtio/virtio...

...ions for this virtqueue. + * @cb: set by the driver for callbacks. + * @priv: private pointer for the driver to use. + */ +struct virtqueue { + struct virtqueue_ops *ops; + bool (*cb)(struct virtqueue *vq); + void *priv; +}; + +/** + * virtqueue_ops - operations for virtqueue abstraction layer + * @add_buf: expose buffer to other end + * vq: the struct virtqueue we're talking about. + * sg: the description of the buffer(s). + * out_num: the number of sg readable by other side + * in_num: the number of sg which are writable (after readable ones) + * data: the token identifying the buffer. + *...

...ions for this virtqueue. + * @cb: set by the driver for callbacks. + * @priv: private pointer for the driver to use. + */ +struct virtqueue { + struct virtqueue_ops *ops; + bool (*cb)(struct virtqueue *vq); + void *priv; +}; + +/** + * virtqueue_ops - operations for virtqueue abstraction layer + * @add_buf: expose buffer to other end + * vq: the struct virtqueue we're talking about. + * sg: the description of the buffer(s). + * out_num: the number of sg readable by other side + * in_num: the number of sg which are writable (after readable ones) + * data: the token identifying the buffer. + *...

...correct confusion noted by Rusty - rewrite patch 3 along the lines suggested by Rusty note: it's not exactly the same but I hope it's close enough, the main difference is that mine does limited polling even in the unlikely xmit failure case. - added a patch to not return capacity from add_buf it always looked like a weird hack Michael S. Tsirkin (4): virtio_ring: add capacity check API virtio_net: fix tx capacity checks using new API virtio_net: limit xmit polling Revert "virtio: make add_buf return capacity remaining: drivers/net/virtio_net.c | 111 ++++++++++++++...

...correct confusion noted by Rusty - rewrite patch 3 along the lines suggested by Rusty note: it's not exactly the same but I hope it's close enough, the main difference is that mine does limited polling even in the unlikely xmit failure case. - added a patch to not return capacity from add_buf it always looked like a weird hack Michael S. Tsirkin (4): virtio_ring: add capacity check API virtio_net: fix tx capacity checks using new API virtio_net: limit xmit polling Revert "virtio: make add_buf return capacity remaining: drivers/net/virtio_net.c | 111 ++++++++++++++...

>From f582caf612b446e42f1e80d5ef12c5b7322efd03 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Mon, 28 Jan 2008 02:09:48 +0200 Subject: [PATCH] virtio_net tx performance fix There was a problem with the location of the notify call in add_buff function: When VRING_USED_F_NO_NOTIFY is set, the host does not kick the guest when packets were transmitted, as a result the guest runs out of tx buffers sometimes. This is fine but the problem lies when add_buf fails, it called notify and the host sends all the pending tx pkts. When enable_cb wa...

>From f582caf612b446e42f1e80d5ef12c5b7322efd03 Mon Sep 17 00:00:00 2001 From: Dor Laor <dor.laor@qumranet.com> Date: Mon, 28 Jan 2008 02:09:48 +0200 Subject: [PATCH] virtio_net tx performance fix There was a problem with the location of the notify call in add_buff function: When VRING_USED_F_NO_NOTIFY is set, the host does not kick the guest when packets were transmitted, as a result the guest runs out of tx buffers sometimes. This is fine but the problem lies when add_buf fails, it called notify and the host sends all the pending tx pkts. When enable_cb wa...

...++++++++++++++++++----------------- 1 file changed, 87 insertions(+), 43 deletions(-) diff --git a/include/linux/virtio.h b/include/linux/virtio.h --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -26,52 +26,22 @@ struct virtqueue { }; /** - * operations for virtqueue - * virtqueue_add_buf: expose buffer to other end - * vq: the struct virtqueue we're talking about. - * sg: the description of the buffer(s). - * out_num: the number of sg readable by other side - * in_num: the number of sg which are writable (after readable ones) - * data: the token identifying the buffer. - * gfp:...

...++++++++++++++++++----------------- 1 file changed, 87 insertions(+), 43 deletions(-) diff --git a/include/linux/virtio.h b/include/linux/virtio.h --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -26,52 +26,22 @@ struct virtqueue { }; /** - * operations for virtqueue - * virtqueue_add_buf: expose buffer to other end - * vq: the struct virtqueue we're talking about. - * sg: the description of the buffer(s). - * out_num: the number of sg readable by other side - * in_num: the number of sg which are writable (after readable ones) - * data: the token identifying the buffer. - * gfp:...

...++++++++++++++++++----------------- 1 file changed, 87 insertions(+), 43 deletions(-) diff --git a/include/linux/virtio.h b/include/linux/virtio.h --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -26,52 +26,22 @@ struct virtqueue { }; /** - * operations for virtqueue - * virtqueue_add_buf: expose buffer to other end - * vq: the struct virtqueue we're talking about. - * sg: the description of the buffer(s). - * out_num: the number of sg readable by other side - * in_num: the number of sg which are writable (after readable ones) - * data: the token identifying the buffer. - * gfp:...

...++++++++++++++++++----------------- 1 file changed, 87 insertions(+), 43 deletions(-) diff --git a/include/linux/virtio.h b/include/linux/virtio.h --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -26,52 +26,22 @@ struct virtqueue { }; /** - * operations for virtqueue - * virtqueue_add_buf: expose buffer to other end - * vq: the struct virtqueue we're talking about. - * sg: the description of the buffer(s). - * out_num: the number of sg readable by other side - * in_num: the number of sg which are writable (after readable ones) - * data: the token identifying the buffer. - * gfp:...