Re: [PATCH net-next v4 6/8] net: bcmgenet: pad transmit frames out of the packet ready window

[Florian Fainelli]

On 10/12/26 02:00, Nicolai Buchwitz wrote:
> A frame that ends a few bytes past the transmit packet ready threshold
> stops the transmitter as soon as a shorter frame follows. Tx DMA then
> refuses to halt, so every later bcmgenet_init_dma() fails and the interface
> cannot be opened again. IP fragmentation generates that pattern on every
> datagram, full frames and a short tail.
>
> The window starts one byte past the threshold and widens with it. On a v5
> it ends 28, 32 and 46 bytes past thresholds of 2560, 3584 and 3840. Link
> speed makes no difference. Pad frames landing in it to 64 bytes past the
> threshold, rounded up from the widest window seen. The threshold goes by
> skb->len, it does not count the 64 byte status block the driver prepends
> later, measured at 0x80 and 0xf0.
>
> Padding must not push a frame past what the peer accepts. Linux does not
> bound how many VLAN tags a frame carries, so measure against the longest
> frame the MAC has to accept rather than a tag count. For the MTUs where
> such a frame would land in the window, lower the threshold instead. All
> other MTUs keep the register maximum, and at or below ETH_DATA_LEN the
> reset value stays, so an unchanged MTU keeps the threshold it always had.
> Nothing reaches either path until a later patch raises dev->max_mtu.
>
> The MAC inserts a checksum only into a frame it holds in full. A frame
> longer than the threshold gets its checksum computed in software.
> ether_setup() leaves IFF_TX_SKB_SHARING set, so unshare before either path
> writes to the frame.
>
> The padding is appended to the frame, so a protocol that locates data from
> the end of it, such as a DSA tail tag or a PRP trailer, sees the zeros
> instead. Nothing below an MTU of 3809 is affected, since no frame reaches
> the window there. Above it the alternatives are dropping the frame or
> leaving the transmitter stalled.
>
> Tested-by: Pierre-Marin Leclercq <pierremarinleclercq88@xxxxxxxxx>
> Signed-off-by: Nicolai Buchwitz <nb@xxxxxxxxxxx>

Reviewed-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx>
--
Florian