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-doc,dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-rdma,org.kernel.vger.netdev
Message-ID <[email protected]>
on 2026/8/5 5:35, [email protected] wrote:
> From: Chia-Yu Chang <[email protected]>
>
> Currently, the hns3 Rx path sets the SKB_GSO_TCP_ECN flag when a TCP
> segment with the CWR flag set is received. This is incorrect because
> the hns3 hardware GRO resets the IP ToS byte to 0 during packet
> aggregation. Consequently, no valid ECN signals are carreid, meaning
> that it cannot support RFC3168 ECN or Accurate ECN protocols. Setting
> SKB_GSO_TCP_ECN or SKB_GSO_TCP_ACCECN under these conditions misleads
> the upper network stack.
>
> Fix this by removing the incorrect SKB_GSO_TCP_ECN flag assignment
> in hns3_gro_complete().


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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.