[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0501MB227146735C5C858D42A2C931D1710@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date: Mon, 4 Mar 2019 04:59:04 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jiri Pirko <jiri@...nulli.us>,
Jakub Kicinski <jakub.kicinski@...ronome.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 2/8] devlink: add PF and VF port flavours
> -----Original Message-----
> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
> Behalf Of Jiri Pirko
> Sent: Wednesday, February 27, 2019 6:17 AM
> To: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Cc: davem@...emloft.net; oss-drivers@...ronome.com;
> netdev@...r.kernel.org
> Subject: Re: [PATCH net-next 2/8] devlink: add PF and VF port flavours
>
> Tue, Feb 26, 2019 at 07:24:30PM CET, jakub.kicinski@...ronome.com wrote:
> >Current port flavours cover simple switches and DSA. Add PF and VF
> >flavours to cover "switchdev" SR-IOV NICs.
> >
> >Example devlink user space output:
> >
> >$ devlink port
> >pci/0000:82:00.0/0: type eth netdev p4p1 flavour physical
> >pci/0000:82:00.0/10000: type eth netdev eth0 flavour pcie_pf pf 0
> >pci/0000:82:00.0/10001: type eth netdev eth1 flavour pcie_vf pf 0 vf 0
> >pci/0000:82:00.0/10002: type eth netdev eth2 flavour pcie_vf pf 0 vf 1
>
A given port is of its parent device.
In current scenario, its PF or VF.
Hence it should be device attribute and not a port attribute.
So devlink dev show command have to show what device flavour is.
Is it well known PCI VF or PF or something else.
It will show subdev device attribute and its parent PCI (PF/VF) devlink device.
So we should have device flovour as PCI_PF or PCI_VF or SUBDEV.
Again VF number showcasing here is very restrictive model.
Every PF/VF/Subdev represents its own 'port' and it is connected to eswitch 'port'.
Instead of showing VF here, it must be this 'port' or 'link' number that gives right view.
Which netdev represents which VF is already linked in the VF rep-netdev sysfs property.
So flavour should be something like 'hostport' and when port is registered for the eswitch side it should be 'switchport'.
With this there is very clear picture of which hostport is connected to which eswitch port.
Just like how we see in the physical world.
Powered by blists - more mailing lists