cpu reordering / missing memory fences issues?

[danielealbano]

I was going over the code and I was wondering if the Fill, Transmit, Receive, etc. functions are not of risk of corrupting the state of the ring buffers, they don't seem to use any protection against cpu reordering nor using memory fences (they are commented out).

Taking into account that there is no guarantee that a given goroutine will be executed on the same core that is used for any given queueid, isn't there the risk that the increment of the offset in the ring queue will be carried out before writing the data and that a context switch will occur in that moment with the driver running on the same core trying to access these information and getting garbage instead?

For instance, libxdp to avoid this issue uses atomic ops, e.g.
https://github.com/xdp-project/xdp-tools/blob/7fe0a0946a38a26d4196bc3819fc43227e0a9ddd/headers/xdp/xsk.h#L135

Probably in the code would be enough to:

• move the increment of the offset of the ring buffer(s) after the for loop issuing only 1 store memory fence before updating the ring buffer counter (even if the kernel realises that there is stuff to send
• move the reading of the offset of the ring buffer(s) before the for loop preceeded by a load memory fence

These two minor changes will guarantee that if the kernel tries to access something that it's told it's available, the data will actually be there.