[RFC v7 3/6] eal: add exactly-once bit access functions
Morten Brørup
mb at smartsharesystems.com
Tue May 7 21:17:14 CEST 2024
> From: Mattias Rönnblom [mailto:mattias.ronnblom at ericsson.com]
> Sent: Sunday, 5 May 2024 10.38
>
> Add test/set/clear/assign/flip functions which prevents certain
> compiler optimizations and guarantees that program-level memory loads
> and/or stores will actually occur.
>
> These functions are useful when interacting with memory-mapped
> hardware devices.
>
> The "once" family of functions does not promise atomicity and provides
> no memory ordering guarantees beyond the C11 relaxed memory model.
In another thread, Stephen referred to the extended discussion on memory models in Linux kernel documentation:
https://www.kernel.org/doc/html/latest/core-api/wrappers/memory-barriers.html
Unlike the "once" family of functions in this RFC, the "once" family of functions in the kernel also guarantee memory ordering, specifically for memory-mapped hardware devices. The document describes the rationale with examples.
It makes me think that DPDK "once" family of functions should behave similarly.
Alternatively, if the "once" family of functions cannot be generically implemented with a memory ordering that is optimal for all use cases, drop this family of functions, and instead rely on the "atomic" family of functions for interacting with memory-mapped hardware devices.
>
> RFC v7:
> * Fix various minor issues in documentation.
>
> RFC v6:
> * Have rte_bit_once_test() accept const-marked bitsets.
>
> RFC v3:
> * Work around lack of C++ support for _Generic (Tyler Retzlaff).
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
> Acked-by: Morten Brørup <mb at smartsharesystems.com>
> Acked-by: Tyler Retzlaff <roretzla at linux.microsoft.com>
> ---
More information about the dev
mailing list