Re: [PATCH net-next v4] tcp: add TCP_ECN and TCP_ECN_OPTION socket options

[Eric Dumazet]

On Tue, Sep 22, 2026 at 12:26 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Wed, 16 Sep 2026 10:32:55 +0530 Irlanki Sandeep wrote:
> > Currently, ECN and Accurate ECN (AccECN) configurations in the Linux
> > kernel are controlled globally via the net.ipv4.tcp_ecn and
> > net.ipv4.tcp_ecn_option sysctl variables. This global approach lacks the
> > granularity required for modern multi-application runtimes.
> >
> > In diverse network environments (such as mobile operating systems like
> > Android), different applications route their traffic over distinct
> > physical and virtual interfaces (cellular, Wi-Fi, VPNs, etc.). In the
> > wild, certain legacy network paths or misconfigured middleboxes (such as
> > routers, DPIs, or firewalls) are known to blackhole packets with ECN
> > negotiation flags in the SYN, or silently drop packets containing AccECN
> > option headers during active sessions.
>
> My gut reaction is that we shouldn't be adding a setsockopt here.
> This is a routing property, really, IIUC you're adding the setsockopt
> because you want to use BPF, in which case isn't it better to add
> a kfunc for this? Why go thru all the sockopt plumbing?
>
> TCP maintainers, WDYT?

Speaking for myself, I also cannot see why we need to support so much
flexibility.

BTW:

I have on my plate a complete walk through of recent fields additions
in tcp_sock,
mostly from the AccECN support.

ecn_mode and ecn_options have nothing to do in tcp_sock_write_tx group
in any case.
This patch  would hurt performance.