[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3327953.1699567608@warthog.procyon.org.uk>
Date: Thu, 09 Nov 2023 22:06:48 +0000
From: David Howells <dhowells@...hat.com>
To: Jeffrey E Altman <jaltman@...istor.com>
Cc: dhowells@...hat.com, Marc Dionne <marc.dionne@...istor.com>,
linux-afs@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/41] rxrpc: Fix RTT determination to use PING ACKs as a source
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
Powered by blists - more mailing lists