netdev - Re: [PATCH net-next 0/9] devlink vdev

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: <20191023195141.48775df1@cakuba.hsd1.ca.comcast.net>
Date:   Wed, 23 Oct 2019 19:51:41 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Yuval Avnery <yuvalav@...lanox.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "leon@...nel.org" <leon@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "shuah@...nel.org" <shuah@...nel.org>,
        Daniel Jurgens <danielj@...lanox.com>,
        andrew.gospodarek@...adcom.com,
        Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH net-next 0/9] devlink vdev

On Thu, 24 Oct 2019 00:11:48 +0000, Yuval Avnery wrote:
> >>> We need some proper ontology and decisions what goes where. We have
> >>> half of port attributes duplicated here, and hw_addr which honestly
> >>> makes more sense in a port (since port is more of a networking
> >>> construct, why would ep storage have a hw_addr?). Then you say you're
> >>> going to dump more PCI stuff in here :(  
> >> Well basically what this "vdev" is is the "port peer" we discussed
> >> couple of months ago. It provides possibility for the user on bare metal
> >> to cofigure things for the VF - for example.
> >>
> >> Regarding hw_addr vs. port - it is not correct to make that a devlink
> >> port attribute. It is not port's hw_addr, but the port's peer hw_addr.  
> > Yeah, I remember us arguing with others that "the other side of the
> > wire" should not be a port.
> >  
> >>> "vdev" sounds entirely meaningless, and has a high chance of becoming
> >>> a dumping ground for attributes.  
> >> Sure, it is a madeup name. If you have a better name, please share.  
> > IDK. I think I started the "peer" stuff, so it made sense to me.
> > Now it sounds like you'd like to kill a lot of problems with this
> > one stone. For PCIe "vdev" is def wrong because some of the config
> > will be for PF (which is not virtual). Also for PCIe the config has
> > to be done with permanence in mind from day 1, PCI often requires
> > HW reset to reconfig.
>
> The PF is "virtual" from the SmartNic embedded CPU point of view.

We also want to configure PCIe on local host thru this in non-SmartNIC
case, having the virtual in the name would be confusing there.

> Maybe gdev is better? (generic)

Let's focus on the scope and semantics of the object we are modelling
first. Can we talk goals, requirements, user scenarios etc.?

IMHO the hw_addr use case is kind of weak, clouds usually do tunnelling
so nobody cares which MAC customer has assigned in the overlay.

CCing Andy and Michael from Broadcom for their perspective and
requirements.

> >> Basically it is something that represents VF/mdev - the other side of
> >> devlink port. But in some cases, like NVMe, there is no associated
> >> devlink port - that is why "devlink port peer" would not work here.  
> > What are the NVMe parameters we'd configure here? Queues etc. or some
> > IDs? Presumably there will be a NVMe-specific way to configure things?
> > Something has to point the NVMe VF to a backend, right?
> >
> > (I haven't looked much into NVMe myself in case that's not obvious ;))