search for: librte_vhost

...ores are reordered after loads. So an explicit hardware memory barrier is needed. I hope that is a correct assessment of the situation. (Forgive my x86centricity, I am sure that seems very foreign to kernel hackers.) If this assessment is correct then the DPDK developers might also want to review librte_vhost/vhost_rxtx.c and consider adding a hardware memory barrier between writing used->idx and reading avail->flags. Cheers, -Luke P.S. I notice that the Linux virtio-net driver does not seem to tolerate spurious interrupts, even though the Virtio 1.0 spec requires this ("must"). On 3.1...

...ores are reordered after loads. So an explicit hardware memory barrier is needed. I hope that is a correct assessment of the situation. (Forgive my x86centricity, I am sure that seems very foreign to kernel hackers.) If this assessment is correct then the DPDK developers might also want to review librte_vhost/vhost_rxtx.c and consider adding a hardware memory barrier between writing used->idx and reading avail->flags. Cheers, -Luke P.S. I notice that the Linux virtio-net driver does not seem to tolerate spurious interrupts, even though the Virtio 1.0 spec requires this ("must"). On 3.1...

...kes people unhappy, since the functionality in question is setup- > time only. Agreed, we don't see dependency on kernel driver is a problem. mdev based vhost backend (this patch set) is independent with vhost-user extension patch set. In fact, there're a few vhost-user providers, DPDK librte_vhost is one of them. FD.IO/VPP and snabbswitch have their own vhost-user providers. So I can't agree on vhost-user extension patch depends on DPDK backend. But anyway, that's the topic of another mail thread. > > As others said, we do not need to go overeboard. A couple of small vendor-...

...o an > explicit hardware memory barrier is needed. > > I hope that is a correct assessment of the situation. (Forgive my > x86centricity, I am sure that seems very foreign to kernel hackers.) > > If this assessment is correct then the DPDK developers might also want to > review librte_vhost/vhost_rxtx.c and consider adding a hardware memory > barrier between writing used->idx and reading avail->flags. > > Cheers, > -Luke > > P.S. I notice that the Linux virtio-net driver does not seem to tolerate > spurious interrupts, even though the Virtio 1.0 spec require...

...an explicit > hardware memory barrier is needed. > > I hope that is a correct assessment of the situation. (Forgive my > x86centricity, I am sure that seems very foreign to kernel hackers.) > > If this assessment is correct then the DPDK developers might also want to > review librte_vhost/vhost_rxtx.c and consider adding a hardware memory barrier > between writing used->idx and reading avail->flags. > > Cheers, > -Luke I agree, this looks like a bug in dpdk. > P.S. I notice that the Linux virtio-net driver does not seem to tolerate > spurious interrupts, e...

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks, -- MST

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks, -- MST

> -----Original Message----- > From: Paolo Bonzini [mailto:pbonzini at redhat.com] > Sent: Tuesday, April 10, 2018 3:52 PM > To: Bie, Tiwei <tiwei.bie at intel.com>; Jason Wang <jasowang at redhat.com> > Cc: mst at redhat.com; alex.williamson at redhat.com; ddutile at redhat.com; > Duyck, Alexander H <alexander.h.duyck at intel.com>; virtio-dev at lists.oasis-