Date: Sat, 23 Jan 2016 17:19:36 +1100 From: Lawrence Stewart <lstewart@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks Message-ID: <56A31B78.2090100@freebsd.org> In-Reply-To: <20160122181816.GB1004@FreeBSD.org> References: <201601212234.u0LMYpKT009948@repo.freebsd.org> <56A1D6B2.1010406@freebsd.org> <20160122181816.GB1004@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/23/16 05:18, Gleb Smirnoff wrote: > On Fri, Jan 22, 2016 at 06:13:54PM +1100, Lawrence Stewart wrote: > L> On 01/22/16 09:34, Gleb Smirnoff wrote: > L> > Author: glebius > L> > Date: Thu Jan 21 22:34:51 2016 > L> > New Revision: 294535 > L> > URL: https://svnweb.freebsd.org/changeset/base/294535 > L> > > L> > Log: > L> > - Rename cc.h to more meaningful tcp_cc.h. > L> > L> As a bit of historical context, the naming was intentionally protocol > L> agnostic because it was originally hoped that the CC framework could be > L> shared between multiple CC aware transports, and the design went to some > L> lengths to accommodate that possibility (e.g. the ccv_container union in > L> struct cc_var). SCTP was the obvious potential in tree consumer at the > L> time, and other protocols like DCCP were considered as well. > L> > L> This hasn't come about to date, but I'm not sure what value is obtained > L> from your rename change unless we decide to completely give up on shared > L> CC and if we do that, this change doesn't go far enough and we can > L> further simplify the framework to make it entirely TCP specific e.g. we > L> should probably do away with struct cc_var. > L> > L> I'd argue in favour of reverting the rename and if you're gung ho about > L> making the framework TCP specific, we can start a public discussion > L> about what that should look like. > > The problem is that cc.h (or tcp_cc.h) is already depening on many > TCP types. So, the structures defined inside are not agnostic, including > tcp headers before cc.h is required. Not in any significant way that tightly couples the API to TCP from consumers' perspective. > The old cc.h used to include tcp.h implicitly, which is a bad style. > > Since many developers sorted netinet/* includes in a .c file using > sort(1), that lead to cc.h always come before actual tcp includes, > hiding the real requirement for tcp.h in a .c file. To provide some more context, I considered that choice to be a lesser evil at the time. Linux had set the defacto standard macro naming and location so even though I would have put the CC related defines in cc.h given the choice, I wanted third-party software which checked for modular CC the Linux way to work on FreeBSD. The alphabetical ordering of includes is what prompted me to include tcp.h in cc.h so that cc.h could happily sit at the top of the list. I probably could have just moved cc.h to the cc subdir, in which case it would always come logically after the TCP includes as <netinet/cc/cc.h> - perhaps that's the right solution. > P.S. Speaking of agnostic stuff. My humble opinion, that in the > network stack through the whole BSD history agnosticism never yield > in virtue. Examples: routing code can be used for IPv4, IPv6, Atalk > and IPX. Result is that Atalk and IPX are history, but our routing > table uses 8x more memory for IPv4 and performs miserably. Another > example is the same sockbuf used for all types of sockets, including > stream, datagram, local and network, which first yielded in quite > complex code for a quite trivial task, and later then, when SCTP > came in failed to be agnostic enough to fit into SCTP. I generally agree with you, though I'm not sure the examples are overly applicable to the CC framework given the minimal overhead required to make it agnostic vs the potential overhead of maintaining multiple incarnations of the same algorithm. That being said, I'm not at all against declaring the shared CC idea a failed experiment given that it hasn't come to fruition. I just suggest that if we're going to do that, we have to go a lot further than just a rename. Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56A31B78.2090100>