I'm going to drop this patch from this series for now and send it separately. > I do not believe the ack_reason matters within rxrpc_input_ack(). As long as > the acked_serial is non-zero, > rxrpc_complete_rtt_probe() can be called to attempt to compute an RTT. If > there is an exact match for the > acked_serial then an RTT can be computed and if acked_serial is later than the > pending rtt probe, the probe > can be abandoned with the following caveats. > > 1. Receiving an acked_serial that is later than the serial of the > transmitted probe indicates that a packet > transmitted after the probe was received first. Or that reordering > of the transmitted packets occurred. > Or that the probe was never received by the peer; or that the peer's > response to the probe was lost in > transit. > 2. The serial number namespace is unsigned 32-bit shared across all of > the call channels of the associated > rx connection. As the serial numbers will wrap the use of after() > within rxrpc_complete_rtt_probe to > compare their values is questionable. If serial numbers will be > compared in this manner then they > need to be locally tracked and compared as unsigned 64-bit values > where only the low 32-bits are > transmitted on the wire and any wire serial number equal to zero is > ignored. I do ignore ack.serial == 0 for this purpose. I'm not sure how expanding it internally to 64-bits actually helps since the upper 32 bits is not visible to the peer. David
