Change Details

When window scaling is in effect, very small receive windows (less than 1 << rcv_scale of available buffer space) can lead to deadlock situations with certain (older) linux clients, which will start sending window probes below the acceptable sequence number. An earlier approach was to unconditionally roundup2 the receive window before sending out the ACK. However, the rounded up value allows senders to grow their send/congestion window beyond the acceptable window, leading to a loss in performance. Reported-by: Cui Cheng (Aug 2016)

When window scaling is in effect, rounding down the scaled down receive window (which a right shift effectively does) can lead to deadlock situations with certain (older) linux clients, which will start sending window probes while reneging the sequence number below our acceptable sequence number. In transactional scenarios the sender, while still transmitting new data, may have shrunk or even zeroed its own window. Due to the scaled window granularity, and the reneging of the sequence number, an eventual window update would be ignored by the FreeBSD stack since that sequence number is below the acceptable range. An earlier approach tried internally was to unconditionally roundup2 only the receive window to be sent out. However, as the rounded up value was not tracked also in tp->rcv_adv and received data segment may fall beyond the window allowed by tp->rcv_adv, this was lead to a loss in performance. Further testing showed, that retaining the rounded-up value and updating tp->rcv_adv using the value the sender would receive addresses these performance concerns completely. Reported-by: Cui Cheng (Aug 2016)

When window scaling is in effect, very smallrounding down the scaled down receive windows (less than 1 << rcv_scale of available (which a right shift effectively does) can lead to deadlock situations with buffer space) can lead to deadlock situations with certain (older) linux clients, which will start sending window probes below the acceptablwhile reneging the sequence number. An earlier approach was to unconditionally roundup2 theer receive window before sending out the ACK.below our acceptable sequence number. In transactional scenarios the sender, while still transmitting new data, may have shrunk or even zeroed its own window. Due to the scaled window granularity, Howeverand the reneging of the sequence number, thean eventual window update rounded up value allows senders to grow their send/congestionwould be ignored by the FreeBSD stack since that sequence window beyondnumber is below the acceptable window, leadingrange. An earlier approach tried internally was to aunconditionally roundup2 only the receive window to be sent out. However, as the rounded up value was not tracked also in tp->rcv_adv and received data segment may fall beyond the window allowed by tp->rcv_adv, this was lead to a loss in performance. Further testing showed, that retaining the rounded-up value and updating tp->rcv_adv using the value the sender would receive addresses these performance concerns completely. Reported-by: Cui Cheng (Aug 2016)