netdev - Re: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for configuration attributes.

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: <20190703104244.7d26e734@cakuba.netronome.com>
Date:   Wed, 3 Jul 2019 10:42:44 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Sudarsana Reddy Kalluru <skalluru@...vell.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Michal Kalderon <mkalderon@...vell.com>,
        "Ariel Elior" <aelior@...vell.com>
Subject: Re: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for
 configuration attributes.

On Wed, 3 Jul 2019 12:56:39 +0000, Sudarsana Reddy Kalluru wrote:
> Apologies for bringing this topic again. From the driver(s) code
> paths/'devlink man pages', I understood that devlink-port object is
> an entity on top of the PCI bus device. Some drivers say NFP
> represents vnics (on pci-dev) as a devlink-ports and, some represents
> (virtual?) ports on the PF/device as devlink-ports. In the case of
> Marvell NIC driver, we don't have [port] partitioning of the PCI
> device. And the config attributes are specific to PCI-device (not the
> vports/vnics of PF). Hence I didn't see a need for creating
> devlink-port objects in the system for Marvell NICs. And planning to
> add the config attributes to 'devlink-dev' object. Please let me know
> if my understanding and the proposal is ok?

I understand where you're coming from.  

We want to make that judgement call on attribute-by-attribute basis.  
We want consistency across vendors (and, frankly, multiple drivers of
the same vendor).  If attribute looks like it belongs to the port,
rather than the entire device/ASIC operation, we should make it a port
attribute.