Date: Tue, 30 Jul 2019 08:40:32 -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: <B0779E92-25DD-4680-AF76-612978285FE3@netflix.com> In-Reply-To: <SN4PR0601MB37280DCBAE4F063AE603A1F186DC0@SN4PR0601MB3728.namprd06.prod.outlook.com> References: <SN4PR0601MB37280DCBAE4F063AE603A1F186DC0@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes As I said in comments to your removal of the sack field, they have drifted since my first work. I am not too concerned since the first 3 cache lines are the most used = and most important. 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) ;) R > 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 > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to = "freebsd-transport-unsubscribe@freebsd.org" ------ Randall Stewart rrs@netflix.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B0779E92-25DD-4680-AF76-612978285FE3>