Ethernet net_pkt buffers - cache coherency

[stujamac]

I have been working through porting the the Synopsys DWMAC drivers to work with an NXP Chip (MIMXRT1176) and I've been bitten a couple of times by cache coherency issues on the ARM M7 as it requires 32 byte aligned memory for DMA transfers to be cached correctly (this is the cache line size). Looking into the creation of the rx_pkts & tx_pkts buffers, these use the K_MEM_SLAB_DEFINE macro and specifies the alignment to be 4 bytes.

K_MEM_SLAB_DEFINE(rx_pkts, sizeof(struct net_pkt), CONFIG_NET_PKT_RX_COUNT, 4);
K_MEM_SLAB_DEFINE(tx_pkts, sizeof(struct net_pkt), CONFIG_NET_PKT_TX_COUNT, 4);

I'm not sure whether this is an issue or not, but these buffers can be accessed by DMA, so should be flushed/invalidated as required to ensure correct data is present in memory. However if the buffers are created aligned on 4 byte boundaries on a system with 32 byte cache lines, there is a fairly good likelihood that data that is not currently expecting to be changed, gets flushed or invalidated when it shouldn't be?

I'm not sure if this is an issue as all writes to the TX buffers should be from the CPU? Or whether it has potential to cause unexpected issues - especially at boundaries of the buffer, where other data may get affected by a flush/invalidation of a cache line.

Would it make more sense to wrap the slab definitions in a check to see what size the cache lines are - not that I can see a configuration to set this?

Sorry if this seems like a rambling - any thoughts appreciated.

[jukkar]

@stujamac You could propose a patch that adds a way (perhaps via a Kconfig option) to adjust the alignment for those slabs. IMHO there should be no issue to change the alignment.

[stujamac]

@jukkar Thank you for your feedback - I will pull something together - I was thinking of maybe using a Kconfig option - I will tidy up my current modifications it up and submit it.
Shall I leave this ticket open until I can add a link to the patch?

[jukkar]

You could mark this as resolved and just send a PR. As this is not a bug report but a discussion, it does not really matter to leave this open.