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  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]
Date:   Wed, 2 Sep 2020 20:10:41 +0000
From:   Parav Pandit <>
To:     Parav Pandit <>, Jakub Kicinski <>,
        "Jiri Pirko" <>
CC:     Parav Pandit <>,
        "" <>,
        "" <>,
        "Roi Dayan" <>,
        Saeed Mahameed <>,
        Jiri Pirko <>
Subject: RE: [PATCH net-next 2/3] devlink: Consider other controller while
 building phys_port_name

> From: Parav Pandit <>
> Sent: Wednesday, September 2, 2020 9:49 PM
> Hi Jakub,
> > From: Jakub Kicinski <>
> > Sent: Wednesday, September 2, 2020 8:54 PM
> >
> > On Wed, 2 Sep 2020 10:00:11 +0200 Jiri Pirko wrote:
> > >>> I didn't quite get the fact that you want to not show controller
> > >>> ID on the local port, initially.
> > >> Mainly to not_break current users.
> > >
> > > You don't have to take it to the name, unless "external" flag is set.
> > >
> > > But I don't really see the point of showing !external, cause such
> > > controller number would be always 0. Jakub, why do you think it is
> > > needed?
> >
> > It may seem reasonable for a smartNIC where there are only two
> > controllers, and all you really need is that external flag.
> >
With only an external flag how shall we differentiate more than one external controllers?

This is the example of on a single physical smartnic device which is serving two hosts.
Each external host has one controller (c1, c2).
Each controller consist of two PCI PFs. (marked with external = true)
Devlink instance is service the local controller too.

cnum = controller number.
external = true/false describes if its external port or local.

Below naming scheme enables one or more controllers, one or more PFs to be managed by individual devlink instance per controller or one devlink instance for all controller without any ambiguity.
Does this look good?

$ devlink port show
pci/0000:00:08.0/0: type eth netdev enp0s8f0_pf0 flavour pcipf pfnum 0 external false
pci/0000:00:08.0/1: type eth netdev enp0s8f0_c1pf0 flavour pcipf pfnum 0 cnum 1 external true

pci/0000:00:08.1/0: type eth netdev enp0s8f1_pf1 flavour pcipf pfnum 1 external false
pci/0000:00:08.1/1: type eth netdev enp0s8f1_c1pf1 flavour pcipf pfnum 1 cnum 1 external true

pci/0000:00:08.2/0: type eth netdev enp0s8f2_pf0 flavour pcipf pfnum 0 external false
pci/0000:00:08.2/1: type eth netdev enp0s8f2_c2pf0 flavour pcipf pfnum 0 cnum 2 external true

pci/0000:00:08.3/0: type eth netdev enp0s8f3_pf1 flavour pcipf pfnum 1 external false
pci/0000:00:08.3/1: type eth netdev enp0s8f3_c2pf1 flavour pcipf pfnum 1 cnum 2 external true

> > In a general case when users are trying to figure out the topology not
> > knowing which controller they are sitting at looks like a serious limitation.
> >
> > Example - multi-host system and you want to know which controller you
> > are to run power cycle from the BMC side.
> >
Did you mean a controller inside the host itself (not in smrtnic) needs to know what is its controller identifier?

> > We won't be able to change that because it'd change the names for you.
> Is BMC controller running devlink instance?
> How the power outlet and devlink instance are connected?
> Can you please provide the example to understand the relation?

Powered by blists - more mailing lists