mbox series

[net-next,0/2] devlink enhancements

Message ID 20210802042740.10355-1-kalesh-anakkur.purayil@broadcom.com (mailing list archive)
Headers show
Series devlink enhancements | expand

Message

Kalesh Anakkur Purayil Aug. 2, 2021, 4:27 a.m. UTC
From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>

This patchset adds device capability reporting to devlink info API.
It may be useful if we expose the device capabilities to the user
through devlink info API.

Kalesh AP (2):
  devlink: add device capability reporting to devlink info API
  bnxt_en: Add device capabilities to devlink info_get cb

 Documentation/networking/devlink/devlink-info.rst |  3 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 31 +++++++++++++++++++++--
 include/net/devlink.h                             |  2 ++
 include/uapi/linux/devlink.h                      |  3 +++
 net/core/devlink.c                                | 25 ++++++++++++++++++
 5 files changed, 62 insertions(+), 2 deletions(-)

Comments

Jakub Kicinski Aug. 2, 2021, 4:36 p.m. UTC | #1
On Mon,  2 Aug 2021 09:57:38 +0530 Kalesh A P wrote:
> From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
> 
> This patchset adds device capability reporting to devlink info API.
> It may be useful if we expose the device capabilities to the user
> through devlink info API.

Did you see the RFC Jake posted? That's way more palatable.

Operationally the API provided here is of little to no value 
to the user, and since it extends the "let the vendors dump custom
meaningless strings" paradigm present in devlink please expect 
major push back.
Jacob Keller Aug. 2, 2021, 7:41 p.m. UTC | #2
On 8/2/2021 9:36 AM, Jakub Kicinski wrote:
> On Mon,  2 Aug 2021 09:57:38 +0530 Kalesh A P wrote:
>> From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
>>
>> This patchset adds device capability reporting to devlink info API.
>> It may be useful if we expose the device capabilities to the user
>> through devlink info API.
> 
> Did you see the RFC Jake posted? That's way more palatable.
> 

FWIW, my patch is more in regards to making sure that users, tools, or
scripts, have a way to tell if a given devlink interface is supported.

This seems like a way to indicate specific device features?

> Operationally the API provided here is of little to no value 
> to the user, and since it extends the "let the vendors dump custom
> meaningless strings" paradigm present in devlink please expect 
> major push back.
> 

Right. the better approach here is to ensure that whatever user-facing
impact of these features is exposed through a standard interface. If one
doesn't exist for the capability, you will need to do work to create
such an interface.

If there's no user impact (and thus no need for a separate interface),
then why does a user need to know the capability?

Thanks,
Jake