I would suggest to leave the old calculation in place which is only active in the non-default (IIRC) newsack=0 case, but collect all the other instances in one place.

Well, if the RTO was indeed spurious, then the subsequent RTO timeout should be the base RTO timeout (again). So, only a false detection of a spurious timeout would (incorrectly) set the cadence to a slightly faster retransmission schedule in subsequent rounds... But if the RTO was spurious, so by definition shouldn't have been triggered anyway, I don't believe this causes a problematic behavior.

• update int types used in function header
• proliferate the const struct to avoid compiler warnings

In D48069#1095696, @ae wrote:

I think this patch should do what you need.

• only keep relevant reject code and mtu rather than full ipfw_insn struct

In D48069#1095714, @kib wrote:

What do you mean by 'lock release ordering'? Can you show exact diagnostic you are trying to fix, please?

• update man to match code

@kp can you please review the PF-related changes in this Diff?

@kbowling, can you have a look at the intel driver changes and if they seem ok, remove that blocker?

Discussed in todays transport call, since this is not in the hot path of every packet, and the retention of the internal bit might confuse someone later, it was decided to abandon this change.

In D44258#1067037, @erj wrote:

Your description definitely helps; thanks for asking the question @kbowling. @tuexen have you checked these masks on the other devices that use ixl/ice, or is this what you've observed so far?

I haven't heard anything internally about needing the TSO masks to be changed, but I'm certainly fine with adding sysctls to configure these values since it seems to fix a valid issue.

Well, I had the same thought - the full MSS (including options) is less frequently used, that the mss without options...

• update comment to reflect current checks in the code

• address peter's feedback for rack and bbr

Seems you inadvertedly removed all reviewers; I added a bunch who probably want to chime in from the transport/ip side. I myself welcome this change - and maybe we should be backporting this to stable/14 and the upcoming release even.... I suspect most public deployments have that tunable toggled already?

Wouldn't it be possible to #define tcp_lro_log in a #else of the first block, such that this scattering of #ifdef's throughout the file could be avoided?

• use accessor in various drivers

• remove unneccesary style and line wrap changes

• implement suggested improvements

• remove unnecessary changes

While I agree that "goto" statements are not nice, and hard to follow - there is something to be said about the overhead of a function preamble, stack use and cleanup. I would suggest to make this an "__inline" function.

Thanks for the thorough review!

• fix typo, remove redundant all-flags definitions

In D47106#1073744, @kp wrote:

pf bits look good.

• log TCP flags properly in ppp

• prepare more ipf tools for AccECN

• decode ACE in libipf too
• expand ipf for AccECN compatibility

• missed function definition

• missed function definition

• clean up type and remove superfluous parenthesis
• revert adding support for TH_AE in ppp and pf

• extend the use of accessor function in userspace and pfil

In D47063#1073100, @kp wrote:

I'm happy with the pf bits.
It mostly doesn't matter because we tend to only look for th_flags flags and not th_x2, but it's probably better to use the accessor anyway.

We should probably do this too
...

• add TH_AE decoding (identical to tcpdump as "e") as suggested by kp
• moving updating the th_flags further down past the last adjustment

• use userspace accessor function

thanks!

• fix typo after rebase

In D43470#1072656, @cc wrote:

Because of commit 440f4ba18e3a, please re-base.

• rebase main

Good find! While there is probably zero difference as the compiler optimizes this, keeping "old_len" instead would only require the clearing of TH_FIN, and not another assignment though, which seems more alike to similar other checks... @tuexen @cc and @rrs may want to have a look too...