> On Thu, Oct 19, 2017 at 2:07 AM, Yuval Mintz <yuv...@mellanox.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
