netdev - Re: [PATCH net-next v3 2/3] devlink: add function unique identifier to devlink dev info

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: <20250422080238.00cbc3dc@kernel.org>
Date: Tue, 22 Apr 2025 08:02:38 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, tariqt@...dia.com, andrew+netdev@...n.ch,
 horms@...nel.org, donald.hunter@...il.com,
 kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH net-next v3 2/3] devlink: add function unique identifier
 to devlink dev info

On Tue, 22 Apr 2025 11:18:23 +0200 Jiri Pirko wrote:
> Sat, Apr 19, 2025 at 02:20:15AM +0200, kuba@...nel.org wrote:
> >On Fri, 18 Apr 2025 12:15:01 +0200 Jiri Pirko wrote:  
> >> Ports does not look suitable to me. In case of a function with multiple
> >> physical ports, would the same id be listed for multiple ports? What
> >> about representors?  
> >
> >You're stuck in nVidia thinking. PF port != Ethernet port.
> >I said PF port.  
> 
> PF port representor represents the eswitch side of the link to the
> actual PF. The PF may or may not be on the same host.
> 
> Ethernet port is physical port.
> 
> Why this is nVidia thinking? How others understand it?

Because you don't have a PF port for local PF.

The information you want to convey is which of the PF ports is "local".
I believe we discussed this >5 years ago when I was trying to solve
this exact problem for the NFP.

The topology information belongs on the ports, not the main instance.

> >> This is a function propertly, therefore it makes sense to me to put it
> >> on devlink instance as devlink instance represents the function.
> >> 
> >> Another patchset that is most probably follow-up on this by one of my
> >> colleagues will introduce fuid propertly on "devlink port function".
> >> By that and the info exposed by this patch, you would be able to identify
> >> which representor relates to which function cross-hosts. I think that
> >> your question is actually aiming at this, isn't it?  
> >
> >Maybe it's time to pay off some technical debt instead of solving all
> >problems with yet another layer of new attributes :(  
> 
> What do you mean by this? 

I keep saying that the devlink instance should represent the chip /
data processing pipeline.

> We need a way to identify port representor
> (PF/VF/SF, does not matter which) and the other side of the wire that
> may be on a different host. How else do you imagine to do the
> identification of these 2 sides?