Re: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug

[David Laight]

On Thu, 4 Jun 2026 08:33:51 +0000
Justin Lai <justinlai0215@xxxxxxxxxxx> wrote:

> Andrew Lunn <andrew@xxxxxxx> wrote:
> > 
> > On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote:  
> > > The hardware parser incorrectly interprets 319/320 in a short IP
> > > fragmented UDP packet payload as standard PTP destination ports and
> > > treats the fragment as a PTP packet for further parsing.

Is that a packet that has been segmented by IP, or one where the skb
is fragmented enough that the data in the header is too short?
I thought that IPv4 required an mtu of 128 bytes (ish) and IPv6 somewhat
larger - so I don't see how that is a problem.

If the skb is fragmented then you need to move data into the header
not pad the frame.

If the hardware really is broken then I suspect you need to disable
the feature and suffer the consequences.

> > >
> > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the remaining
> > > data is insufficient for further parsing and causes hardware TX hang.  
> > 
> > Where does RTASE_SHORT_PKT_THRESH come into this?
> > 
> > RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding up to
> > 60 bytes, plus FCS. There are not many such packets, so why both this all the
> > complexity and just pad all small packets? Do you have any performance
> > numbers which show the complexity is worth it?
> >   
> > > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN
> > > before transmitting to avoid triggering the hardware issue.
> > >
> > > Signed-off-by: Justin Lai <justinlai0215@xxxxxxxxxxx>  
> > 
> > Is this a Fix? Please add a Fixes: tag. And base it on net.
> > 
> > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> > 
> >     Andrew
> > 
> > ---
> > pw-bot: cr  
> 
> Hi Andrew,
>  
> RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding
> threshold. It is the minimum transport-data length required by
> the hardware parser after the packet is incorrectly detected as
> a PTP packet.
>  
> Therefore, this workaround needs to pad the packets which can
> trigger the hardware issue, rather than just padding packets to
> the Ethernet minimum frame size.

Is that a longer length?
Excessive frame padding (beyond 60+FCS) can be treated as a protocol error.

-- David

>  
> I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I
> will remove it in the next revision.
>  
> Yes, this is a fix. I will add a Fixes tag and repost it
> against the net tree.
>  
> Thanks,
> Justin
>