Change Details

A while back Hans optimized the LRO code. This is great but one optimization he did degrades the timestamp precision so that all flushed LRO entries end up with the same LRO timestamp if there is not a hardware timestamp. The intent of the LRO timestamp is to get as close to the time that the packet arrived as possible. Without the LRO queuing this works out fine since a binuptime is taken and then the rx_common code is called. But when you go through the queue path you end up *not* updating the M_LRO_TSTMP fields. Lets fix this so that we restore the precision to the timestamp.

A while back Hans optimized the LRO code. This is great but one optimization he did degrades the timestamp precision so that all flushed LRO entries end up with the same LRO timestamp if there is not a hardware timestamp. The intent of the LRO timestamp is to get as close to the time that the packet arrived as possible. Without the LRO queuing this works out fine since a binuptime is taken and then the rx_common code is called. But when you go through the queue path you end up *not* updating the M_LRO_TSTMP fields. Another issue in the LRO code is several places that cause packet reordering. In general TCP can handle reordering but it can cause extra un-needed retransmission as well as other oddities. We will fix all of the reordering problems. Lets fix this so that we restore the precision to the timestamp.

A while back Hans optimized the LRO code. This is great but one optimization he did degrades the timestamp precision so that all flushed LRO entries end up with the same LRO timestamp if there is not a hardware timestamp. The intent of the LRO timestamp is to get as close to the time that the packet arrived as possible. Without the LRO queuing this works out fine since a binuptime is taken and then the rx_common code is called. But when you go through the queue path you end up *not* updating the M_LRO_TSTMP fields. Another issue in the LRO code is several places that cause packet reordering. In general TCP can handle reordering but it can cause extra un-needed retransmission as well as other oddities. We will fix all of the reordering problems. Lets fix this so that we restore the precision to the timestamp.