RE: [PATCH v5 net-next 2/2] net: hns3: fix GSO_ECN flag setting in the RX path

-----Original Message-----
From: Jijie Shao <[email protected]>
Sent: Wednesday, August 19, 2026 4:52 AM
To: Jakub Kicinski <[email protected]>; Chia-Yu Chang (Nokia) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Koen De Schepper (Nokia) <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH v5 net-next 2/2] net: hns3: fix GSO_ECN flag setting in the RX path


> on 2026/8/13 6:59, Jakub Kicinski wrote:
> > On Wed, 12 Aug 2026 10:35:25 +0000 Chia-Yu Chang (Nokia) wrote:
> >>> Tested on hns3 HW (2x 100G, direct cable, openEuler 24.03, kernel 7.2.0-rc6).
> >>>
> >>> tcpdump confirms HW GRO zeroes IP ToS: aggregated (>MTU) packets carry tos 0x0, while non-aggregated packets keep their ToS/ECN marks - so the zeroing is done by HW GRO, not the sender. Before patch, CWR packets had SKB_GSO_TCP_ECN set (0x5 = SKB_GSO_TCPV4 | SKB_GSO_TCP_ECN). After patch, all GRO events gso_type=0x1 (SKB_GSO_TCPV4 only), no 0x5 observed.
> >>>
> >>> Tested-by: Jijie Shao <[email protected]>
> >> Thanks Jijie for confirmation, I will submit to net in the next round.
> > Hold on.. Sounds like hns3 zeros ToS out (?!)
> >
> > This would be invalid and illegal for HW-GRO. If hns3 nukes crucial IP
> > header fields it should probably be advertising LRO not HW-GRO in the
> > first place.
>
> Your assessment is correct - HW GRO on hns3 does NOT zero IP ToS.
>
> My earlier Tested-by claiming "HW GRO zeroes IP ToS" was wrong. The
> tos=0x0 I observed was caused by a test methodology error: I used
> iperf3 with --tos but did not set net.ipv4.tcp_ecn=1, so the sender's kernel TCP stack cleared the ECN bits before the packets hit the wire.
> I mistakenly attributed this TX-side clearing to HW GRO.
>
> I have retested with tesgine (direct packet construction, bypassing the kernel TCP stack) and confirmed:
>    - HW GRO preserves IP ToS - each aggregate group retains the head
>      packet's ToS value (verified with 0x00/0x02/0x03/0x10/0xB8)
>    - HW GRO segments flows by ToS boundaries - any ToS change (DSCP or
>      ECN bits) terminates the current aggregate group
>    - ECN signals are intact - CE packets (tos=0x03) are delivered
>      independently with the CE mark preserved
>
> hns3 HW GRO is behaving correctly. Sorry for the confusion caused by my earlier report.
>
> Full test details in my correction reply to the patch 2/2 thread:
> https://lore.kernel.org/all/[email protected]/
>
> Regards,
> Jijie Shao

Hi Jijie,

Thank you for the update, but I'd like to follow up on the CWR flag issue.
How does your HW-GRO determine whether to flush packages related to the CWR flag?

Currently, the software approach (see the test case in 6f74bc8b6e8d) flushes only when the CWR value is different.
This behavior has changed since patch  ab4c8b6f7fcb.

Thanks.
Chia-Yu