From: Ben Greear <greearb@candelatech•com>
To: David Miller <davem@davemloft•net>
Cc: jeffrey.t.kirsher@intel•com, donald.c.skidmore@intel•com,
netdev@vger•kernel.org, gospo@redhat•com, sassmann@redhat•com,
bhutchings@solarflare•com
Subject: Re: [net-next v2 6/8] ixgbe: add syfs interface for to export read only driver information
Date: Tue, 01 May 2012 07:30:55 -0700 [thread overview]
Message-ID: <4F9FF39F.7080205@candelatech.com> (raw)
In-Reply-To: <20120501.100241.1409452912879198250.davem@davemloft.net>
On 05/01/2012 07:02 AM, David Miller wrote:
> From: Jeff Kirsher<jeffrey.t.kirsher@intel•com>
> Date: Tue, 1 May 2012 01:51:07 -0700
>
>> From: Don Skidmore<donald.c.skidmore@intel•com>
>>
>> This patch exports non-thermal (which was done via hwmon in an earlier
>> patch) data to sysfs which isn't readily available elsewhere. All of the
>> fields are read only as this interface is to only export driver data.
>>
>> Signed-off-by: Don Skidmore<donald.c.skidmore@intel•com>
>> Tested-by: Stephen Ko<stephen.s.ko@intel•com>
>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel•com>
>
> I don't like it.
>
> Some of this stuff is generic and belongs somewhere like ethtool, for
> example the descriptor sizes and queue sizes.
>
> The others are reading registers, and we have an ethtool API for that
> already.
>
> But putting anything like this in sysfs is pointless, because the
> stuff that other cards have too will then go into differently named
> sysfs files which, as is oft repeated here, is a terrible user
> experience.
>
> If you want to do this right, add a new ethtool interface that allows
> the publication of card specific unchanging values, in a style like
> what we already do for statistics. Have one query that gets the
> string list, and then another which fetches the actual values.
And if you decide to go forward with this, I have some ideas for API
and would like to discuss it. Or, if I beat you to it, I'll post some
RFC patches when I get a chance to write them up.
Basically, I'm thinking of a get-strings(flags), get-types(flags), and get-values(flags)
API. The types would return an array of enums that would define the data
type, like uint32, int8, etc. Strings would be same as it is today,
just with a new type. Values would return array of uint64 as it does now.
To each method you could specify a uint32 flags that would be device specific.
I would like to use flags in wifi to specify whether to get the underlying NIC
stats v/s just the soft-device stats, for instance. And maybe some additional
granularity if some stats are more costly to get than others so that one could
probe expensive stats more rarely....
And while strings would still be free-form, we could at least attempt to use
the same strings for the same kinds of stats where possible.
Thanks,
Ben
--
Ben Greear <greearb@candelatech•com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2012-05-01 14:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 8:51 [net-next 0/8][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2012-05-01 8:51 ` [net-next 1/8] e1000e: workaround EEPROM configuration change on 82579 Jeff Kirsher
2012-05-01 8:51 ` [net-next 2/8] e1000e: PHY initialization flow changes for 82577/8/9 Jeff Kirsher
2012-05-01 8:51 ` [net-next 3/8] e1000e: fix .ndo_set_rx_mode for 82579 Jeff Kirsher
2012-05-01 8:51 ` [net-next v2 4/8] ixgbe: add support functions to access thermal data Jeff Kirsher
2012-05-01 8:51 ` [net-next v2 5/8] ixgbe: add hwmon interface to export " Jeff Kirsher
2012-05-01 8:51 ` [net-next v2 6/8] ixgbe: add syfs interface for to export read only driver information Jeff Kirsher
2012-05-01 14:02 ` David Miller
2012-05-01 14:30 ` Ben Greear [this message]
2012-05-02 8:41 ` Jeff Kirsher
2012-05-02 8:51 ` David Miller
2012-05-01 8:51 ` [net-next 7/8] ixgbe: Deny MACVLAN requests from VFs with admin set MAC Jeff Kirsher
2012-05-01 8:51 ` [net-next 8/8] ixgbe: Reset max_vfs to zero when user request is out of range Jeff Kirsher
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=4F9FF39F.7080205@candelatech.com \
--to=greearb@candelatech$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=donald.c.skidmore@intel$(echo .)com \
--cc=gospo@redhat$(echo .)com \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sassmann@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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