[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241202194429.0cec6f2e@kernel.org>
Date: Mon, 2 Dec 2024 19:44:29 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: netdev@...r.kernel.org, Marc Dionne <marc.dionne@...istor.com>, Yunsheng
Lin <linyunsheng@...wei.com>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
linux-afs@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 16/37] rxrpc: Implement progressive
transmission queue struct
On Mon, 2 Dec 2024 14:30:34 +0000 David Howells wrote:
> We need to scan the buffers in the transmission queue occasionally when
> processing ACKs, but the transmission queue is currently a linked list of
> transmission buffers which, when we eventually expand the Tx window to 8192
> packets will be very slow to walk.
>
> Instead, pull the fields we need to examine a lot (last sent time,
> retransmitted flag) into a new struct rxrpc_txqueue and make each one hold
> an array of 32 or 64 packets.
>
> The transmission queue is then a list of these structs, each pointing to a
> contiguous set of packets. Scanning is then a lot faster as the flags and
> timestamps are concentrated in the CPU dcache.
>
> The transmission timestamps are stored as a number of microseconds from a
> base ktime to reduce memory requirements. This should be fine provided we
> manage to transmit an entire buffer within an hour.
>
> This will make implementing RACK-TLP [RFC8985] easier as it will be less
> costly to scan the transmission buffers.
also possibly transient but clang says:
net/rxrpc/output.c:815:20: warning: unused function 'rxrpc_instant_resend' [-Wunused-function]
815 | static inline void rxrpc_instant_resend(struct rxrpc_call *call)
| ^~~~~~~~~~~~~~~~~~~~
Powered by blists - more mailing lists