mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Irlanki Sandeep" <irlanki.s@samsung.com>
To: "'Eric Dumazet'" <edumazet@google.com>,
	"'Jakub Kicinski'" <kuba@kernel.org>
Cc: <ncardwell@google.com>, <netdev@vger.kernel.org>,
	<bpf@vger.kernel.org>, <davem@davemloft.net>, <pabeni@redhat.com>,
	<ast@kernel.org>, <daniel@iogearbox.net>, <andrii@kernel.org>,
	<corbet@lwn.net>, <linux-kernel@vger.kernel.org>,
	<lorenzo@google.com>, <maze@google.com>, <sporeba@google.com>,
	<motomuman@google.com>, <srihari.k@samsung.com>,
	<g.pokhra@samsung.com>, <r.kumawat@samsung.com>,
	<raj.kumars@samsung.com>, <ts413.lee@samsung.com>,
	<ramyashree.s@samsung.com>, <daeil2.hwang@samsung.com>,
	<cpgs@samsung.com>, <irlanki.s@samsung.com>
Subject: RE: [PATCH net-next v4] tcp: add TCP_ECN and TCP_ECN_OPTION socket options
Date: Wed, 30 Sep 2026 17:48:32 +0530	[thread overview]
Message-ID: <000001dd50d5$d1c1fb70$7545f250$@samsung.com> (raw)
In-Reply-To: <CANn89iJgAXaoepX1uvUbYhnutjvOPknPFheThf-gRWV-PbZZxw@mail.gmail.com>

> On Mon, 21 Sep 2026 15:26:04 -0700, Jakub Kicinski <kuba@kernel.org> wrote:
> > 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?

Hi Jakub,

Agreed. Moving to BPF kfuncs avoids UAPI clutter while giving us the exact per-connection granularity we need.

I adopted your suggestion and transitioned the implementation to two kfuncs:
- bpf_sock_ops_set_ecn_mode()
- bpf_sock_ops_set_accecn_option()

v5 with the kfuncs and selftests has been submitted:
https://lore.kernel.org/all/20260930102308.197808-1-irlanki.s@samsung.com/

> On Tue, 22 Sep 2026 02:48:10 +0200, Eric Dumazet <edumazet@google.com> wrote:
> Speaking for myself, I also cannot see why we need to support so much
> flexibility.

Hi Eric,

Regarding the need for this flexibility:

In our testing on real-world networks across multiple interfaces (cellular, Wi-Fi):
1. Certain legacy middleboxes blackhole ECN flags or drop data packets carrying AccECN option headers. A global sysctl is all-or-nothing: disabling it loses L4S benefits on compliant paths, while enabling it globally causes connection failures on broken paths.
2. Under heavy CE markings, we observed throughput drops when comparing Prague (out-of-tree) against Cubic/BIC. We need the ability to selectively enable AccECN for latency-sensitive applications while avoiding it for bulk throughput-oriented traffic on paths showing throughput regressions.

This patch gives us this per-connection control dynamically without changing global sysctls.

> 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.

Thanks for pointing this out.

In v5, ecn_mode and ecn_option have been moved out of tcp_sock_write_tx and placed into the cold section of struct tcp_sock (immediately after accecn_fail_mode, outside hot fastpath cachelines). We have also updated Documentation/networking/net_cachelines/tcp_sock.rst accordingly.

Please review v5 when you get a chance.

Thanks,
Sandeep


      reply	other threads:[~2026-09-30 12:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260916050144epcas5p3f7d6a44556baabd24027af8f4bce7893@epcas5p3.samsung.com>
2026-09-16  5:02 ` Irlanki Sandeep
2026-09-21 22:26   ` Jakub Kicinski
2026-09-22  0:48     ` Eric Dumazet
2026-09-30 12:18       ` Irlanki Sandeep [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001dd50d5$d1c1fb70$7545f250$@samsung.com' \
    --to=irlanki.s@samsung.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=cpgs@samsung.com \
    --cc=daeil2.hwang@samsung.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=g.pokhra@samsung.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=maze@google.com \
    --cc=motomuman@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=r.kumawat@samsung.com \
    --cc=raj.kumars@samsung.com \
    --cc=ramyashree.s@samsung.com \
    --cc=sporeba@google.com \
    --cc=srihari.k@samsung.com \
    --cc=ts413.lee@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®