From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net-next 0/8] bnxt_en: devlink param updates Date: Wed, 12 Sep 2018 11:50:26 +0200 Message-ID: <20180912115026.6c05ab5e@cakuba> References: <1536655505-14387-1-git-send-email-vasundhara-v.volam@broadcom.com> <20180911133215.5798ed2a@cakuba> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Miller , "michael.chan@broadcom.com" , Netdev , alexander.duyck@gmail.com To: Vasundhara Volam Return-path: Received: from mail-ed1-f68.google.com ([209.85.208.68]:40700 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726082AbeILOyW (ORCPT ); Wed, 12 Sep 2018 10:54:22 -0400 Received: by mail-ed1-f68.google.com with SMTP id j62-v6so1242930edd.7 for ; Wed, 12 Sep 2018 02:50:36 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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.