All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Tariq Toukan <tariqt@nvidia.com>
Cc: Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Donald Hunter <donald.hunter@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Jonathan Corbet <corbet@lwn.net>,
	Saeed Mahameed <saeedm@nvidia.com>,
	"Leon Romanovsky" <leon@kernel.org>,
	Mark Bloch <mbloch@nvidia.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-rdma@vger.kernel.org>, Gal Pressman <gal@nvidia.com>,
	Moshe Shemesh <moshe@nvidia.com>,
	Carolina Jubran <cjubran@nvidia.com>,
	Cosmin Ratiu <cratiu@nvidia.com>, Jiri Pirko <jiri@nvidia.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Simon Horman <horms@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH net-next V7 02/14] devlink: introduce shared devlink instance for PFs on same chip
Date: Mon, 2 Feb 2026 19:49:46 -0800	[thread overview]
Message-ID: <20260202194946.64555356@kernel.org> (raw)
In-Reply-To: <20260128112544.1661250-3-tariqt@nvidia.com>

On Wed, 28 Jan 2026 13:25:32 +0200 Tariq Toukan wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> Multiple PFs may reside on the same physical chip, running a single
> firmware. Some of the resources and configurations may be shared among
> these PFs. Currently, there is no good object to pin the configuration
> knobs on.
> 
> Introduce a shared devlink instance, instantiated upon probe of the
> first PF and removed during remove of the last PF. The shared devlink
> instance is backed by a faux device, as there is no PCI device related
> to it. The implementation uses reference counting to manage the
> lifecycle: each PF that probes calls devlink_shd_get() to get or create
> the shared instance, and calls devlink_shd_put() when it removes. The
> shared instance is automatically destroyed when the last PF removes.

> diff --git a/include/net/devlink.h b/include/net/devlink.h
> index cb839e0435a1..c453faec8ebf 100644
> --- a/include/net/devlink.h
> +++ b/include/net/devlink.h
> @@ -1644,6 +1644,12 @@ void devlink_register(struct devlink *devlink);
>  void devlink_unregister(struct devlink *devlink);
>  void devlink_free(struct devlink *devlink);
>  
> +struct devlink *devlink_shd_get(const char *id,
> +				const struct devlink_ops *ops,
> +				size_t priv_size);
> +void devlink_shd_put(struct devlink *devlink);
> +void *devlink_shd_get_priv(struct devlink *devlink);

Would Cosmin or someone else be willing to take on co-maintainership 
of this API (including reviews of other drivers using it)?
We could add a maintainers entry with:

K:	devlink_shd_

So y'all get CCed.

> +#include <linux/device/faux.h>
> +#include <net/devlink.h>

> +/* This structure represents a shared devlink instance,
> + * there is one created per identifier (e.g., serial number).
> + */
> +struct devlink_shd {
> +	struct list_head list; /* Node in shd list */
> +	const char *id; /* Identifier string (e.g., serial number) */

Why does this have to be a string? The identifier should be irrelevant,
and if something like serial number exists it can be reported in dev
info for the shared instance?

> +	struct faux_device *faux_dev; /* Related faux device */
> +	refcount_t refcount; /* Reference count */
> +	char priv[] __aligned(NETDEV_ALIGN); /* Driver private data */

size member annotated with __counted_by() is missing here

> +};

> +static struct devlink_shd *devlink_shd_create(const char *id,
> +					      const struct devlink_ops *ops,
> +					      size_t priv_size)
> +{
> +	struct faux_device *faux_dev;
> +	struct devlink_shd *shd;
> +	struct devlink *devlink;
> +
> +	/* Create faux device - probe will be called synchronously */
> +	faux_dev = faux_device_create(id, NULL, NULL);
> +	if (!faux_dev)
> +		return NULL;
> +
> +	devlink = devlink_alloc(ops, sizeof(struct devlink_shd) + priv_size,
> +				&faux_dev->dev);
> +	if (!devlink)
> +		goto err_devlink_alloc;

error labels should be named after the target not the source in new code

> +	shd = devlink_priv(devlink);
> +
> +	shd->id = kstrdup(id, GFP_KERNEL);
> +	if (!shd->id)
> +		goto err_kstrdup_id;
> +	shd->faux_dev = faux_dev;
> +	refcount_set(&shd->refcount, 1);
> +
> +	devl_lock(devlink);
> +	devl_register(devlink);
> +	devl_unlock(devlink);
> +
> +	list_add_tail(&shd->list, &shd_list);
> +
> +	return shd;
> +
> +err_kstrdup_id:
> +	devlink_free(devlink);
> +
> +err_devlink_alloc:
> +	faux_device_destroy(faux_dev);
> +	return NULL;
> +}

> +struct devlink *devlink_shd_get(const char *id,
> +				const struct devlink_ops *ops,
> +				size_t priv_size)
> +{
> +	struct devlink_shd *shd;
> +
> +	if (WARN_ON(!id || !ops))
> +		return NULL;

Seems a little too defensive to check input attrs against NULL.
Let the kernel crash if someone is foolish enough..

> +	mutex_lock(&shd_mutex);
> +
> +	shd = devlink_shd_lookup(id);
> +	if (!shd)
> +		shd = devlink_shd_create(id, ops, priv_size);
> +	else
> +		refcount_inc(&shd->refcount);
> +
> +	mutex_unlock(&shd_mutex);
> +	return shd ? priv_to_devlink(shd) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(devlink_shd_get);
> +
> +/**
> + * devlink_shd_put - Release a reference on a shared devlink instance
> + * @devlink: Shared devlink instance
> + *
> + * Release a reference on a shared devlink instance obtained via
> + * devlink_shd_get().
> + */
> +void devlink_shd_put(struct devlink *devlink)
> +{
> +	struct devlink_shd *shd;
> +
> +	if (WARN_ON(!devlink))
> +		return;

ditto

> +	mutex_lock(&shd_mutex);
> +	shd = devlink_priv(devlink);
> +	if (refcount_dec_and_test(&shd->refcount))
> +		devlink_shd_destroy(shd);
> +	mutex_unlock(&shd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(devlink_shd_put);

  reply	other threads:[~2026-02-03  3:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-28 11:25 [PATCH net-next V7 00/14] devlink and mlx5: Support cross-function rate scheduling Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 01/14] documentation: networking: add shared devlink documentation Tariq Toukan
2026-02-03  3:40   ` Jakub Kicinski
2026-02-03  9:18     ` Jiri Pirko
2026-02-04  3:01       ` Jakub Kicinski
2026-02-04  7:12         ` Jiri Pirko
2026-02-05  2:02           ` Jakub Kicinski
2026-02-06 10:52             ` Jiri Pirko
2026-02-07  1:50               ` Jakub Kicinski
2026-01-28 11:25 ` [PATCH net-next V7 02/14] devlink: introduce shared devlink instance for PFs on same chip Tariq Toukan
2026-02-03  3:49   ` Jakub Kicinski [this message]
2026-02-03  9:44     ` Jiri Pirko
2026-02-04  2:42       ` Jakub Kicinski
2026-02-04  7:15         ` Jiri Pirko
2026-02-05  2:06           ` Jakub Kicinski
2026-01-28 11:25 ` [PATCH net-next V7 03/14] devlink: Reverse locking order for nested instances Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 04/14] devlink: Add helpers to lock nested-in instances Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 05/14] devlink: Refactor devlink_rate_nodes_check Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 06/14] devlink: Decouple rate storage from associated devlink object Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 07/14] devlink: Add parent dev to devlink API Tariq Toukan
2026-02-03  4:00   ` Jakub Kicinski
2026-02-11 16:28     ` Cosmin Ratiu
2026-02-11 16:57       ` Jakub Kicinski
2026-01-28 11:25 ` [PATCH net-next V7 08/14] devlink: Allow parent dev for rate-set and rate-new Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 09/14] devlink: Allow rate node parents from other devlinks Tariq Toukan
2026-02-03  4:04   ` Jakub Kicinski
2026-01-28 11:25 ` [PATCH net-next V7 10/14] net/mlx5: Add a shared devlink instance for PFs on same chip Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 11/14] net/mlx5: Expose a function to clear a vport's parent Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 12/14] net/mlx5: Store QoS sched nodes in the sh_devlink Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 13/14] net/mlx5: qos: Support cross-device tx scheduling Tariq Toukan
2026-01-28 11:25 ` [PATCH net-next V7 14/14] net/mlx5: Document devlink rates Tariq Toukan
2026-02-03  4:09 ` [PATCH net-next V7 00/14] devlink and mlx5: Support cross-function rate scheduling Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260202194946.64555356@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=cjubran@nvidia.com \
    --cc=corbet@lwn.net \
    --cc=cratiu@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=horms@kernel.org \
    --cc=jiri@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=krzk@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.