Re: [PATCH v5 net 2/4] net: enetc: do not rely on mEMAC hardware frame padding

[Vladimir Oltean]

Hi David,

On Thu, Oct 22, 2026 at 09:48:03PM +0100, David Laight wrote:
> > > UDP segmentation has to use IP fragmentation and that is usually done because
> > > the interface/path mtu is too short.  
> > 
> > In my testing, UDP GSO does not generate IP fragments, but rather, each
> > UDP segment is its own datagram.
> 
> Hmmm....
> I wouldn't have thought that was generally useful.
> Losing data from random points in a connection is going to be hard
> to recover from.
> I guess that it why it is per-socket rather than system wide.
> I mean, you can run telnet over udp and just hope no packets get lost.

After a very quick search, I think the main use case for UDP GSO was QUIC:
https://lpc.events/event/2/contributions/106/

In turn, QUIC has its own loss detection and congestion control, though
I don't exactly know how they do it.

An interesting statement I found in that paper is:

"The gso size parameter communicates the length of the
payload without network or transport layer headers. A
gso_size all the way down to 1 is a valid choice. A value of 0
effectively disables GSO."

> > Are you thinking of UDP Fragmentation Offload instead? As per
> > https://docs.kernel.org/networking/segmentation-offloads.html#udp-fragmentation-offload
> > this is deprecated and AFAIU not what this is about.
> 
> That is the sort of UDP segmentation I thought made sense.
> OTOH I think the main user of it was NFS, but even then 8k datagrams
> were actually so unreliable it was often much better to tell UDP to fragment
> the 8k blocks into 1k chunks (IIRC that was a mount option).
> 
> > 
> > The docs do also explicitly say that UDP Segmentation Offload does not
> > generate IP fragments.
> > 
> > > But there is a minimum mtu for IPv4 of (something like) 128 bytes, and
> > > it may be invalid to fragment into smaller pieces.  
> > 
> > I have no idea what you are referring to, here, with the minimum MTU of
> > 128 bytes.
> 
> The correct number is probably 68 (min max size of an IPv4 fragment) rather
> than 576 (for a reassembled message) - I think both are from the start of
> the IP headers.
> That means there is no sane reason to fragment anything so small that
> ethernet frames get padded.
> 
> > 
> > > > Sensible or not, it is possible, and I did generate a test program using
> > > > an LLM to confirm this.
> > > > 
> > > > Regardless of that, the last segment of a GSO super-skb would need
> > > > padding anyway, because even with a 'normal' TCP MSS, the skb->len
> > > > modulo gso_size could still result in a last frame < ETH_ZLEN. Padding
> > > > just the GSO super-skb, as I did in v3, would also not fix this.  
> > > 
> > > True, but that is a different check to the one you did.  
> > 
> > So what is your suggestion for the driver to do?
> 
> Clearly you need to allow a BD for padding if the final fragment is short.
> That is one extra BD for the entire frame, that same as a non-GSO message.
> You could leave the hardware padding 'stupidly short' gso fragments.

Leaving the hardware to pad 'stupidly short' GSO segments is definitely
not an option. Given my context: the hardware adds some non-zero padding
bytes, and customers suspect the MAC is leaking device-internal memories,
this is exactly the kind of attack vector user space could use to
exfiltrate data (even if not practically useful, this is a valid API).
The request has been explicit to avoid this if we can't prove the origin
of the non-zero padding bytes.

Now, having that said, I noticed that Joe Damato had this exact problem
a few weeks ago in bnxt:
https://lore.kernel.org/netdev/20261009215426.2377946-1-joe@xxxxxxx/

It looks like he did something there in ndo_features_check() to simply
clear NETIF_F_GSO_MASK for the 'stupidly short' gso_size, so that
they're segmented in the stack and appear as non-GSO during driver xmit.
But this is just a superficial analysis. I'll have to see how much
complexity it adds to do something similar in enetc, vs just adding a
padding BD for each GSO segment/datagram myself.

> I assume the driver is building the ethernet/IP/UDP/TDP header so that
> will be one buffer and not hit the 'fragmented after 14 bytes' issue.

Yes, the header buffer < ENETC_MIN_BUFF_SIZE is not the problem here,
just general MAC padding contents. This is why I split the patches the
way I did: first never allow the MAC to pad by itself, then address the
remaining buffer geometry issues that ENETC doesn't tolerate (this
causes a separate, unrelated problem, that the software padding partly
fixes and partly doesn't).

> > > > > But does this code allow for the VLAN tag that you forgot about in the
> > > > > other patch?    
> > > > 
> > > > Not sure I understand your concern here? Is it that with VLAN TX
> > > > insertion offload, we pad "too much" (i.e. to ETH_ZLEN, then the NIC
> > > > pushes an extra VLAN_HLEN)? I'm not sure that's a problem..  
> > > 
> > > That is a problem, VLAN packets should only be padded to 64 bytes
> > > including the VLAN header and CRC.
> > > However such overlong packets are likely to be tolerated because
> > > an ethernet switch can add a VLAN header before forwarding a packet
> > > and it can't know whether a short packet is padded.  
> > 
> > Well, if it's a theoretical problem but it's not a practical problem,
> > I'd prefer leaving it as is.
> > 
> > Since eth_skb_pad() itself is unaware of VLAN TX offloads, I'd be
> > opening myself up to an endless rabbit hole ("why didn't you fix this
> > in eth_skb_pad()? It's a generic problem." followed by
> > "changing eth_skb_pad() broke 20 drivers!")...
> > 
> > Unless it's very clear why I'd be doing this, I'd very much prefer not to.
> 
> VLAN headers came in after I stopped writing ethernet drivers!
> I think systems have to tolerate extra padding when a VLAN header is present.
> 
> David
> 
>