[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR05MB4866963BE7BA1EE0831C9624D1780@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date: Thu, 7 Nov 2019 21:03:09 +0000
From: Parav Pandit <parav@...lanox.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
CC: "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Saeed Mahameed <saeedm@...lanox.com>,
"kwankhede@...dia.com" <kwankhede@...dia.com>,
"leon@...nel.org" <leon@...nel.org>,
"cohuck@...hat.com" <cohuck@...hat.com>,
Jiri Pirko <jiri@...lanox.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
Subject: RE: [PATCH net-next 12/19] devlink: Introduce mdev port flavour
> -----Original Message-----
> From: kvm-owner@...r.kernel.org <kvm-owner@...r.kernel.org> On Behalf
> Of Jakub Kicinski
> Sent: Thursday, November 7, 2019 2:39 PM
> To: Parav Pandit <parav@...lanox.com>
> Cc: alex.williamson@...hat.com; davem@...emloft.net;
> kvm@...r.kernel.org; netdev@...r.kernel.org; Saeed Mahameed
> <saeedm@...lanox.com>; kwankhede@...dia.com; leon@...nel.org;
> cohuck@...hat.com; Jiri Pirko <jiri@...lanox.com>; linux-
> rdma@...r.kernel.org
> Subject: Re: [PATCH net-next 12/19] devlink: Introduce mdev port flavour
>
> On Thu, 7 Nov 2019 10:08:27 -0600, Parav Pandit wrote:
> > Introduce a new mdev port flavour for mdev devices.
> > PF.
> > Prepare such port's phys_port_name using unique mdev alias.
> >
> > An example output for eswitch ports with one physical port and one
> > mdev port:
> >
> > $ devlink port show
> > pci/0000:06:00.0/65535: type eth netdev p0 flavour physical port 0
> > pci/0000:06:00.0/32768: type eth netdev p1b0348cf880a flavour mdev
> > alias 1b0348cf880a
>
> Surely those devices are anchored in on of the PF (or possibly VFs) that should
> be exposed here from the start.
>
They are anchored to PCI device in this implementation and all mdev device has their parent device too.
However mdev devices establishes their unique identity at system level using unique UUID.
So prefixing it with pf0, will shorten the remaining phys_port_name letter we get to use.
Since we get unique 12 letters alias in a system for each mdev, prefixing it with pf/vf is redundant.
In case of VFs, given the VF numbers can repeat among multiple PFs, and representor can be over just one eswitch instance, it was necessary to prefix.
Mdev's devices parent PCI device is clearly seen in the PCI sysfs hierarchy, so don't prefer to duplicate it.
> > Signed-off-by: Parav Pandit <parav@...lanox.com>
>
> > @@ -6649,6 +6678,9 @@ static int
> __devlink_port_phys_port_name_get(struct devlink_port *devlink_port,
> > n = snprintf(name, len, "pf%uvf%u",
> > attrs->pci_vf.pf, attrs->pci_vf.vf);
> > break;
> > + case DEVLINK_PORT_FLAVOUR_MDEV:
> > + n = snprintf(name, len, "p%s", attrs->mdev.mdev_alias);
>
> Didn't you say m$alias in the cover letter? Not p$alias?
>
In cover letter I described the naming scheme for the netdevice of the mdev device (not the representor).
Representor follows current unique phys_port_name method.
> > + break;
> > }
> >
> > if (n >= len)
Powered by blists - more mailing lists