netdev - [RFC PATCH] devlink: Introduce rate domains

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-next>] [day] [month] [year] [list]

Message-ID: <20241113203317.2507537-1-cratiu@nvidia.com>
Date: Wed, 13 Nov 2024 22:30:37 +0200
From: Cosmin Ratiu <cratiu@...dia.com>
To: <netdev@...r.kernel.org>
CC: <jiri@...nulli.us>, <tariqt@...dia.com>, <kuba@...nel.org>,
	<saeedm@...dia.com>, <cratiu@...dia.com>
Subject: [RFC PATCH] devlink: Introduce rate domains

Hi,

This patch series extends devlink rates with support for tx scheduling spanning
multiple physical functions. The full explanation is in the cover letter and in
the individual patch messages.

More context for the series:

I have tried and rejected several other approaches, because they do not work:
1. Acquiring multiple devlinks locks. Requires defining a lock order and gets
extremely messy really fast.
2. Using a single global rate lock in addition to the devlink object lock.
Cleaner than failed approach number 1, but feels like a regression back to the
global devlink lock days.
3. Using weak references instead of pointers for parent relationships. Doesn't
work because I couldn't find a way to fetch the associated priv pointer of a
parent rate node from another devlink without acquiring that object's lock.
4. Jiri tried a more general approach: defining a shared parent devlink object
to represent the hardware. That object could then be used to store devlink
rates. Unforeseen complexity unfortunately threw a wrench in that.

The approach in this patchset is well tested and it works. But after some
discussions with Jiri, he's not too happy about the added complexity so I'm
sending this as RFC first to gather opinions on alternative approaches, if any
exist. I want to ask people if they think the approach is good and if not,
perhaps suggest alternatives.

Thank you,
Cosmin.