On Thu, Aug 21, 2025 at 7:58 AM Chia-Yu Chang (Nokia) chia-yu.chang@nokia-bell-labs.com wrote:
-----Original Message----- From: Eric Dumazet edumazet@google.com Sent: Thursday, August 21, 2025 2:30 PM To: Chia-Yu Chang (Nokia) chia-yu.chang@nokia-bell-labs.com Cc: pabeni@redhat.com; linux-doc@vger.kernel.org; corbet@lwn.net; horms@kernel.org; dsahern@kernel.org; kuniyu@amazon.com; bpf@vger.kernel.org; netdev@vger.kernel.org; dave.taht@gmail.com; jhs@mojatatu.com; kuba@kernel.org; stephen@networkplumber.org; xiyou.wangcong@gmail.com; jiri@resnulli.us; davem@davemloft.net; andrew+netdev@lunn.ch; donald.hunter@gmail.com; ast@fiberby.net; liuhangbin@gmail.com; shuah@kernel.org; linux-kselftest@vger.kernel.org; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) koen.de_schepper@nokia-bell-labs.com; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com Subject: Re: [PATCH v15 net-next 10/14] tcp: accecn: AccECN option
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.
On Fri, Aug 15, 2025 at 1:40 AM chia-yu.chang@nokia-bell-labs.com wrote:
[...]
/* Used for make_synack to form the ACE flags */ diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h index bdac8c42fa82..53e0e85b52be 100644 --- a/include/uapi/linux/tcp.h +++ b/include/uapi/linux/tcp.h @@ -316,6 +316,13 @@ struct tcp_info { * in milliseconds, including any * unfinished recovery. */
__u32 tcpi_received_ce; /* # of CE marks received */__u32 tcpi_delivered_e1_bytes; /* Accurate ECN byte counters */__u32 tcpi_delivered_e0_bytes;__u32 tcpi_delivered_ce_bytes;__u32 tcpi_received_e1_bytes;__u32 tcpi_received_e0_bytes;__u32 tcpi_received_ce_bytes;};
We do not add more fields to tcp_info, unless added fields are a multiple of 64 bits.
Otherwise a hole is added and can not be recovered.
Hi Eric,
Thanks for the feedback.
Then, would it make sense to add __u32 reserved; here or this is not an option?
I would prefer we take the opportunity to export a 32bit field right there, instead of a hole.
A reserved field makes it difficult for ss commands to know if a new kernel is using it for a different purpose.
Neal, any idea of what would be useful ?
I was thinking lately of sk_err_soft, but I am not yet convinced.