mbox series

[RFC,00/10] net: hns3: Adds support of debugfs to HNS3 driver

Message ID 20181109220743.10264-1-salil.mehta@huawei.com (mailing list archive)
Headers show
Series net: hns3: Adds support of debugfs to HNS3 driver | expand

Message

Salil Mehta Nov. 9, 2018, 10:07 p.m. UTC
This patchset adds support of debugfs to the HNS3 driver. 

Support has been added to query info related to below items:
1. Queue related
2. Flow Director
3. Promisc mode
4. TC config
5. Transmit Module/Scheduler
6. Checksum
7. QoS buffer
8. QoS prio map

Note: This patch-set has been floated as an RFC as it is an
an effort to understand what type information can be fetched
from the kernel and how it can be exported to user-space in
the HNS3 driver. There are few questions revolving our minds
like,
1. Is it allowed to dump the information of register in the
   syslog using the printk or we should use debugfs
   to export information to user-space using file interface only?
2. Can we export the information from the firmware to the
   userspace using debugfs?
3. Debugfs looks more unstructured unlike sysfs. Is there any
   de-facto standard of the user-api or drivers are allowed to
   use it in any way to expose the information from kernel.
4. Last but not least, is there any good driver reference
   within kernel which can be used as a reference. We could
   see Intel IXGBE/i40e/mellanox drivers having debugfs
   interface but with some discussions it looked they have
   some of the *might be* objectionable implementations.
5. With the idea started from Greg KH original patch
   Link: https://lwn.net/Articles/115282/
   Is the heart-and-soul of debugfs i.e. the reason why it was
   created still the same?

It would be a great help if people can help in throwing light
and reviewing this patch-set.

Thanks!


liuzhongzhu (10):
  net: hns3: Add debugfs framework registration
  net: hns3: Add "queue info" query function
  net: hns3: Add "FD flow table" info query function
  net: hns3: Add "promisc mode" config info query function
  net: hns3: Add "tc config" info query function
  net: hns3: Add "tm config" info query function
  net: hns3: Add checksum info query function
  net: hns3: Add PFC config info query function
  net: hns3: Add "qos prio map" info query function
  net: hns3: Add "qos buffer" config info query function

 drivers/net/ethernet/hisilicon/hns3/Makefile       |   2 +-
 drivers/net/ethernet/hisilicon/hns3/hnae3.h        |   2 +
 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 264 +++++++++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c    |  17 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h    |   4 +
 .../net/ethernet/hisilicon/hns3/hns3pf/Makefile    |   2 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |   4 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 589 +++++++++++++++++++++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h |  24 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c    |   1 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h    |   1 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h  |   6 +
 12 files changed, 912 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
 create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.h

Comments

Andrew Lunn Nov. 9, 2018, 10:43 p.m. UTC | #1
> 3. Debugfs looks more unstructured unlike sysfs. Is there any
>    de-facto standard of the user-api or drivers are allowed to
>    use it in any way to expose the information from kernel.

Hi Salil

You don't really have a user api using debugfs, because debugfs is
unstable. Anything can change at any time. Any user tools which use
debugfs can be expected to break at any time as the information in
debugfs changes. debugfs is for debug, not to export an API. And in
production systems, it is often not mounted.

As much as possible, you are recommended to use existing APIs,
ethtool, devlink, etc.

	Andrew
Salil Mehta Nov. 11, 2018, 3:12 p.m. UTC | #2
Hi Andrew,
Thanks for replying. Sorry, for not being prompt as I was
traveling.

Please find some further follow-up questions below

Salil.

> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
> owner@vger.kernel.org] On Behalf Of Andrew Lunn
> Sent: Friday, November 9, 2018 10:44 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; yuvalm@mellanox.com; leon@kernel.org;
> Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil@opnsrc.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-rdma@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>
> Subject: Re: [RFC PATCH 00/10] net: hns3: Adds support of debugfs to
> HNS3 driver
> 
> > 3. Debugfs looks more unstructured unlike sysfs. Is there any
> >    de-facto standard of the user-api or drivers are allowed to
> >    use it in any way to expose the information from kernel.
> 
> Hi Salil
> 
> You don't really have a user api using debugfs, because debugfs is
> unstable. Anything can change at any time. Any user tools which use
> debugfs can be expected to break at any time as the information in
> debugfs changes. debugfs is for debug, not to export an API. And in
> production systems, it is often not mounted.


Sure, I understand. 

> 
> As much as possible, you are recommended to use existing APIs,
> ethtool, devlink, etc.


Agreed. But what about if we want to expose anything related to
firmware to user-space using the debugfs, assuming we are presenting
information in structured way and not as a black-box to some user-space
application. Is it something which might be discouraged?

Many Thanks
Andrew Lunn Nov. 11, 2018, 4:18 p.m. UTC | #3
> Agreed. But what about if we want to expose anything related to
> firmware to user-space using the debugfs, assuming we are presenting
> information in structured way and not as a black-box to some user-space
> application. Is it something which might be discouraged?

Hi Salil

Please take a look at devlink. Mellonex have been adding commands to
it for dumping firmware states.

   Andrew
Salil Mehta Nov. 11, 2018, 4:47 p.m. UTC | #4
Hi Andrew,

> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Sunday, November 11, 2018 4:18 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; yuvalm@mellanox.com; leon@kernel.org;
> Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; lipeng (Y)
> <lipeng321@huawei.com>; mehta.salil@opnsrc.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-rdma@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>
> Subject: Re: [RFC PATCH 00/10] net: hns3: Adds support of debugfs to
> HNS3 driver
> 
> > Agreed. But what about if we want to expose anything related to
> > firmware to user-space using the debugfs, assuming we are presenting
> > information in structured way and not as a black-box to some user-
> space
> > application. Is it something which might be discouraged?
> 
> Hi Salil
> 
> Please take a look at devlink. Mellonex have been adding commands to
> it for dumping firmware states.

sure, thanks for the info. Ill check.

Salil.