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: <AM0PR05MB48667057857062CB24DD57D2D17B0@AM0PR05MB4866.eurprd05.prod.outlook.com>
Date:   Fri, 8 Nov 2019 18:23:44 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>
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



> -----Original Message-----
> From: Jiri Pirko <jiri@...nulli.us>

[..]
> Well, I don't really need those in the phys_port_name, mainly simply because
> they would not fit. However, I believe that you should fillup the PF/VF devlink
> netlink attrs.
> 
> Note that we are not talking here about the actual mdev, but rather
> devlink_port associated with this mdev. And devlink port should have this info.
> 
> 
> >
> >> >What in hypothetical case, mdev is not on top of PCI...
> >>
> >> Okay, let's go hypothetical. In that case, it is going to be on top
> >> of something else, wouldn't it?
> >Yes, it will be. But just because it is on top of something, doesn't mean we
> include the whole parent dev, its bridge, its rc hierarchy here.
> >There should be a need.
> >It was needed in PF/VF case due to overlapping numbers of VFs via single
> devlink instance. You probably missed my reply to Jakub.
> 
> Sure. Again, I don't really care about having that in phys_port_name.
> But please fillup the attrs.
> 
Ah ok. but than that would be optional attribute?
Because you can have non pci based mdev, though it doesn't exist today along with devlink to my knowledge.