lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ