From: Neal Cardwell <ncardwell@xxxxxxxxxx>
Date: Thu, 15 Feb 2024 12:57:35 -0700
> On Tue, Feb 13, 2024 at 3:32 PM Kuniyuki Iwashima <kuniyu@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
>
> 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!
