similar to: [PATCH] Always notify a virtio_ring when it's full

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/virtio.h | 5 +++++ 2 files changed, 13

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/virtio.h | 5 +++++ 2 files changed, 13

>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

>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

If virtio_rng is build as a module, random_data is an address in vmalloc space. As virtio expects guest real addresses, this can cause any kind of funny behaviour, so lets allocate random_data dynamically with kmalloc. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)

If virtio_rng is build as a module, random_data is an address in vmalloc space. As virtio expects guest real addresses, this can cause any kind of funny behaviour, so lets allocate random_data dynamically with kmalloc. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)

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_ring.c | 8 ++++++++ include/linux/virtio.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> --- v2: return true/false instead of 1/0 drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux/virtio.h |

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

This patch allows virtio-blk to release its block queue lock while kicking the host. This improves scalability on SMP guests who would otherwise spin on the lock while another vCPU is kicking the host. This approach can be used for other virtio devices too. It simply splits the virtqueue_kick() operation into a prepare step which requires that the lock be held and the actual notify step which

This patch allows virtio-blk to release its block queue lock while kicking the host. This improves scalability on SMP guests who would otherwise spin on the lock while another vCPU is kicking the host. This approach can be used for other virtio devices too. It simply splits the virtqueue_kick() operation into a prepare step which requires that the lock be held and the actual notify step which

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

The virtio block device holds a lock during I/O request processing. Kicking the virtqueue while the lock is held results in long lock hold times and increases contention for the lock. This patch modifies virtqueue_kick() to optionally release a lock while notifying the host. Virtio block is modified to pass in its lock. This allows other vcpus to queue I/O requests during the time spent

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> >

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> >