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

Message-ID: <CA+Jmh7H+u1-1Ot2TxLXEHk2HW=p+yeT02cexNPC1nW5V_gMVgQ@mail.gmail.com>
Date:   Thu, 19 Oct 2017 11:07:50 -0400
From:   Steve Lin <steven.lin1@...adcom.com>
To:     Yuval Mintz <yuvalm@...lanox.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.  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.

Thanks,
Steve