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

[Justin Lai]

David Laight <david.laight.linux@xxxxxxxxx> wrote:
> 
> 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.htm
> > > l
> > >
> > >     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
> >

Hi David,
 
This is an IP fragmented packet, not a fragmented skb.
 
The issue occurs on a non-initial IP fragment whose payload
contains values matching the PTP event/general destination
ports (319/320). The hardware parser incorrectly identifies the
fragment as a PTP packet and attempts further parsing.
 
The workaround does not modify the IP or UDP length fields. The
original protocol headers still describe the actual packet size.
 
Therefore, the protocol-defined payload size remains unchanged.
 
We have tested this workaround and have not observed issues
caused by the additional padding.
 
Thanks,
Justin