[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z_VQ0KlCRkqYWXa-@calendula>
Date: Tue, 8 Apr 2025 18:37:36 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, David Ahern <dsahern@...nel.org>,
Neal Cardwell <ncardwell@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 2/4] net: Retire DCCP.
Hi Kuniyuki,
On Mon, Apr 07, 2025 at 04:17:49PM -0700, Kuniyuki Iwashima wrote:
> DCCP was orphaned in 2021 by commit 054c4610bd05 ("MAINTAINERS: dccp:
> move Gerrit Renker to CREDITS"), which noted that the last maintainer
> had been inactive for five years.
>
> In recent years, it has become a playground for syzbot, and most changes
> to DCCP have been odd bug fixes triggered by syzbot. Apart from that,
> the only changes have been driven by treewide or networking API updates
> or adjustments related to TCP.
>
> Thus, in 2023, we announced we would remove DCCP in 2025 via commit
> b144fcaf46d4 ("dccp: Print deprecation notice.").
>
> Since then, only one individual has contacted the netdev mailing list. [0]
>
> There is ongoing research for Multipath DCCP. The repository is hosted
> on GitHub [1], and development is not taking place through the upstream
> community. While the repository is published under the GPLv2 license,
> the scheduling part remains proprietary, with a LICENSE file [2] stating:
>
> "This is not Open Source software."
>
> The researcher mentioned a plan to address the licensing issue, upstream
> the patches, and step up as a maintainer, but there has been no further
> communication since then.
>
> Maintaining DCCP for a decade without any real users has become a burden.
>
> Therefore, it's time to remove it.
>
> Removing DCCP will also provide significant benefits to TCP. It allows
> us to freely reorganize the layout of struct inet_connection_sock, which
> is currently shared with DCCP, and optimize it to reduce the number of
> cachelines accessed in the TCP fast path.
Netfilter parses skbuffs, in that sense, it is a middlebox. Main
concern on my side is that it could break rulesets, even for people
that don't really see dccp traffic ever, ruleset could stop loading.
I would keep the netfilter bits aside by now, based on your netfilter
updates, we can internally discuss how to phase out dccp support to
get aligned with netdev maintainers, as it seems there is a wish to
reduce debt in this front.
Having said, this Netfilter does not rely on any of this socket
structures, I think it should not be an impediment for your tree
spring cleanup (IIRC we have no hard dependencies on CONFIG_DCCP).
> Note that we leave uAPI headers alone for userspace programs.
Powered by blists - more mailing lists