Date: Tue, 30 Jul 2019 14:58:47 -0400 From: Randall Stewart <rrs@netflix.com> To: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> Cc: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: Re: tcpcb cleanup? Message-ID: <F6ED4758-57A3-43FB-AFC4-7E7E3F786AB9@netflix.com> In-Reply-To: <SN4PR0601MB37289523526A617579B2C37886DC0@SN4PR0601MB3728.namprd06.prod.outlook.com> References: <SN4PR0601MB37280DCBAE4F063AE603A1F186DC0@SN4PR0601MB3728.namprd06.prod.outlook.com> <B0779E92-25DD-4680-AF76-612978285FE3@netflix.com> <SN4PR0601MB37289523526A617579B2C37886DC0@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
That should change soon :) R > On Jul 30, 2019, at 2:45 PM, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >=20 > I believe the alignment of some pointers is also off, further shifting = the data... >=20 > I started some work in D21117 around this - reducing the size of this = t_rttupdated in tcpcb down from ulong to uint8_t, as it really only = needs to track the initial few rounds, and then stay fixed at the = UCHAR_MAX. >=20 > Also, I made other types, particularly pure counters, uint32_t (from = int), giving them more range. >=20 > It seems that some variables, that are only (currently) used in the NF = RACK stack, have "leaked" out already =F0=9F=98=8A (t_maxunacktime is = referenced to, but apparently never set, in the upstreamed RACK stack). >=20 > Best regards, >=20 >=20 > Richard Scheffenegger >=20 > -----Original Message----- > From: Randall Stewart <rrs@netflix.com>=20 > Sent: Dienstag, 30. Juli 2019 08:41 > To: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> > Cc: freebsd-transport@freebsd.org > Subject: Re: tcpcb cleanup? >=20 > NetApp Security WARNING: This is an external email. Do not click links = or open attachments unless you recognize the sender and know the content = is safe. >=20 >=20 >=20 >=20 > Yes >=20 > As I said in comments to your removal of the sack field, they have = drifted since my first work. >=20 > I am not too concerned since the first 3 cache lines are the most used = and most important. >=20 > I do intend to do a re-analysis once I get BBR and the latest Rack in = to see if we could improve things.. though it is doubtful that we will = gain much (but you never know) ;) >=20 > R >=20 >> On Jul 29, 2019, at 11:13 PM, Scheffenegger, Richard = <Richard.Scheffenegger@netapp.com> wrote: >>=20 >> Hi, >>=20 >> I've been looking into the cache line alignment today (because = D18811). >>=20 >> Found that the commented cache lines only align to line 3 - then they = drift from the comments. >>=20 >> For example, t_rttupdated is defined as u_long (8 bytes), while it = really only tracks if at least some (small) number of rtt samples were = collected, to start the use of the rtt vars... >>=20 >> Realistically, a uint8_t with a limited increment (if (x<255) x++) = would serve the very same function... >>=20 >> Other example: t_sndzerowin (in tcpcb) appears to be only a counter, = better placed into the tcpstat structure, where non-functional counters = belong IMHO. (perhaps a per-session variant). >>=20 >>=20 >>=20 >>=20 >> And the other variables could probably be defined in the explicit = types (uint16/32/64), to be more certain of the alignment - plus making = sure that alignment boundaries between different sized types don't = result in unintentional shifting of the alignment (like it seems = currently to be the case). >>=20 >> Another prime example: struct sackhint is 40 bytes, only 24 of these = are actually used; and ideally, sackblks, snd_fack share the same line, = while sackhint and snd_holes would do the same (currently, both are = distributed across 2) .... >>=20 >>=20 >> Any appetite to get the (higher) cache lines aligned in tcpcb? >>=20 >> Best regards, >> Richard >>=20 >>=20 >> _______________________________________________ >> freebsd-transport@freebsd.org mailing list=20 >> https://lists.freebsd.org/mailman/listinfo/freebsd-transport >> To unsubscribe, send any mail to = "freebsd-transport-unsubscribe@freebsd.org" >=20 > ------ > Randall Stewart > rrs@netflix.com >=20 >=20 >=20 ------ Randall Stewart rrs@netflix.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6ED4758-57A3-43FB-AFC4-7E7E3F786AB9>