[PATCH net v2] net: stmmac: restore NET_IP_ALIGN in the RX DMA offset

[Maxime Chevallier]

Hi,

On 8/24/26 14:50, Pascal Kneuper wrote:
> Since the RX path was converted to zero-copy, the page pool page is handed
> to the stack directly as the skb head, and the offset the DMA engine writes
> at is what determines the alignment of the packet headers.
> 
> Before the conversion the payload was copied into an skb obtained from
> napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The
> conversion moved the headroom into stmmac_rx_offset() but did not carry
> over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP
> header now lands misaligned:
> 
>   64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98
> 
> Same for the XDP branch:
> 
>   256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290
> 
> On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses
> even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set.
This patch breaks the stmmac selftests for Jumbo Frames on dwmac1000 :(

Try ethtool -t ethX, before :

27. Jumbo Frame               0

after :

27. Jumbo Frame               -110

I _think_ the issue is that we have buffer start that is not 4-bytes aligned,
the controller can handle that no problem but it still performs a 4-byte
aligned transfer and discards the first 2 bytes of the first DMA word xfer,
and last 2 bytes of the last xfer.

The issue is that that last burst may not fit in the buffer size we specify in
the descriptor, so another descriptor is used to store the last 2 bytes of the
frame, and the first one doesn't have the "last" bit set.

We need to account for that when computing the descriptor size field in
stmmac_rx_buf1_len().

I can try to send a followup, if you can give it try that would be appreciated.

(this is the first bug found with my stmmac CI setup, we'rre getting somwhere !)

Maxime