Date: Fri, 8 Jun 2018 09:37:46 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Matthew Macy <mat.macy@gmail.com> Cc: Randall Stewart <rrs@netflix.com>, Randall Ray Stewart <rrs@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334804 - in head/sys: kern modules/tcp modules/tcp/rack netinet netinet/tcp_stacks sys Message-ID: <20180608163746.GE62424@strugglingcoder.info> In-Reply-To: <CAPrugNo4bHERR-Cs5o4io5-Lnw0tz6ZN=oe3H2BSH1LgdZBubg@mail.gmail.com> References: <201806071818.w57IIENp080093@repo.freebsd.org> <20180607220121.GC62424@strugglingcoder.info> <40CCC8B4-5667-4D4B-A4B4-7AD5779FE011@netflix.com> <20180608015740.GD62424@strugglingcoder.info> <CAPrugNo4bHERR-Cs5o4io5-Lnw0tz6ZN=oe3H2BSH1LgdZBubg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--SWTRyWv/ijrBap1m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
> >
>=20
> 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.
--SWTRyWv/ijrBap1m
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQF8BAABCgBmBQJbGrDXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4
QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l0QcIAKWf6UGXQDm/wILTuTYlMoc4
9ia14RqEi5bL5tjS5JmSjVK8xt85MkcyIBXYI12Cyf1hlf952d+wi0jqrVnkbwKi
QQOMm5P8TtAN/PjX2lyxdNZdJ4Y5eWlEKG5vOmvHkBMtaXAovyXFbL90WNbcFllK
umFSXPvOsxfTjF5Q8Dmx0Dbqr050pXF3L+aY11fxivWnLTVtnOC9ANTmF6y+jGXl
pvKyuudvySUuRQp+rCddcgOPgammpqy7vj/UDRfDkxcpXzixytmyRZLcsquQK6hh
6iCyxjyaFZEB0o11LTfms4NSr09TmZS8al4qAfPh5m5ekm6o7OeNJeYkkikgq9A=
=rAaV
-----END PGP SIGNATURE-----
--SWTRyWv/ijrBap1m--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180608163746.GE62424>