svn commit: r349893 - in head/sys: modules/tcp/rack netinet netinet/tcp_stacks sys

[Randall Stewart]

John:

Thanks for the suggestions.. I have committed changes to the two
nits. As to M_PROTO1, I see that in the NF world we have removed
M_PROTO12 and moved the M_PROTO’s up 1 i.e. M_PROTO1 == 0x2000

So for now it is safe, since the M_TSTMP_LRO is not yet used.. but in
my up and coming commits I will have to address this i.e. either do
the same thing or just make it use M_PROTO12.

There are a couple of places M_PROTO1 is used on the receive path
so that would not work there :o

After I get the DSACK fixes in my next change to get BBR in will
be the LRO work…

So maybe I should just settle on using M_PROTO12 for that 
what do you think?

R

> On Jul 10, 2019, at 7:28 PM, John Baldwin <jhb at freebsd.org> wrote:
> 
> On 7/10/19 1:40 PM, Randall Stewart wrote:
>> Author: rrs
>> Date: Wed Jul 10 20:40:39 2019
>> New Revision: 349893
>> URL: https://svnweb.freebsd.org/changeset/base/349893
>> 
>> Log:
>>  This commit updates rack to what is basically being used at NF as
>>  well as sets in some of the groundwork for committing BBR. The
>>  hpts system is updated as well as some other needed utilities
>>  for the entrance of BBR. This is actually part 1 of 3 more
>>  needed commits which will finally complete with BBRv1 being
>>  added as a new tcp stack.
>> 
>>  Sponsored by:	Netflix Inc.
>>  Differential Revision:	https://reviews.freebsd.org/D20834
> 
> Is it safe for M_TSTMP_LRO to conflict with M_PROTO1?
> 
> Also, it seems you changed the copyright range on rack.c from
> 2016-2019 to just 2016 which I suspect is an accident.
> 
> I would suggest using #error here:
> 
> #ifndef TCPHPTS
> fatal error missing option TCPHSTS in the build;
> #endif
> 
> -- 
> John Baldwin

------
Randall Stewart
rrs at netflix.com