tcphpts: enable per default

[tuexen]

Summary

This patch enables the TCP high precision timer system per default on all platforms, which right now support TCP Black Box logging per default.

Please note that this adds some CPU overhead to the system. An upcoming optimization will provide a mitigation. Enable this right now to allow simpler testing of the TCP RACK stack.

[glebius]

I actually planned to make it a loadable module. Given that it creates extra threads that aren't going to be used by default makes its presence questionable.

[jtl]

In D42664#973383, @glebius wrote:

I actually planned to make it a loadable module. Given that it creates extra threads that aren't going to be used by default makes its presence questionable.

I believe the "upcoming optimization" that @tuexen mentioned in the review is to defer thread creation until those are actually needed, similar to what is done for KTLS now. If that is planned, I (speaking only for myself, and only giving an opinion), think it seems reasonable to commit this now in order to enable easier RACK testing.

[glebius]

Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.

[tuexen]

In D42664#973596, @glebius wrote:

Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.

Are you preferring to delay the adding of the kernel option until an optimization has been added?

[glebius]

In D42664#973599, @tuexen wrote:

In D42664#973596, @glebius wrote:

Agreed. If threads aren't created until they are needed adding to GENERIC sound alright. At least for "large" platforms like amd64.

Are you preferring to delay the adding of the kernel option until an optimization has been added?

I really don't want to block anyone's work.

Since you asking, yeah, I'd prefer to see FreeBSD CURRENT perfect at any point, thus I don't like the approach of "let's throw this in but fix tomorrow". However! Right now we have unloadable modules and adding to HPTS to GENERIC is going to fix it. Making CURRENT better for people who use rack & bbr, making it slightly worse for people who don't. So it is your call. Whatever is more handy to you. I'm definitely not blocking this revision.

[tuexen]

OK, I talked to rrs@. He says that using TCPHPTS adds some memory overhead for each core and runs a timer per core every 500ms. I summary he thinks that this is not a critical overhead on today's machines. So do we really need the optimization?

[manu]

In D42664#973835, @tuexen wrote:

OK, I talked to rrs@. He says that using TCPHPTS adds some memory overhead for each core and runs a timer per core every 500ms. I summary he thinks that this is not a critical overhead on today's machines. So do we really need the optimization?

Maybe not critical on today's amd64 machines, what about embedded ?
Also it seems that this review doesn't update armv7 and we will likely keep armv7 for 15-CURRENT (and 15.0).

[glebius]

We were actually one step away from a working loadable module.

https://reviews.freebsd.org/D42696
https://reviews.freebsd.org/D42697

[tuexen]

We don't need this anymore, since it is now a module. Thanks to glebius@ for making it a module.