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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204180256.1476f537@kernel.org>
Date: Wed, 4 Feb 2026 18:02:56 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Tariq Toukan <tariqt@...dia.com>, 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>, 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>, Simon Horman
 <horms@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH net-next V7 01/14] documentation: networking: add shared
 devlink documentation

On Wed, 4 Feb 2026 08:12:00 +0100 Jiri Pirko wrote:
> Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@...nel.org wrote:
> >On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:  
> >> How exactly you can have a single devlink instance for multiple PFs of a
> >> same device? I don't really understand how that could work, considering
> >> dynamic binds/unbinds of the PFs within single host and/or multiple VMs
> >> passing PFs to.  
> >
> >The same way you currently gather up the devlink instances to create
> >the shared instance.  
> 
> What's the backing device / handle (busname/devname)? Best would be to
> draw a picture, as always :)

Either the bus/dev that shows up first or we go back to index.
(My main point being that the single instance is strictly better
than shared, ie. no problem exists in single instance multi func
which does not exist in multi instance + extra instance multi func.
But some problems do exist in multi instance which do not in single
like the locking)

> >> Okay. I originally wanted to use an id, similar to what we have in
> >> the dpll. However I was forced by community to tie the instance to
> >> bus/device. It is how it is, any idea how to relax this bond?  
> >
> >Interesting! I was curious to research how we ended up here, found this:
> >https://lore.kernel.org/netdev/20160225225803.GA2191@nanopsycho.orion/
> >My reading is that Hannes was arguing against the _NAME attribute but
> >both _NAME and _INDEX were deleted? I think there's nothing wrong with
> >an index.  
> 
> He argues for "stable topology indentifiers", which randomly assigned
> index is not.

Agreed, I love me a stable identifier myself! :) That does not mean 
we can't have ID _as well_ as the identifiers. Which lets us add
more stable identifiers and/or making some optional.

I think I was trying to sell you on "more stable identifiers" 
as a alternative to ALT_NAMEs for netdevs at some point ;)
Maybe I'm projecting that conversation onto what Hannes said.

> >FWIW using devlink day to day, the bus/device is not at all useful as
> >an identifier. Most of code touching devlink at Meta either matches
> >on devlink dev info or assumes there's one instance on the system.  
> 
> Okay, what's your suggestion going foreward then?

Add the ID back, make bus/dev optional, forgo the faux dev?
Would that work? Would exiting CLI become very unhappy? :S

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ