netdev - RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports

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: <VI1PR0501MB227119525408A9474AA4937ED1470@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date:   Mon, 18 Mar 2019 20:35:02 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     Jiri Pirko <jiri@...nulli.us>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
 ports



> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Sent: Monday, March 18, 2019 3:00 PM
> To: Parav Pandit <parav@...lanox.com>
> Cc: Jiri Pirko <jiri@...nulli.us>; Samudrala, Sridhar
> <sridhar.samudrala@...el.com>; davem@...emloft.net;
> netdev@...r.kernel.org; oss-drivers@...ronome.com
> Subject: RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
> ports
> 
> On Mon, 18 Mar 2019 19:44:21 +0000, Parav Pandit wrote:
> > > -----Original Message-----
> > > From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> > > Sent: Monday, March 18, 2019 2:37 PM
> > > To: Parav Pandit <parav@...lanox.com>
> > > Cc: Jiri Pirko <jiri@...nulli.us>; Samudrala, Sridhar
> > > <sridhar.samudrala@...el.com>; davem@...emloft.net;
> > > netdev@...r.kernel.org; oss-drivers@...ronome.com
> > > Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on
> > > devlink PCI ports
> > >
> > > On Mon, 18 Mar 2019 16:22:33 +0000, Parav Pandit wrote:
> > > >>>>>>2. flavour should not be vf/pf, flavour should be hostport,
> switchport.
> > > >>>  >Because switch is flat and agnostic of pf/vf/mdev.
> > > >>>>>
> > > >>>>> Not sure. It's good to have this kind of visibility.
> > > >>>>>
> > > >>>> port can have label/attribute indicating that this belong to
> > > >>>> VF-1 or mdev as long as you are agreeing to have mdev attribute on
> host port.
> > > >>>> (and not ask for abstracting it, because mdev is well defined kernel
> object).
> > > >>>
> > > >>> Why mdev cannot be another flavour?
> > > >>>
> > > >>
> > > >> hostport is of type pf/vf/mdev connected to some switchport.
> > > >>
> > > >> So proposal is to have,
> > > >> port flavour = hostport/switchport port type/label = pf/vf/mdev
> > > >>
> > > > Instead of having two attributes per port, how about having, port
> > > > flavour= physical/cpu/dsa/pf/vf/mdev/switchport.
> > > >
> > > > physical and pf has some overlapping definitions.
> > >
> > > What "overlapping definitions" do physical and PF have?
> > PF has physically user facing port.
> 
> PF doesn't "have a user facing port" in switchdev mode.  
Physical port described in include/uapi/linux/devlink.h as DEVLINK_PORT_FLAVOUR_PHYSICAL is not related to switchdev or legacy mode.
As the comment block describe it is 'any kind of port physical facing user'.
Current mlx5 driver doesn't expose ports as physical regardless of switchdev/legacy mode.

> It's a limitation of Mellanox HW that you have some strong association there.
>
Not sure why you keep saying that. Any code reference that I should look at?
Or maybe you can explain what is that limitation, because I am not aware of any.

> > And physical port in include/uapi/linux/devlink.h also describe that.
> 
> By "that" you must mean that the physical is a user facing port.

Can you please describe the difference between 'PF port' and 'physical port of include/uapi/linux/devlink.h'?
I must have missed this crisp definition in discussion between you and Jiri.
I am in meantime checking the thread.