I guess you want to keep KMOD_TCPSTAT_INC here, since this is a kernel module.

I guess you want to keep KMOD_TCPSTAT_INC here, since this is a kernel module.

I guess you want to keep KMOD_TCPSTAT_INC here, since this is a kernel module.

You could use bool as the type for nolog, and use true and false when calling it.
Maybe it is simpler to avoid the negation and use bool log as the parameter, swap true and false when calling and use

			if (log)
				tcp_log_end_status(tp, TCP_EI_STATUS_PROGRESS);

instead of

			if (!nolog)
				tcp_log_end_status(tp, TCP_EI_STATUS_PROGRESS);

Maybe use 2016-2020?

I think it is Warner removing the All rights reserved. So are you adding it intentionally?

Maybe use 2016-2020?

Maybe make this header and the one used in tcp_bbr.h consistent? Add the SPDX there too...

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Do you intentionally remove uint8_t iptos, which was added by Richard for future ECN support?

Can you provide a better description? What does 3 mean? The text read like you are describing a boolean...

Text reads like a boolean, but value isn't?

Text reads like a boolean, but value isn't...

Text reads like a boolean, but value isn't...

Text reads like a boolean, but value isn't... Double ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

Why ? at the end?

The text reads like a boolean. but the value isn't.

Why ? at the end?

What instead of what?

No double space.

Just picking one: Where is it freed? I guess they are leaked on unloading the module, or am I missing something?

SACKs instead of SACK's?

yep this was probably not upstream when you did the update.

yep

yep

No not intentionally. The problem was that our rack lived for a time in parallel rack.c and rack_pacing.c , which means
merges were painful since we had to catch all the changes going in from upstream in rack.c and copy them over to rack_pacing.c
I must have missed that one. A release or two ago rack_pacing.c became rack.c

I will add it back though it looks like it is unused.

see above

see above

see above

see above

see above

see above

see above

see above

How about
What is the maximum number of full TLS records that will be sent at once

Maybe:
If not zero, provides a maximum usecond that you can stay in probertt (2sec = 2000000)
would make ie clearer?

For these three how about

If non zero, what percentage of goodput to pace at in <xxx>

where xxx is recovery, congestion avoidance or slow start

I have removed all sysctl terminating ? marks.

I always more or less thought of this as asking a question but I see that probably is a bit weird ... but so am I ;-)

Maybe
Rack timely what threshold do we count to before another boost during b/w decent
would be more clear?

ok

A comment perhaps then i.e.
/* Measure controls */

Good question, bbr may also have the same issue. Let me check.

Yep and there were two in BBR.

ok

ok

I will fix this so that all of them have the correct statements... (all consistently the same)

I prepared the iptos stuff for adding in AccECN support later (intially only the handshake, and some simple tie-in with existing ECN reactions).

Obviously, if you have a stack (BBRv1) which is not supporting ECN in the first place, this could be reverted.

D21011 has the initial AccECN handshake code, but once the draft stabilizes after being promoted to PS (and addressing a number of edge cases), I will have to update that diff agian.

And yes, in many places I don't actually need access to iptos (but because of the callout table, I had to add it to all function headers). If you have a more effective way to get access in all the SYN- related states only, that would work for me.

I have them all -20 but yeah I like 2020 better.. I was just following other files.