netdev - Re: [PATCH net-next 12/19] devlink: Introduce mdev port flavour

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191107201750.6ac54aed@cakuba>
Date:   Thu, 7 Nov 2019 20:17:50 -0500
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Parav Pandit <parav@...lanox.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

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@...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.

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)