In D44258#1087685, @kbowling wrote:

@tuexen just a note that the X552 is also using the same middle value as 82599

In D47439#1081965, @cc wrote:

I think you meant the title be:
tcp: consistently set CWND to MSS => tcp: consistently set CWND to 1
in case of SYN/SYN ACK retransmissions => in case of SYN retransmissions

In D47401#1081163, @rscheff wrote:

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?

#ifdef TCP_BLACKBOX
static void
tcp_lro_log(struct tcpcb *tp, const struct lro_ctrl *lc,
    const struct lro_entry *le, const struct mbuf *m,
    int frm, int32_t tcp_data_len, uint32_t th_seq,
    uint32_t th_ack, uint16_t th_win)
{
:
}
#else
#define tcp_lro_log(tp, lc, le, m, frm, tcp_data_len, th_seq, th_ack, th_win)
#endif

Do you mean tcp: allow TSO even while RX path is unordered instead of tcp: allow LRO even while RX path is unordered?

In D46884#1071271, @emaste wrote:

In D46884#1069128, @tuexen wrote:

It would be great if you can do a functional test...

See D46999, D46995 and D47000

In D46881#1069245, @markj wrote:

All of the races are harmless though, i.e., the getsockopt call would return garbage in the worst case. There might be applications which query these socket options frequently, especially the socket buffer sizes. Do you think the extra overhead of acquiring the socket lock is unlikely to matter?

It would be great if you can do a functional test...

In D46824#1068981, @jhb wrote:

I can fix the type mismatch during commit. I have not looked to see if other stacks are affected.