On Tue, 2 Mar 2021 at 11:23, Toke Høiland-Jørgensen wrote:
>
> Björn Töpel writes:
>
> > On 2021-03-01 17:08, Toke Høiland-Jørgensen wrote:
> >> Björn Töpel writes:
> >>
> >>> From: Björn Töpel
> >>>
> >>> Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
> >>> kernel-side. By updat
Björn Töpel writes:
> On 2021-03-01 17:08, Toke Høiland-Jørgensen wrote:
>> Björn Töpel writes:
>>
>>> From: Björn Töpel
>>>
>>> Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
>>> kernel-side. By updating the rings for load-acquire/store-release
>>> semantics, the full barrier o
On 2021-03-01 17:08, Toke Høiland-Jørgensen wrote:
Björn Töpel writes:
From: Björn Töpel
Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
kernel-side. By updating the rings for load-acquire/store-release
semantics, the full barrier on the consumer side can be replaced with
i
Björn Töpel writes:
> From: Björn Töpel
>
> Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
> kernel-side. By updating the rings for load-acquire/store-release
> semantics, the full barrier on the consumer side can be replaced with
> improved performance as a nice side-effect.
>
>
From: Björn Töpel
Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
kernel-side. By updating the rings for load-acquire/store-release
semantics, the full barrier on the consumer side can be replaced with
improved performance as a nice side-effect.
Note that this change does *not* req
