In D54718#1250105, @amy.vargas_netapp.com wrote:

I have not. I'm still getting familiar with the process. Should I submit there first and if so, would the new version of tcpdump just be picked up by FreeBSD with no need for this review?

• bump date of tcp.4

• bump date of tcp.4

In D52225#1193159, @tuexen wrote:

Is D52226 good enough or do you have suggestions to improve the clarity?

content appears to be a better matching what the code does. Thx.

Maybe also put an updated syncookies(4) man page update into this diff. Currently, that man page is not really clear on the distinctions between sysctl net.inet.tcp.syncookies and sysctl net.inet.tcp.syncookies_only. (the _only is mentioned, but not the relationship between syncache, syncookie and syncookie_only ).

Thanks for catching

I now wonder why i had the left_edge adjustment conditional on an fack adjustment only. But that may have preceeded some other modifications. LGTM

• rebase before commit

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