search for: x86centricity

...er barrier may be needed, however.) The second memory barrier (write to used->idx before reading avail->flags) is not implicit on x86 because stores 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 th...

...er barrier may be needed, however.) The second memory barrier (write to used->idx before reading avail->flags) is not implicit on x86 because stores 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 th...

....) > > The second memory barrier (write to used->idx before reading avail->flags) > is not implicit on x86 because stores 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. > > Che...

...> > The second memory barrier (write to used->idx before reading avail->flags) is > not implicit on x86 because stores 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. > > C...

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