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: <AM0PR05MB4866BEC2A2B586AA72BAA9ABD17B0@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date:   Fri, 8 Nov 2019 01:44:53 +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: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Sent: Thursday, November 7, 2019 7:18 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 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.
>
I didn't follow your comment. For devlink port show command output you said,

"Surely those devices are anchored in on of the PF (or possibly VFs) that should be exposed here from the start."
 
So I was trying to explain why we don't expose PF/VF detail in the port attributes which contains 
(a) flavour
(b) netdev representor (name derived from phys_port_name)
(c) mdev alias

Can you please describe which netlink attribute I missed?

> > > > 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?
>
I initially had 'm' as prefix to make it easy to recognize as mdev's port, instead of 'p', but during internal review Jiri's input was to just use 'p'.
 
> 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.
> 
Well, many orchestration framework probably won't care of what name is picked up.
And such name will likely get renamed to eth0 in VM or container.
Unlike vxlan, macvlan interfaces, user explicitly specify the netdevice name, and when newlink() netlink command completes with success, user know the device to use.
If we don't have persistent name for mdev, if a random name ethX is picked up, user needs refer to sysfs device hierarchy to know its netdev.
Its super easy to do refer that, but having persistent name based out of alias makes things aligned like naming device on PCI bus.
This way devices can be used without VM/container use cases too, for example user is interested in only 4 or 8 mdev devices in system and its setup is done through systemd.service.



> > > > +		break;
> > > >  	}
> > > >
> > > >  	if (n >= len)