Displaying 6 results from an estimated 6 matches for "x86centric".
2015 Apr 07
4
[snabb-devel] Re: memory barriers in virtq.lua?
...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...
2015 Apr 07
4
[snabb-devel] Re: memory barriers in virtq.lua?
...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...
2015 Apr 08
0
[dpdk-dev] [snabb-devel] Re: memory barriers in virtq.lua?
....)
>
> 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.
>
>...
2015 Apr 07
0
[snabb-devel] Re: memory barriers in virtq.lua?
...>
> 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.
>
>...
2015 Jan 27
2
memory barriers in virtq.lua?
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
2015 Jan 27
2
memory barriers in virtq.lua?
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