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 13:43:27 +0000
> Justin Lai <justinlai0215@xxxxxxxxxxx> wrote:
> 
> > 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.
> 
> Ok, your tests are broken for fragmented skb.
> skb_tail_pointer() is the end of the initial fragment, not the
> end of the actual data.
> So you could be adding padding to a full length packet making
> it overlong.
> Somewhere you need to be looking at skb->len.
> Probably with a fast-path check to ignore long packets.
> 

You're right. skb_tail_pointer() only covers the linear area and can
underestimate the transport-data length for non-linear skb.

I will change the transport-data length calculation to use:
trans_data_len = skb->len - skb_transport_offset(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.
> 
> Wait a minute, what stops someone using either of those port numbers
> for something else?
> There are no hard restrictions on the use of UDP port numbers.
> So what does the hardware do with UDP packets to port 319/320 that
> are being used for something else entirely?
> 

If the UDP destination port is 319 or 320, the hardware will identify
the packet as a PTP packet and perform the corresponding PTP
processing.

> > 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.
> 
> Have you checked all the systems that might receive such packets?
> 

Could you clarify what kind of protocol error you are referring to?

>From my understanding, this workaround adds padding at the end of the
frame without modifying the IP or UDP length fields. The
protocol-defined packet length therefore remains unchanged.

This appears similar to Ethernet frame padding, where additional bytes
may exist beyond the protocol-defined payload length. Could you
elaborate on how this case differs from the padding up to the Ethernet
minimum frame size (60 bytes + FCS)?

Thanks,
Justin

> -- David
> 
> >
> > Thanks,
> > Justin