All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Jiri Pirko <jiri@resnulli.us>, Cosmin Ratiu <cratiu@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>,
	netdev@vger.kernel.org, Konrad Knitter <konrad.knitter@intel.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	davem@davemloft.net, Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	linux-kernel@vger.kernel.org,
	ITP Upstream <nxne.cnse.osdt.itp.upstreaming@intel.com>,
	Carolina Jubran <cjubran@nvidia.com>
Subject: Re: [Intel-wired-lan] [RFC net-next v2 1/2] devlink: add whole device devlink instance
Date: Thu, 20 Feb 2025 17:45:12 -0800	[thread overview]
Message-ID: <20250220174512.578eebe8@kernel.org> (raw)
In-Reply-To: <20250219164410.35665-2-przemyslaw.kitszel@intel.com>

On Wed, 19 Feb 2025 17:32:54 +0100 Przemek Kitszel wrote:
> Add a support for whole device devlink instance. Intented as a entity
> over all PF devices on given physical device.
> 
> In case of ice driver we have multiple PF devices (with their devlink
> dev representation), that have separate drivers loaded. However those
> still do share lots of resources due to being the on same HW. Examples
> include PTP clock and RSS LUT. Historically such stuff was assigned to
> PF0, but that was both not clear and not working well. Now such stuff
> is moved to be covered into struct ice_adapter, there is just one instance
> of such per HW.
> 
> This patch adds a devlink instance that corresponds to that ice_adapter,
> to allow arbitrage over resources (as RSS LUT) via it (further in the
> series (RFC NOTE: stripped out so far)).
> 
> Thanks to Wojciech Drewek for very nice naming of the devlink instance:
> PF0:		pci/0000:00:18.0
> whole-dev:	pci/0000:00:18
> But I made this a param for now (driver is free to pass just "whole-dev").

Which only works nicely if you're talking about functions not full
separate links :) When I was thinking about it a while back my
intuition was that we should have a single instance, just accessible
under multiple names. But I'm not married to that direction if there
are problems with it.

> $ devlink dev # (Interesting part of output only)
> pci/0000:af:00:
>   nested_devlink:
>     pci/0000:af:00.0
>     pci/0000:af:00.1
>     pci/0000:af:00.2
>     pci/0000:af:00.3
>     pci/0000:af:00.4
>     pci/0000:af:00.5
>     pci/0000:af:00.6
>     pci/0000:af:00.7

Could you go into more details on what stays on the "nested" instances
and what moves to the "whole-dev"? Jiri recently pointed out to y'all
cases where stuff that should be a port attribute was an instance
attribute.

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Jiri Pirko <jiri@resnulli.us>, Cosmin Ratiu <cratiu@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>,
	netdev@vger.kernel.org, Konrad Knitter <konrad.knitter@intel.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	davem@davemloft.net, Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	linux-kernel@vger.kernel.org,
	ITP Upstream <nxne.cnse.osdt.itp.upstreaming@intel.com>,
	Carolina Jubran <cjubran@nvidia.com>
Subject: Re: [RFC net-next v2 1/2] devlink: add whole device devlink instance
Date: Thu, 20 Feb 2025 17:45:12 -0800	[thread overview]
Message-ID: <20250220174512.578eebe8@kernel.org> (raw)
In-Reply-To: <20250219164410.35665-2-przemyslaw.kitszel@intel.com>

On Wed, 19 Feb 2025 17:32:54 +0100 Przemek Kitszel wrote:
> Add a support for whole device devlink instance. Intented as a entity
> over all PF devices on given physical device.
> 
> In case of ice driver we have multiple PF devices (with their devlink
> dev representation), that have separate drivers loaded. However those
> still do share lots of resources due to being the on same HW. Examples
> include PTP clock and RSS LUT. Historically such stuff was assigned to
> PF0, but that was both not clear and not working well. Now such stuff
> is moved to be covered into struct ice_adapter, there is just one instance
> of such per HW.
> 
> This patch adds a devlink instance that corresponds to that ice_adapter,
> to allow arbitrage over resources (as RSS LUT) via it (further in the
> series (RFC NOTE: stripped out so far)).
> 
> Thanks to Wojciech Drewek for very nice naming of the devlink instance:
> PF0:		pci/0000:00:18.0
> whole-dev:	pci/0000:00:18
> But I made this a param for now (driver is free to pass just "whole-dev").

Which only works nicely if you're talking about functions not full
separate links :) When I was thinking about it a while back my
intuition was that we should have a single instance, just accessible
under multiple names. But I'm not married to that direction if there
are problems with it.

> $ devlink dev # (Interesting part of output only)
> pci/0000:af:00:
>   nested_devlink:
>     pci/0000:af:00.0
>     pci/0000:af:00.1
>     pci/0000:af:00.2
>     pci/0000:af:00.3
>     pci/0000:af:00.4
>     pci/0000:af:00.5
>     pci/0000:af:00.6
>     pci/0000:af:00.7

Could you go into more details on what stays on the "nested" instances
and what moves to the "whole-dev"? Jiri recently pointed out to y'all
cases where stuff that should be a port attribute was an instance
attribute.

  parent reply	other threads:[~2025-02-21  1:54 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 16:32 [Intel-wired-lan] [RFC net-next v2 0/2] devlink: whole-device, resource .occ_set() Przemek Kitszel
2025-02-19 16:32 ` Przemek Kitszel
2025-02-19 16:32 ` [Intel-wired-lan] [RFC net-next v2 1/2] devlink: add whole device devlink instance Przemek Kitszel
2025-02-19 16:32   ` Przemek Kitszel
2025-02-19 22:11   ` [Intel-wired-lan] " Jacob Keller
2025-02-19 22:11     ` Jacob Keller
2025-02-21  1:45   ` Jakub Kicinski [this message]
2025-02-21  1:45     ` Jakub Kicinski
2025-02-21 22:50     ` [Intel-wired-lan] " Jacob Keller
2025-02-21 22:50       ` Jacob Keller
2025-02-24 10:15       ` [Intel-wired-lan] " Przemek Kitszel
2025-02-24 10:15         ` Przemek Kitszel
2025-02-24 13:03     ` [Intel-wired-lan] " Jiri Pirko
2025-02-24 13:03       ` Jiri Pirko
2025-02-24 22:09       ` [Intel-wired-lan] " Jacob Keller
2025-02-24 22:09         ` Jacob Keller
2025-02-24 16:14   ` [Intel-wired-lan] " Jiri Pirko
2025-02-24 16:14     ` Jiri Pirko
2025-02-24 22:12     ` [Intel-wired-lan] " Jacob Keller
2025-02-24 22:12       ` Jacob Keller
2025-02-25 11:30     ` [Intel-wired-lan] " Przemek Kitszel
2025-02-25 11:30       ` Przemek Kitszel
2025-02-25 14:35       ` [Intel-wired-lan] " Jiri Pirko
2025-02-25 14:35         ` Jiri Pirko
2025-02-25 15:40         ` [Intel-wired-lan] " Przemek Kitszel
2025-02-25 15:40           ` Przemek Kitszel
2025-02-25 18:16           ` [Intel-wired-lan] " Jacob Keller
2025-02-25 18:16             ` Jacob Keller
2025-02-26 14:48           ` [Intel-wired-lan] " Jiri Pirko
2025-02-26 14:48             ` Jiri Pirko
2025-02-26 15:06             ` [Intel-wired-lan] " Przemek Kitszel
2025-02-26 15:06               ` Przemek Kitszel
2025-02-26 15:25               ` [Intel-wired-lan] " Jiri Pirko
2025-02-26 15:25                 ` Jiri Pirko
2025-03-18 15:42   ` [Intel-wired-lan] " Jiri Pirko
2025-03-18 15:42     ` Jiri Pirko
2025-02-19 16:32 ` [Intel-wired-lan] [RFC net-next v2 2/2] devlink: give user option to allocate resources Przemek Kitszel
2025-02-19 16:32   ` Przemek Kitszel

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=20250220174512.578eebe8@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=cjubran@nvidia.com \
    --cc=cratiu@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=konrad.knitter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nxne.cnse.osdt.itp.upstreaming@intel.com \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.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.