Re: [PATCH 01/41] rxrpc: Fix RTT determination to use PING ACKs as a source

[David Howells]

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