From: David Miller <davem@davemloft.net>
To: Yuval.Mintz@cavium.com
Cc: gerlitz.or@gmail.com, jeffrey.t.kirsher@intel.com,
mitch.a.williams@intel.com, netdev@vger.kernel.org,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com
Subject: Re: [net-next 04/14] i40e: dump VF information in debugfs
Date: Thu, 20 Apr 2017 11:20:21 -0400 (EDT) [thread overview]
Message-ID: <20170420.112021.167483274923043370.davem@davemloft.net> (raw)
In-Reply-To: <BL2PR07MB23064C036E994DC63475F7388D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Thu, 20 Apr 2017 10:09:28 +0000
>> > Dump some internal state about VFs through debugfs. This provides
>> > information not available with 'ip link show'.
>>
>> such as?
>>
>> donnwantobethedebugfspolice, but still, in the 2-3 times we tried to push
>> debugfs to MLNX NIC drivers, Dave disallowed that, and lately the switch
>> team even went further and deleted that portion of the mlxsw driver -- all to
>> all, I don't see much point for these type of changes, thoughts?
>
> Don't want to hikjack your thread, but continuing this topic -
> Is there some flat-out disapproval for debugfs in net-next now?
>
> We're currently internally engaged with adding qed support for register dumps
> [~equivalents for `ethtool -d' outputs] through debugfs, on behalf of storage
> drivers [qedi/qedf] lacking the API for doing that.
I really hate to see debugfs things in networking drivers. It's a
complete cop out for doing things properly.
I push back, but I can only fight too much. If people want to keep
adding stupid poorly designed crap endlessly to their drivers there
is only so much I can do...
next prev parent reply other threads:[~2017-04-20 15:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 1:57 [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2017-04-19 Jeff Kirsher
2017-04-20 1:57 ` [net-next 01/14] i40evf: Use net_device_stats from struct net_device Jeff Kirsher
2017-04-20 1:57 ` [net-next 02/14] i40e/i40evf: Remove VF Rx csum offload for tunneled packets Jeff Kirsher
2017-04-20 1:57 ` [net-next 03/14] i40e: Fix support for flow director programming status Jeff Kirsher
2017-04-20 1:57 ` [net-next 04/14] i40e: dump VF information in debugfs Jeff Kirsher
2017-04-20 6:16 ` Or Gerlitz
2017-04-20 10:09 ` Mintz, Yuval
2017-04-20 11:39 ` Jiri Pirko
2017-04-20 13:57 ` Mintz, Yuval
2017-04-20 15:51 ` David Miller
2017-04-20 16:24 ` Mintz, Yuval
2017-04-20 16:58 ` David Miller
2017-04-20 20:12 ` Mintz, Yuval
2017-04-20 20:35 ` David Miller
2017-04-20 20:50 ` Mintz, Yuval
2017-04-20 20:54 ` David Miller
2017-04-21 8:11 ` Or Gerlitz
2017-04-20 15:20 ` David Miller [this message]
2017-04-20 22:25 ` Williams, Mitch A
2017-04-21 18:12 ` David Miller
2017-04-20 1:57 ` [net-next 05/14] i40e/i40evf: Add tracepoints Jeff Kirsher
2017-04-20 1:57 ` [net-next 06/14] i40e: new AQ commands Jeff Kirsher
2017-04-20 1:57 ` [net-next 07/14] i40e: don't hold RTNL lock while waiting for VF reset to finish Jeff Kirsher
2017-04-20 1:57 ` [net-next 08/14] i40e: factor out queue control from i40e_vsi_control_(tx|rx) Jeff Kirsher
2017-04-20 1:57 ` [net-next 09/14] i40e: fix CONFIG_BUSY checks in i40e_set_settings function Jeff Kirsher
2017-04-20 1:57 ` [net-next 10/14] i40e: reduce wait time for adminq command completion Jeff Kirsher
2017-04-20 1:57 ` [net-next 11/14] i40e: remove I40E_FLAG_IN_NETPOLL entirely Jeff Kirsher
2017-04-20 1:57 ` [net-next 12/14] i40e: split some code in i40e_reset_vf into helpers Jeff Kirsher
2017-04-20 1:57 ` [net-next 13/14] i40e: reset all VFs in parallel when rebuilding PF Jeff Kirsher
2017-04-20 1:57 ` [net-next 14/14] i40e: use i40e_stop_rings_no_wait to implement PORT_SUSPENDED state Jeff Kirsher
2017-04-21 18:13 ` [net-next 00/14][pull request] 40GbE Intel Wired LAN Driver Updates 2017-04-19 David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170420.112021.167483274923043370.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=Yuval.Mintz@cavium.com \
--cc=gerlitz.or@gmail.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jogreene@redhat.com \
--cc=mitch.a.williams@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).