Page MenuHomeFreeBSD

lro has a loss of timestamp precision.
Needs ReviewPublic

Authored by rrs on Thu, Aug 4, 3:33 PM.

Details

Reviewers
tuexen
hselasky
gallatin
Group Reviewers
transport
Summary

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.

Test Plan

Use BB logs to make sure we no longer have the same
timestamp in all packets on one LRO flush like we do now.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

rrs requested review of this revision.Thu, Aug 4, 3:33 PM

Drew suggested we use the mbufqueue flag as an indication that
we have stacks that are interested in the M_TSTMP_LRO so we only
do it if thats true.

Just found an interesting bug when SACKs are mixing in with compressed acks. We can
push the acks in the wrong order by remembering the last compressed ack we were filling.
We should NULL the cmp field when it turns out we have to add a packet that is
not-compressable.

sys/netinet/tcp_lro.c
1958

Should this code block be after the IFCAP_LRO check or not?

1960

Fix comment: check if device is not LRO capable