On Thu, 7 Nov 2019 21:03:09 +0000, Parav Pandit wrote: > > 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. I'm talking about netlink attributes. I'm not suggesting to sprintf it all into the phys_port_name. > > > Signed-off-by: Parav Pandit <parav@xxxxxxxxxxxx> > > > > > @@ -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. So we're reusing the letter that normal ports use? Why does it matter to name the virtualized device? In case of other reprs its the repr that has the canonical name, in case of containers and VMs they will not care at all what hypervisor identifier the device has. > > > + break; > > > } > > > > > > if (n >= len)
