netdev - Re: [PATCH net-next 0/8] bnxt_en: devlink param updates

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: <20180912115026.6c05ab5e@cakuba>
Date:   Wed, 12 Sep 2018 11:50:26 +0200
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Vasundhara Volam <vasundhara-v.volam@...adcom.com>
Cc:     David Miller <davem@...emloft.net>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        Netdev <netdev@...r.kernel.org>, alexander.duyck@...il.com
Subject: Re: [PATCH net-next 0/8] bnxt_en: devlink param updates

On Wed, 12 Sep 2018 12:09:37 +0530, Vasundhara Volam wrote:
> On Tue, Sep 11, 2018 at 5:04 PM Jakub Kicinski wrote:
> > On Tue, 11 Sep 2018 14:14:57 +0530, Vasundhara Volam wrote:  
> > > This patchset adds support for 4 generic and 1 driver-specific devlink
> > > parameters.
> > >
> > > Also, this patchset adds support to return proper error code if
> > > HWRM_NVM_GET/SET_VARIABLE commands return error code
> > > HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
> > >
> > > Vasundhara Volam (8):
> > >   devlink: Add generic parameter hw_tc_offload  
> >
> > Much like Jiri, I can't help but wonder why do you need this?  
>
> There is a request from our customer for a way to toggle tc_offload
> feature in our adapter.

Vasundhara, again, we don't need to know who asked you to do this, but
_why_.  What problem are you solving?  What is the customer trying to
achieve?

> > >   devlink: Add generic parameter ignore_ari
> > >   devlink: Add generic parameter msix_vec_per_pf_max
> > >   devlink: Add generic parameter msix_vec_per_pf_min  
> >
> > IMHO more structured API would be preferable if possible.  The string
> > keys won't scale if you want to set the parameters per PF, and
> > creating more structured API for PCIe which is a relatively slow
> > moving HW spec seems tractable.  
>
> Sorry, could you please suggest an example? We will try to adapt.

My thinking was that the same way devlink device has ports, it should
have PCIe functions as objects which then have attributes.  Instead of
making everything a string-identified device attribute.  But I'm not
dead set on this if others don't think its a good idea.