netdev - RE: [PATCH 4/7] devlink: Adding perm config of link settings

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] [day] [month] [year] [list]

Date:   Thu, 19 Oct 2017 18:34:47 +0000
From:   Yuval Mintz <yuvalm@...lanox.com>
To:     Steve Lin <steven.lin1@...adcom.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "linville@...driver.com" <linville@...driver.com>,
        "gospo@...adcom.com" <gospo@...adcom.com>
Subject: RE: [PATCH 4/7] devlink: Adding perm config of link settings

> On Thu, Oct 19, 2017 at 2:07 AM, Yuval Mintz <yuvalm@...lanox.com>
> wrote:
> >> +enum devlink_autoneg_protocol {
> >> +     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_BAM,
> >> +     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY_CONSORTIUM,
> >> +     DEVLINK_AUTONEG_PROTOCOL_IEEE8023BY,
> >> +     DEVLINK_AUTONEG_PROTOCOL_BAM,           /* Broadcom
> >> Autoneg Mode */
> >> +     DEVLINK_AUTONEG_PROTOCOL_CONSORTIUM,    /*
> >> Consortium Autoneg Mode */
> >> +};
> >
> > Wouldn't adding BAM as a 'generic' mode of operation be like adding
> > non-consortium speeds to ethtool API?
> > [I profess ignorance in this area; For all I know it can be a widely accepted
> > industry standard]
> >
> 
> Yuval, I'm glad to get input from other NIC vendors.  
Other switch vendors ;)

>The high-level goal of this effort is to allow users of various vendors' NICs to be
> able to configure these types of NVRAM/permanent/default settings
> using an inbox tool, rather than the collection of vendor-specific
> tools that is the status quo.
> 
> In order to provide that functionality, it seems like the
> vendor-specific parameters and also the vendor-specific settings of
> common parameters both need to be supported in this manner.
> 
> Ideally there will be much overlap in both the set of parameters
> available as well as the options for each parameter, but in the real
> world, there will always be differences between vendors and even
> between different devices (drivers) from the same vendor.  Despite
> that reality, I think there is still great benefit in having a common
> inbox tool that users can use for device configuration of this type.
> It just means that not all drivers will support all parameters, nor
> all options for each parameter that they do support.

I don't object the end-goal; I think my hesitation is due to the same
enum containing both generic and vendor-specific values mixed
together. I feel like we need some clear distinction between the two.

> 
> Thanks,
> Steve