similar to: [PATCHv2] virtio: use smp_XX barriers on SMP

Documentation/memory-barriers.txt says: Mandatory barriers should not be used to control SMP effects, since mandatory barriers unnecessarily impose overhead on UP systems. This rule applies to virtio, so let's do it correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_ring.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)

Documentation/memory-barriers.txt says: Mandatory barriers should not be used to control SMP effects, since mandatory barriers unnecessarily impose overhead on UP systems. This rule applies to virtio, so let's do it correctly. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_ring.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)

Virtio is using memory barriers to control the ordering of references to the vrings on SMP systems. When the guest is compiled with SMP support, virtio is only using SMP barriers in order to avoid incurring the overhead involved with mandatory barriers. Lately, though, virtio is being increasingly used with inter-processor communication scenarios too, which involve running two (separate)

Virtio is using memory barriers to control the ordering of references to the vrings on SMP systems. When the guest is compiled with SMP support, virtio is only using SMP barriers in order to avoid incurring the overhead involved with mandatory barriers. Lately, though, virtio is being increasingly used with inter-processor communication scenarios too, which involve running two (separate)

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

We were cheating with our barriers; using the smp ones rather than the real device ones. That was fine, until virtio-mmio came along, which could be talking to a real device (a non-SMP CPU). Unfortunately, just putting back the real barriers (reverting d57ed95d) causes a performance regression on virtio-pci. In particular, Amos reports netbench's TCP_RR over virtio_net CPU utilization

On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: > This change makes it so that instead of using smp_wmb/rmb which varies > depending on the kernel configuration we can can use dma_wmb/rmb which for > most architectures should be equal to or slightly more strict than > smp_wmb/rmb. > > The advantage to this is that these barriers are available to uniprocessor

virtio ring uses smp_wmb on SMP and wmb on !SMP, the reason for the later being that it might be talking to another kernel on the same SMP machine. This is exactly what __smp_XXX barriers do, so switch to these instead of homegrown ifdef hacks. Cc: Peter Zijlstra <peterz at infradead.org> Cc: Alexander Duyck <alexander.duyck at gmail.com> Signed-off-by: Michael S. Tsirkin <mst at

This change makes it so that instead of using smp_wmb/rmb which varies depending on the kernel configuration we can can use dma_wmb/rmb which for most architectures should be equal to or slightly more strict than smp_wmb/rmb. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

This change makes it so that instead of using smp_wmb/rmb which varies depending on the kernel configuration we can can use dma_wmb/rmb which for most architectures should be equal to or slightly more strict than smp_wmb/rmb. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

Paolo Bonzini <pbonzini at redhat.com> writes: > Il 19/06/2013 10:24, Michael S. Tsirkin ha scritto: >>> > 2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT >>> > specifically for net and block (note the new names). > > So why not a transport feature? Is it just because the SCSI commands > for virtio-blk also require a config space

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/virtio/virtio_ring.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 79e1b29..78428a8 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -35,7 +35,7 @@ #define virtio_rmb(vq) \ do { if

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/virtio/virtio_ring.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 79e1b29..78428a8 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -35,7 +35,7 @@ #define virtio_rmb(vq) \ do { if

Il 20/06/2013 04:40, Rusty Russell ha scritto: > Paolo Bonzini <pbonzini at redhat.com> writes: >> Il 19/06/2013 10:24, Michael S. Tsirkin ha scritto: >>>>> 2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT >>>>> specifically for net and block (note the new names). >> >> So why not a transport feature? Is it just

Il 20/06/2013 04:40, Rusty Russell ha scritto: > Paolo Bonzini <pbonzini at redhat.com> writes: >> Il 19/06/2013 10:24, Michael S. Tsirkin ha scritto: >>>>> 2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT >>>>> specifically for net and block (note the new names). >> >> So why not a transport feature? Is it just

This commit introduces the basic support (without EVENT_IDX) for packed ring. Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> --- drivers/virtio/virtio_ring.c | 444 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 434 insertions(+), 10 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index e164822ca66e..0181e93897be 100644 ---

This commit introduces the support (without EVENT_IDX) for packed ring. Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> --- drivers/virtio/virtio_ring.c | 474 ++++++++++++++++++++++++++++++++++- 1 file changed, 468 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index f5ef5f42a7cf..eb9fd5207a68 100644 ---

This commit introduces the basic support (without EVENT_IDX) for packed ring. Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> --- drivers/virtio/virtio_ring.c | 491 ++++++++++++++++++++++++++++++++++- 1 file changed, 481 insertions(+), 10 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 62d7c407841a..c6c5deb0e3ae 100644 ---

On 2018?04?01? 22:12, Tiwei Bie wrote: > Hello everyone, > > This RFC implements packed ring support for virtio driver. > > The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented > by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html > Minor changes are needed for the vhost code, e.g. to kick the guest. > > TODO: > - Refinements and bug

Use virtioXX_to_cpu and friends for access to all multibyte structures in memory. Note: this is intentionally mechanical. A follow-up patch will split long lines etc. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_ring.c | 89 ++++++++++++++++++++++---------------------- 1 file changed, 45 insertions(+), 44 deletions(-) diff --git