Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Lawrence Stewart]

On 01/24/16 19:07, Gleb Smirnoff wrote:
>   Lawrence,
> 
> On Sat, Jan 23, 2016 at 05:19:36PM +1100, Lawrence Stewart wrote:
> L> > The problem is that cc.h (or tcp_cc.h) is already depening on many
> L> > TCP types. So, the structures defined inside are not agnostic, including
> L> > tcp headers before cc.h is required.
> L> 
> L> Not in any significant way that tightly couples the API to TCP from
> L> consumers' perspective.
> L> 
> L> > The old cc.h used to include tcp.h implicitly, which is a bad style.
> L> > 
> L> > Since many developers sorted netinet/* includes in a .c file using
> L> > sort(1), that lead to cc.h always come before actual tcp includes,
> L> > hiding the real requirement for tcp.h in a .c file.
> L> 
> L> To provide some more context, I considered that choice to be a lesser
> L> evil at the time. Linux had set the defacto standard macro naming and
> L> location so even though I would have put the CC related defines in cc.h
> L> given the choice, I wanted third-party software which checked for
> L> modular CC the Linux way to work on FreeBSD. The alphabetical ordering
> L> of includes is what prompted me to include tcp.h in cc.h so that cc.h
> L> could happily sit at the top of the list. I probably could have just
> L> moved cc.h to the cc subdir, in which case it would always come
> L> logically after the TCP includes as  - perhaps that's
> L> the right solution.
> 
> Well, if the intent was to provide some sort of compatibility with Linux,
> then my rename is even more valid! Look what left in the cc.h in the
> Netflix source (which is kinda forward of FreeBSD): almost the whole
> file is under _KERNEL. Only the tcp.h pollution left for userland.
> 
> If Linux has cc.h and we want to put same definitions in cc.h, then
> we should start new cc.h and keep this one renamed. Because if we
> provided that one, we won't provide any compatibility, but would
> just pollute with tcp.h.

They do not have cc.h, they stuffed things into tcp.h. When I say I was
trying to keep compat with Linux, I meant that I wanted to leave
TCP_CA_NAME_MAX in tcp.h rather than move it to cc.h where it logically
belongs and is required. This has no bearing on the naming of our cc.h
file, but is the reason why I included tcp.h in cc.h, bad as that may be.

> I am fine with netinet/cc/cc.h. If you agree I can run the rename.

I think this is the right option. Please go ahead and move tcp_cc.h to
netinet/cc/cc.h and update ifdef guard, src includes and man page
accordingly.

Cheers,
Lawrence
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Gleb Smirnoff]

  Lawrence,

On Sat, Jan 23, 2016 at 05:19:36PM +1100, Lawrence Stewart wrote:
L> > The problem is that cc.h (or tcp_cc.h) is already depening on many
L> > TCP types. So, the structures defined inside are not agnostic, including
L> > tcp headers before cc.h is required.
L> 
L> Not in any significant way that tightly couples the API to TCP from
L> consumers' perspective.
L> 
L> > The old cc.h used to include tcp.h implicitly, which is a bad style.
L> > 
L> > Since many developers sorted netinet/* includes in a .c file using
L> > sort(1), that lead to cc.h always come before actual tcp includes,
L> > hiding the real requirement for tcp.h in a .c file.
L> 
L> To provide some more context, I considered that choice to be a lesser
L> evil at the time. Linux had set the defacto standard macro naming and
L> location so even though I would have put the CC related defines in cc.h
L> given the choice, I wanted third-party software which checked for
L> modular CC the Linux way to work on FreeBSD. The alphabetical ordering
L> of includes is what prompted me to include tcp.h in cc.h so that cc.h
L> could happily sit at the top of the list. I probably could have just
L> moved cc.h to the cc subdir, in which case it would always come
L> logically after the TCP includes as  - perhaps that's
L> the right solution.

Well, if the intent was to provide some sort of compatibility with Linux,
then my rename is even more valid! Look what left in the cc.h in the
Netflix source (which is kinda forward of FreeBSD): almost the whole
file is under _KERNEL. Only the tcp.h pollution left for userland.

If Linux has cc.h and we want to put same definitions in cc.h, then
we should start new cc.h and keep this one renamed. Because if we
provided that one, we won't provide any compatibility, but would
just pollute with tcp.h.

I am fine with netinet/cc/cc.h. If you agree I can run the rename.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[George Neville-Neil]

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.


Best,
George
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Gleb Smirnoff]

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.

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.

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.

-- 
Totus tuus, Glebius.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Lawrence Stewart]

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  - 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
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Bjoern A. Zeeb]

> On 22 Jan 2016, at 15:21 , George Neville-Neil  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?

/bz
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[hiren panchasara]

On 01/22/16 at 04:06P, Bjoern A. Zeeb wrote:
> 
> > On 22 Jan 2016, at 15:21 , George Neville-Neil  
> > 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_ 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

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Lawrence Stewart]

On 01/23/16 03:06, Bjoern A. Zeeb wrote:
> 
>> On 22 Jan 2016, at 15:21 , George Neville-Neil  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?

I don't object to a name change if it's desired by others, but I don't
have any suggestions to offer and would personally just stick with cc.h

Cheers,
Lawrence
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Gleb Smirnoff]

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.
  - Declare it a kernel only include, which it already is.
  - Don't include tcp.h implicitly from tcp_cc.h

Added:
  head/sys/netinet/tcp_cc.h
 - copied, changed from r294534, head/sys/netinet/cc.h
Deleted:
  head/sys/netinet/cc.h
Modified:
  head/sys/netinet/cc/cc.c
  head/sys/netinet/cc/cc_cdg.c
  head/sys/netinet/cc/cc_chd.c
  head/sys/netinet/cc/cc_cubic.c
  head/sys/netinet/cc/cc_dctcp.c
  head/sys/netinet/cc/cc_hd.c
  head/sys/netinet/cc/cc_htcp.c
  head/sys/netinet/cc/cc_newreno.c
  head/sys/netinet/cc/cc_vegas.c
  head/sys/netinet/tcp_input.c
  head/sys/netinet/tcp_output.c
  head/sys/netinet/tcp_stacks/fastpath.c
  head/sys/netinet/tcp_subr.c
  head/sys/netinet/tcp_timer.c
  head/sys/netinet/tcp_usrreq.c

Modified: head/sys/netinet/cc/cc.c
==
--- head/sys/netinet/cc/cc.cThu Jan 21 22:24:20 2016(r294534)
+++ head/sys/netinet/cc/cc.cThu Jan 21 22:34:51 2016(r294535)
@@ -65,10 +65,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 

Modified: head/sys/netinet/cc/cc_cdg.c
==
--- head/sys/netinet/cc/cc_cdg.cThu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_cdg.cThu Jan 21 22:34:51 2016
(r294535)
@@ -65,11 +65,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 

Modified: head/sys/netinet/cc/cc_chd.c
==
--- head/sys/netinet/cc/cc_chd.cThu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_chd.cThu Jan 21 22:34:51 2016
(r294535)
@@ -67,11 +67,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 

Modified: head/sys/netinet/cc/cc_cubic.c
==
--- head/sys/netinet/cc/cc_cubic.c  Thu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_cubic.c  Thu Jan 21 22:34:51 2016
(r294535)
@@ -59,11 +59,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 

Modified: head/sys/netinet/cc/cc_dctcp.c
==
--- head/sys/netinet/cc/cc_dctcp.c  Thu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_dctcp.c  Thu Jan 21 22:34:51 2016
(r294535)
@@ -50,10 +50,10 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
-
+#include 
 #include 
 
 #defineCAST_PTR_INT(X) (*((int*)(X)))

Modified: head/sys/netinet/cc/cc_hd.c
==
--- head/sys/netinet/cc/cc_hd.c Thu Jan 21 22:24:20 2016(r294534)
+++ head/sys/netinet/cc/cc_hd.c Thu Jan 21 22:34:51 2016(r294535)
@@ -68,11 +68,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 

Modified: head/sys/netinet/cc/cc_htcp.c
==
--- head/sys/netinet/cc/cc_htcp.c   Thu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_htcp.c   Thu Jan 21 22:34:51 2016
(r294535)
@@ -62,11 +62,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 /* Fixed point math shifts. */

Modified: head/sys/netinet/cc/cc_newreno.c
==
--- head/sys/netinet/cc/cc_newreno.cThu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_newreno.cThu Jan 21 22:34:51 2016
(r294535)
@@ -62,10 +62,10 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
-
+#include 
 #include 
 
 static voidnewreno_ack_received(struct cc_var *ccv, uint16_t type);

Modified: head/sys/netinet/cc/cc_vegas.c
==
--- head/sys/netinet/cc/cc_vegas.c  Thu Jan 21 22:24:20 2016
(r294534)
+++ head/sys/netinet/cc/cc_vegas.c  Thu Jan 21 22:34:51 2016
(r294535)
@@ -69,11 +69,10 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
-#include 
-#include 
+#include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 

Copied and modified: head/sys/netinet/tcp_cc.h (from r294534, 
head/sys/netinet/cc.h)

Re: svn commit: r294535 - in head/sys/netinet: . cc tcp_stacks

[Lawrence Stewart]

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.

Cheers,
Lawrence
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"