In D31149#703220, @hselasky wrote:

@np: Is is possible you could send the changes as an incremental diff to: hselasky@freebsd.org ?

In D31149#701525, @hselasky wrote:

@np: I'd like to push this by end of week. Please respond!

I know it's not directly related but the 'if' here is not needed. If you're tightening the len checks in the function then maybe clean this too?

Thanks for the fix. Please add a "Fixes: 43bbae19483fbde0a91e61acad8a6e71e334c8b8" line to the commit log before checking it in.

I can confirm that this change fixes the problem for me.

Acquire reg_lock around read_vf_stat instead of in a loop in the function.

By the way there's an "MTU" section in the vxlan(4) man page and you might want to update it with this new behavior.

In D29501#661249, @np wrote:

vxlan_setup_interface_hdrlen() can be called repeatedly and if the vxlan interface is down it will call vxlan_ctrl_set_remote_addr(). if_mtu will get decremented every time and that's not correct.

vxlan_setup_interface_hdrlen() can be called repeatedly and if the vxlan interface is down it will call vxlan_ctrl_set_remote_addr(). if_mtu will get decremented every time and that's not correct.

Let's land this if it's ready.

There's also this in t4_main.c that needs to be updated to sizeof(struct sge_ofld_txq):

The offload tx queues are also used for RATELIMIT tx and we should either set cxgbe_rate_tag->eo_txq to ofld_txq->wrq in ethofld_transmit or change eo_txq to be a sge_ofld_txq.

"NIC TLS" instead of "KTLS" in the message as suggested by jhb@.