On 01/22/16 at 04:06P, Bjoern A. Zeeb wrote: > > > On 22 Jan 2016, at 15:21 , George Neville-Neil <[email protected]> > > wrote: > > > > > > > > On 22 Jan 2016, at 2:13, Lawrence Stewart wrote: > > > >> Hi Gleb, > >> > >> On 01/22/16 09:34, Gleb Smirnoff wrote: > >>> Author: glebius > >>> Date: Thu Jan 21 22:34:51 2016 > >>> New Revision: 294535 > >>> URL: https://svnweb.freebsd.org/changeset/base/294535 > >>> > >>> Log: > >>> - Rename cc.h to more meaningful tcp_cc.h. > >> > >> As a bit of historical context, the naming was intentionally protocol > >> agnostic because it was originally hoped that the CC framework could be > >> shared between multiple CC aware transports, and the design went to some > >> lengths to accommodate that possibility (e.g. the ccv_container union in > >> struct cc_var). SCTP was the obvious potential in tree consumer at the > >> time, and other protocols like DCCP were considered as well. > >> > >> This hasn't come about to date, but I'm not sure what value is obtained > >> from your rename change unless we decide to completely give up on shared > >> CC and if we do that, this change doesn't go far enough and we can > >> further simplify the framework to make it entirely TCP specific e.g. we > >> should probably do away with struct cc_var. > >> > >> I'd argue in favour of reverting the rename and if you're gung ho about > >> making the framework TCP specific, we can start a public discussion > >> about what that should look like. > >> > > > > I actually was wondering about this as well. I think it ought to be > > reverted to agnostic. > > I probably share that view but I also agree that cc.h is not a good name. > > So before we entirely revert this, can when maybe come up with a name that is > better than cc.h or tcp_cc.h and only make this one more change forward > rather than going back to the previous status quo?
We use "cc" everywhere in the stack to refer to congestion control. Whether thats mod_cc or cc_<algo> or sys/netinet/cc directory. I don't see a problem with the name. Neither do I feel a need for any change. Cheers, Hiren
pgpIMq0R4tcos.pgp
Description: PGP signature
