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

[hiren panchasara]

On 06/07/18 at 08:07P, Matthew Macy wrote:
> >
> > Okay. I believe there might be situations where we may want to still
> > keep the 'default' stack alive. I know Windows doesn't yet use RACK when
> > rtt is lesser than 10ms (or something like that), as an example.
> >
> 
> Is there any reason RACK wouldn't work for tracking 10us RTTs? If we
> know we know the peer doesn't do delack or have enough data in flight
> and the other stack doesn't have broken LRO, could we just use this in
> lieu of high resolution timestamps?

I believe the issue is both ends having fine-grained timers for RACK to
be able to do the right thing. If timer resolution ends up being coarser
than rtt, just depending on rack may be problematic. I know 10ms is
doable on most systems but just using this as an example that we
probably want non-rack ('default') stack to be around a little longer
and possibly with the enhancements that we can easily extract out to be
shared among all the stacks.

Also RACK needing pacing which requires but more CPU so question for us
could be that do we want to keep the 'default' stack around for machines
that can't take that extra CPU hit.

SACK is inefficient in default stack and PRR could be super useful as
"psuedo" pacing mechanism and could help recover faster but at the end
of the day it all depends on someone with time/energy/motivation to
maintain the 'default' stack with all shiny things that appear in
non-default stacks.

cheers,
Hiren

ps: I know we are not killing the default stack as of yet and just
stopping active maintenance of it but just wanted to raise these
(probably obvious) points.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20180608/d2d4eb9a/attachment.sig>