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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20191108094646.GB6990@nanopsycho>
Date:   Fri, 8 Nov 2019 10:46:46 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Parav Pandit <parav@...lanox.com>
Cc:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "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

Fri, Nov 08, 2019 at 03:31:02AM CET, parav@...lanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
>> Sent: Thursday, November 7, 2019 8:20 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 Fri, 8 Nov 2019 01:44:53 +0000, Parav Pandit wrote:
>> > > 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?
>> 
>> Identification of the PCI device. The PCI devices are not linked to devlink
>> ports, so the sysfs hierarchy (a) is irrelevant, (b) may not be visible in multi-
>> host (or SmartNIC).
>>
>
>It's the unique mdev device alias. It is not right to attach to the PCI device.
>Mdev is bus in itself where devices are identified uniquely. So an alias suffice that identity.

Wait a sec. For mdev, what you say is correct. But here we talk about
devlink_port which is representing this mdev. And this devlink_port is
very similar to VF devlink_port. It is bound to specific PF (in case of
mdev it could be PF-VF).


>
>> > > > > > 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'.
>> 
>> Let's way for Jiri to weigh in then.
>
>Yeah.
>I remember his point was to not confuse the <en><m> prefix in the persistent device name with 'm' prefix in phys_port_name.
>Hence, his input was just 'p'.

Not sure what are you referring to. Udev places "n" in front of whatever
string we construct here, so the namespace is entirely in our hands.


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