netdev - Re: [PATCH net-next V4 02/14] documentation: networking: add shared devlink documentation

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: <20251127201645.3d7a10f6@kernel.org>
Date: Thu, 27 Nov 2025 20:16:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Tariq Toukan <tariqt@...dia.com>
Cc: Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Donald Hunter <donald.hunter@...il.com>, Jiri Pirko
 <jiri@...nulli.us>, Jonathan Corbet <corbet@....net>, Saeed Mahameed
 <saeedm@...dia.com>, "Leon Romanovsky" <leon@...nel.org>, Mark Bloch
 <mbloch@...dia.com>, <netdev@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
 <linux-rdma@...r.kernel.org>, Gal Pressman <gal@...dia.com>, Moshe Shemesh
 <moshe@...dia.com>, Carolina Jubran <cjubran@...dia.com>, Cosmin Ratiu
 <cratiu@...dia.com>, Jiri Pirko <jiri@...dia.com>, Randy Dunlap
 <rdunlap@...radead.org>
Subject: Re: [PATCH net-next V4 02/14] documentation: networking: add shared
 devlink documentation

On Tue, 25 Nov 2025 22:06:01 +0200 Tariq Toukan wrote:
> From: Jiri Pirko <jiri@...dia.com>
> 
> Document shared devlink instances for multiple PFs on the same chip.
> 
> Signed-off-by: Jiri Pirko <jiri@...dia.com>
> Reviewed-by: Cosmin Ratiu <cratiu@...dia.com>
> Signed-off-by: Tariq Toukan <tariqt@...dia.com>
> ---
>  .../networking/devlink/devlink-shared.rst     | 66 +++++++++++++++++++
>  Documentation/networking/devlink/index.rst    |  1 +
>  2 files changed, 67 insertions(+)
>  create mode 100644 Documentation/networking/devlink/devlink-shared.rst
> 
> diff --git a/Documentation/networking/devlink/devlink-shared.rst b/Documentation/networking/devlink/devlink-shared.rst
> new file mode 100644
> index 000000000000..be9dd6f295df
> --- /dev/null
> +++ b/Documentation/networking/devlink/devlink-shared.rst
> @@ -0,0 +1,66 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +============================
> +Devlink Shared Instances
> +============================
> +
> +Overview
> +========
> +
> +Shared devlink instances allow multiple physical functions (PFs) on the same
> +chip to share an additional devlink instance for chip-wide operations. This
> +should be implemented within individual drivers alongside the individual PF
> +devlink instances, not replacing them.
> +
> +The shared devlink instance should be backed by a faux device and should
> +provide a common interface for operations that affect the entire chip
> +rather than individual PFs.

If we go with this we must state very clearly that this is a crutch and
_not_ the recommended configuration...

> +Implementation
> +==============
> +
> +Architecture
> +------------
> +
> +The implementation should use:
> +
> +* **Faux device**: Virtual device backing the shared devlink instance
> +* **Chip identification**: PFs are grouped by chip using a driver-specific identifier
> +* **Shared instance management**: Global list of shared instances with reference counting
> +
> +Initialization Flow
> +-------------------
> +
> +1. **PF calls shared devlink init** during driver probe
> +2. **Chip identification** using driver-specific method to determine device identity
> +3. **Lookup existing shared instance** for this chip identifier
> +4. **Create new shared instance** if none exists:
> +
> +   * Create faux device with chip identifier as name
> +   * Allocate and register devlink instance
> +   * Add to global shared instances list
> +
> +5. **Add PF to shared instance** PF list
> +6. **Set nested devlink instance** for the PF devlink instance

... because presumably we could use this infra to manage a single
devlink instance? Which is what I asked for initially.

> +Cleanup Flow
> +------------
> +
> +1. **Cleanup** when PF is removed; destroy shared instance when last PF is removed
> +
> +Chip Identification
> +-------------------
> +
> +PFs belonging to the same chip are identified using a driver-specific method.
> +The driver is free to choose any identifier that is suitable for determining
> +whether two PFs are part of the same device. Examples include VPD serial numbers,
> +device tree properties, or other hardware-specific identifiers.
> +
> +Locking
> +-------
> +
> +A global per-driver mutex protects the shared instances list and individual shared
> +instance PF lists during registration/deregistration.

Why can't this mutex live in the core?

> +Similarly to other nested devlink instance relationships, devlink lock of
> +the shared instance should be always taken after the devlink lock of PF.
> diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst
> index 35b12a2bfeba..f7ba7dcf477d 100644
> --- a/Documentation/networking/devlink/index.rst
> +++ b/Documentation/networking/devlink/index.rst
> @@ -68,6 +68,7 @@ general.
>     devlink-resource
>     devlink-selftests
>     devlink-trap
> +   devlink-shared
>  
>  Driver-specific documentation
>  -----------------------------