netdev - Re: [PATCH 0/5] Rust abstractions for network device drivers

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <762a7d75-2ed8-4f29-b8e5-c90305275c9e@lunn.ch>
Date: Fri, 16 Jun 2023 15:20:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Alice Ryhl <alice@...l.io>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	rust-for-linux@...r.kernel.org, aliceryhl@...gle.com,
	miguel.ojeda.sandonis@...il.com,
	FUJITA Tomonori <fujita.tomonori@...il.com>
Subject: Re: [PATCH 0/5] Rust abstractions for network device drivers

> As for this being a single function rather than four functions, that's
> definitely a debatable decision. You would only do that if it makes sense to
> merge them together and if you would always assign all of them together. I
> don't know enough about these fields to say whether it makes sense here.

It can actually make sense to do them all together, because the source
of these is likely to be a per CPU data structure protected by a per
CPU sequence lock. You iterate over all CPUs, doing a transaction,
taking the sequence lock, copy the values, and then releasing the
lock. Taking and releases the lock per value is unnecessary expense.

      Andrew