Re: [PATCH v5 net-next 2/2] net: hns3: fix GSO_ECN flag setting in the RX path
Jijie Shao <[email protected]>
| Newsgroups | org.kernel.vger.linux-rdma,dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.linux-doc,org.kernel.vger.linux-kselftest,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
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