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

[Justin Lai]

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.
> >
> > 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.
 
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