It's been two weeks with no further input. I just pinged rstone directly with a last-call. If there are no further objections in the next 8 hours or so, I plan to commit this as-is.

In D3060#60525, @hiren wrote:

https://www.ietf.org/rfc/rfc1323.txt mentions:

The Timestamp Echo Reply field (TSecr) is only valid if the ACK
bit is set in the TCP header; if it is valid, it echos a times-
tamp value that was sent by the remote TCP in the TSval field
of a Timestamps option.  When TSecr is not valid, its value
must be zero.

Which I brought up to Patrick but then he mentioned that while following this and always initializing the tsecr field early in tcpopt processing would be the correct thing to do but the code is already established elsewhere to 1) check the option flag for the timestamp option and then 2) check if the value is not zero.

And I agree that because of that reasoning, the proposed fix seems sufficient to me.

Also adding network so someone else can also review this.

In D3007#59268, @wblock wrote:

Are the local changes FreeBSD-specific? To put it another way, can they be submitted upstream to avoid being lost on the next import? The man page changes look that way, at least.

In D2987#59000, @kib wrote:

This is probably fine.

But, from the description of the sysctlmemlock, it seems that the lock must be owned whenever sysctl_wire_old_buffer() is called, am I right ? If yes, I think an assertion that the lock is owned, should be added to the wire_old_buffer().

In D2922#57500, @erj wrote:

In D2922#57481, @pkelsey wrote:

In D2922#57477, @erj wrote:

Everything but the change in ixgbe_vf.c looks good to me.

It looks like the PF driver needs to not set CTS when it acks the reset request, instead of the VF driver ignoring the flag.

So ixgbe_vf_reset_msg() in if_ix.c needs to change instead.

It certainly wasn't clear to me what the implementation intent was with CTS flag, so I made this change in what appeared to be the most consistent way given the existing code. In this case, ixgbe_set_rar_vf(), ixgbe_set_uc_addr_vf(), and ixgbev_get_queues() served as the reference for what the VF side of things was doing before checking flags in the response header. Considering your requested change to the patch, would those also be changed under the same reasoning? Also, in if_ix.c, ixgbe_vf_get_queues() is setting IXGBE_VT_MSGTYPE_CTS in its response - should that also be eliminated as the receiver of that response is just masking it off?

My reasoning was "do it because it'll match the Linux PF's behavior" and not "I don't like the way you did it." AFAICT, the Linux PF doesn't send CTS on a VF reset request ACK because they don't think it's necessary. The VF is marked as being clear to send in their PF after their reset flow, so they might assume the VF would know it's clear to send if it receives a response.

In D2922#57477, @erj wrote:

Everything but the change in ixgbe_vf.c looks good to me.

It looks like the PF driver needs to not set CTS when it acks the reset request, instead of the VF driver ignoring the flag.

So ixgbe_vf_reset_msg() in if_ix.c needs to change instead.