[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<PAXPR07MB7984A4151F79A09D8D418A4FA398A@PAXPR07MB7984.eurprd07.prod.outlook.com>
Date: Wed, 4 Feb 2026 07:41:08 +0000
From: "Chia-Yu Chang (Nokia)" <chia-yu.chang@...ia-bell-labs.com>
To: Parav Pandit <parav@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"shaojijie@...wei.com" <shaojijie@...wei.com>, "shenjian15@...wei.com"
<shenjian15@...wei.com>, "salil.mehta@...wei.com" <salil.mehta@...wei.com>,
Mark Bloch <mbloch@...dia.com>, Saeed Mahameed <saeedm@...dia.com>,
"leon@...nel.org" <leon@...nel.org>, "eperezma@...hat.com"
<eperezma@...hat.com>, "brett.creeley@....com" <brett.creeley@....com>,
"jasowang@...hat.com" <jasowang@...hat.com>, "virtualization@...ts.linux.dev"
<virtualization@...ts.linux.dev>, "mst@...hat.com" <mst@...hat.com>,
"xuanzhuo@...ux.alibaba.com" <xuanzhuo@...ux.alibaba.com>,
"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
<edumazet@...gle.com>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "corbet@....net" <corbet@....net>,
"horms@...nel.org" <horms@...nel.org>, "dsahern@...nel.org"
<dsahern@...nel.org>, "kuniyu@...gle.com" <kuniyu@...gle.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "dave.taht@...il.com" <dave.taht@...il.com>,
"jhs@...atatu.com" <jhs@...atatu.com>, "kuba@...nel.org" <kuba@...nel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>, "jiri@...nulli.us"
<jiri@...nulli.us>, "davem@...emloft.net" <davem@...emloft.net>,
"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "donald.hunter@...il.com"
<donald.hunter@...il.com>, "ast@...erby.net" <ast@...erby.net>,
"liuhangbin@...il.com" <liuhangbin@...il.com>, "shuah@...nel.org"
<shuah@...nel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "ij@...nel.org" <ij@...nel.org>,
"ncardwell@...gle.com" <ncardwell@...gle.com>, "Koen De Schepper (Nokia)"
<koen.de_schepper@...ia-bell-labs.com>, "g.white@...lelabs.com"
<g.white@...lelabs.com>, "ingemar.s.johansson@...csson.com"
<ingemar.s.johansson@...csson.com>, "mirja.kuehlewind@...csson.com"
<mirja.kuehlewind@...csson.com>, "cheshire@...le.com" <cheshire@...le.com>,
"rs.ietf@....at" <rs.ietf@....at>, "Jason_Livingood@...cast.com"
<Jason_Livingood@...cast.com>, "vidhi_goel@...le.com" <vidhi_goel@...le.com>
Subject: RE: [PATCH v3 net-next 1/3] net: update comments for SKB_GSO_TCP_ECN
and SKB_GSO_TCP_ACCECN
> -----Original Message-----
> From: Parav Pandit <parav@...dia.com>
> Sent: Wednesday, February 4, 2026 3:54 AM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@...ia-bell-labs.com>; Tariq Toukan <tariqt@...dia.com>; linux-rdma@...r.kernel.org; shaojijie@...wei.com; shenjian15@...wei.com; salil.mehta@...wei.com; Mark Bloch <mbloch@...dia.com>; Saeed Mahameed <saeedm@...dia.com>; leon@...nel.org; eperezma@...hat.com; brett.creeley@....com; jasowang@...hat.com; virtualization@...ts.linux.dev; mst@...hat.com; xuanzhuo@...ux.alibaba.com; pabeni@...hat.com; edumazet@...gle.com; linux-doc@...r.kernel.org; corbet@....net; horms@...nel.org; dsahern@...nel.org; kuniyu@...gle.com; bpf@...r.kernel.org; netdev@...r.kernel.org; dave.taht@...il.com; jhs@...atatu.com; kuba@...nel.org; stephen@...workplumber.org; xiyou.wangcong@...il.com; jiri@...nulli.us; davem@...emloft.net; andrew+netdev@...n.ch; donald.hunter@...il.com; ast@...erby.net; liuhangbin@...il.com; shuah@...nel.org; linux-kselftest@...r.kernel.org; ij@...nel.org; ncardwell@...gle.com; Koen De Schepper (Nokia) <koen.de_schepper@...ia-bell-labs.com>; g.white@...lelabs.com; ingemar.s.johansson@...csson.com; mirja.kuehlewind@...csson.com; cheshire@...le.com; rs.ietf@....at; Jason_Livingood@...cast.com; vidhi_goel@...le.com
> Subject: RE: [PATCH v3 net-next 1/3] net: update comments for SKB_GSO_TCP_ECN and SKB_GSO_TCP_ACCECN
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> > From: chia-yu.chang@...ia-bell-labs.com
> > <chia-yu.chang@...ia-bell-labs.com>
> > Sent: 03 February 2026 09:41 PM
> > Cc: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> > Subject: [PATCH v3 net-next 1/3] net: update comments for
> > SKB_GSO_TCP_ECN and SKB_GSO_TCP_ACCECN
> >
> > From: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> >
> > This patch updates the documentation of ECN‑related GSO flags, it
> > clarifies the limitations of SKB_GSO_TCP_ECN and explains how to
> > preserve the CWR flag (part of the ACE signal) in the Rx path.
> >
> > For Tx, SKB_GSO_TCP_ECN and SKB_GSO_TCP_ACCECN are used respectively
> > for
> > RFC3168 ECN and AccECN (RFC9768). SKB_GSO_TCP_ECN indicates that the
> > first segment has CWR set, while subsequent segments have CWR cleared.
> > In contrast, SKB_GSO_TCP_ACCECN means that the segment uses AccECN and
> > therefore its CWR flag must not be modified durging segmentation.
> >
> > For RX, SKB_GSO_TCP_ECN shall NOT be used, because the stack cannot
> > know whether the connection uses RFC3168 ECN or AccECN, whereas
> > RFC3168 ECN offload may clear CWR flag and thus corrupts the ACE
> > signal. Instead, any segment that arrives with CWR set must use the
> > SKB_GSO_TCP_ACCECN flag to prevent RFC3168 ECN offload logic from clearing the CWR flag.
> >
> > Co-developed-by: Ilpo Järvinen <ij@...nel.org>
> > Signed-off-by: Ilpo Järvinen <ij@...nel.org>
> > Signed-off-by: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> >
> > ---
> > v3:
> > - Update commit messages and documentation for clarity
> > ---
> > include/linux/skbuff.h | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index
> > 8b399ddf1b9b..c59f0ce414d9 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -671,7 +671,13 @@ enum {
> > /* This indicates the skb is from an untrusted source. */
> > SKB_GSO_DODGY = 1 << 1,
> >
> > - /* This indicates the tcp segment has CWR set. */
> > + /* For Tx, this indicates that the first TCP segment has CWR set, and
> > + * any subsequent segment in the same skb has CWR cleared. This flag
> > + * must not be used in Rx, because the connection to which the segment
> > + * belongs is not tracked to use RFC3168 or AccECN. Using RFC3168 ECN
> > + * offload may clear CWR and corrupt ACE signal (CWR is part of it).
> > + * Instead, SKB_GSO_TCP_ACCECN shall be used to avoid CWR corruption.
> > + */
> Above part of the patch belongs to net with Fixes tag. Not sure how important it is to have fixes tag for comment.
> But the next patch of hns and mlx5 surely needs to have Fixes tag and in net.
> So can you please split this patch along with hns and mlx5 patch in the net branch instead of net-next?
>
> > SKB_GSO_TCP_ECN = 1 << 2,
> >
>
> > __SKB_GSO_TCP_FIXEDID = 1 << 3,
> > @@ -706,6 +712,13 @@ enum {
> >
> > SKB_GSO_FRAGLIST = 1 << 18,
> >
> > + /* For TX, this indicates that the TCP segment uses the CWR flag as part
> > + * of the ACE signal, and the CWR flag must not be modified in the skb.
> > + * For RX, any incoming segment with CWR set must use this flag so that
> > + * no RFC3168 ECN offload can clear the CWR flag. This is essential for
> > + * preserving ACE signal correceness (CWR is part of it) in a forwarding
> > + * scenario, e.g., from virtio_net RX to GSO TX.
> > + */
> Better to have this comment not linked to any device type as virtio-net. It can be from one to other netdev as generic example.
Hi Parav,
Sure, I will split the last virtio-net patch into individual series into net-next.
And re-send the first 2 patches (with the suggested change to not linked to any device type) to net.
Thanks.
Chia-Yu
Powered by blists - more mailing lists