[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240215201627.14449-1-kuniyu@amazon.com>
Date: Thu, 15 Feb 2024 12:16:27 -0800
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <ncardwell@...gle.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <jaka@...ux.ibm.com>,
<jonesrick@...gle.com>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.com>, <linux-s390@...r.kernel.org>, <martineau@...nel.org>,
<matttbe@...nel.org>, <mptcp@...ts.linux.dev>, <netdev@...r.kernel.org>,
<pabeni@...hat.com>, <soheil@...gle.com>, <wenjia@...ux.ibm.com>,
<ycheng@...gle.com>
Subject: Re: [PATCH v1 net-next] net: Deprecate SO_DEBUG and reclaim SOCK_DBG bit.
From: Neal Cardwell <ncardwell@...gle.com>
Date: Thu, 15 Feb 2024 12:57:35 -0700
> On Tue, Feb 13, 2024 at 3:32 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> > Recently, commit 8e5443d2b866 ("net: remove SOCK_DEBUG leftovers")
> > removed the last users of SOCK_DEBUG(), and commit b1dffcf0da22 ("net:
> > remove SOCK_DEBUG macro") removed the macro.
> >
> > Now is the time to deprecate the oldest socket option.
> >
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
> > ---
>
> I would like to kindly implore you to please not remove the
> functionality of the SO_DEBUG socket option. This socket option is a
> key mechanism that the Google TCP team uses for automated testing of
> Linux TCP, including BBR congestion control.
>
> Widely used tools like netperf allow users to enable the SO_DEBUG
> socket option via the command line (-g in netperf). Then debugging
> code in the kernel can use the SOCK_DBG bit to decide whether to take
> special actions, such as logging debug information, which can be used
> to generate graphs or assertions about correct internal behavior. For
> example, the transperf network testing tool that our team open-sourced
> - https://github.com/google/transperf - uses the netperf -g/SO_DEBUG
> mechanism to trigger debug logging that we use for testing,
> troubleshooting, analysis, and development.
>
> The SO_DEBUG mechanism is nice in that it works well no matter what
> policy an application or benchmarking tool uses for choosing other
> attributes (like port numbers) that could conceivably be used to point
> out connections that should receive debug treatment. For example, most
> benchmarking or production workloads will effectively end up with
> random port numbers, which makes port numbers hard to use for
> triggering debug treatment.
>
> This mechanism is very simple and battle-tested, it works well, and
> IMHO it would be a tragedy to remove it. It would cause our team
> meaningful headaches to replace it. Please keep the SO_DEBUG socket
> option functionality as-is. :-)
>
> Thanks for your consideration on this!
Oh that's an interesting use case!
I didn't think of out-of-tree uses.
Sure, I'll drop the patch.
Thanks!
Powered by blists - more mailing lists