From: Ben Greear <greearb@candelatech.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Florian Fainelli <florian@openwrt.org>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 4/5] mac80211: Add more ethtools stats: survey, rates, etc
Date: Thu, 12 Apr 2012 13:46:08 -0700 [thread overview]
Message-ID: <4F873F10.6010207@candelatech.com> (raw)
In-Reply-To: <1334259053.2497.18.camel@bwh-desktop.uk.solarflarecom.com>
On 04/12/2012 12:30 PM, Ben Hutchings wrote:
> On Thu, 2012-04-12 at 09:51 -0700, Ben Greear wrote:
>> On 04/12/2012 09:42 AM, Florian Fainelli wrote:
>>> Hi,
>>>
>>> Le 04/12/12 18:32, greearb@candelatech.com a écrit :
>>>> From: Ben Greear<greearb@candelatech.com>
>>>>
>>>> The signal and noise are forced to be positive since ethtool
>>>> deals in unsigned 64-bit values and this number should be human
>>>> readable. This gives easy access to some of the data formerly
>>>> exposed in the deprecated /proc/net/wireless file.
>>>
>>> Uh, that's misleading, the signal and noise values are typically negative, so one needs to think about mentally adding a minus sign if he/she wants to
>>> understand it. Does not ethtool know about 32-bits signed integers?
>>
>> Ethtool stats only supports u64. I think it's easy enough for
>> humans or programs to add the negative sign. Can signal or noise
>> ever be> 0? If so, that could actually break something that depends
>> on flipping the value to negative....
>
> So far as I can see, the ethtool stats were expected to be counters,
> which obviously cannot become negative (or fractional). Maybe it's time
> to define another command and string-set to cover other types of status
> information. The ethtool utility could ask for those typed statistics
> as well, so 'ethtool -S' would get all of them.
One nice thing about ethtool stats API is that it is backwards and forwards
compatible for a long while. Also, adding a new API means a second call
into the kernel (most likely) for the other set of strings, which effectively
doubles the cost of getting stats (and allows the stats to be updated
out-of-sync with each other more easily).
I wonder if instead we could add a convention where we add a short
prefix (or suffix) to a string to denote it's type (and cast the value
into u64). So, an old ethtool might see:
foo:s32: 4294967295
while a new one understand that the s32: prefix is special, do
some casting, and could show:
foo: -1
Both are still at least somewhat human readable, and probably wouldn't
confuse anyone that is parsing the output of existing ethtool output.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
To: Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
Cc: Florian Fainelli
<florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 4/5] mac80211: Add more ethtools stats: survey, rates, etc
Date: Thu, 12 Apr 2012 13:46:08 -0700 [thread overview]
Message-ID: <4F873F10.6010207@candelatech.com> (raw)
In-Reply-To: <1334259053.2497.18.camel-/LGg1Z1CJKReKY3V0RtoKmatzQS1i7+A3tAM5lWOD0I@public.gmane.org>
On 04/12/2012 12:30 PM, Ben Hutchings wrote:
> On Thu, 2012-04-12 at 09:51 -0700, Ben Greear wrote:
>> On 04/12/2012 09:42 AM, Florian Fainelli wrote:
>>> Hi,
>>>
>>> Le 04/12/12 18:32, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org a écrit :
>>>> From: Ben Greear<greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>>
>>>> The signal and noise are forced to be positive since ethtool
>>>> deals in unsigned 64-bit values and this number should be human
>>>> readable. This gives easy access to some of the data formerly
>>>> exposed in the deprecated /proc/net/wireless file.
>>>
>>> Uh, that's misleading, the signal and noise values are typically negative, so one needs to think about mentally adding a minus sign if he/she wants to
>>> understand it. Does not ethtool know about 32-bits signed integers?
>>
>> Ethtool stats only supports u64. I think it's easy enough for
>> humans or programs to add the negative sign. Can signal or noise
>> ever be> 0? If so, that could actually break something that depends
>> on flipping the value to negative....
>
> So far as I can see, the ethtool stats were expected to be counters,
> which obviously cannot become negative (or fractional). Maybe it's time
> to define another command and string-set to cover other types of status
> information. The ethtool utility could ask for those typed statistics
> as well, so 'ethtool -S' would get all of them.
One nice thing about ethtool stats API is that it is backwards and forwards
compatible for a long while. Also, adding a new API means a second call
into the kernel (most likely) for the other set of strings, which effectively
doubles the cost of getting stats (and allows the stats to be updated
out-of-sync with each other more easily).
I wonder if instead we could add a convention where we add a short
prefix (or suffix) to a string to denote it's type (and cast the value
into u64). So, an old ethtool might see:
foo:s32: 4294967295
while a new one understand that the s32: prefix is special, do
some casting, and could show:
foo: -1
Both are still at least somewhat human readable, and probably wouldn't
confuse anyone that is parsing the output of existing ethtool output.
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-04-12 20:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-12 16:32 [PATCH 0/5] Add ethtool stats support for Wireless Devices greearb
2012-04-12 16:32 ` greearb-my8/4N5VtI7c+919tysfdA
2012-04-12 16:32 ` [PATCH 1/5] cfg80211: Add framework to support ethtool stats greearb
2012-04-12 16:32 ` [PATCH 2/5] mac80211: Support getting sta_info stats via ethtool greearb
2012-04-12 16:32 ` [PATCH 3/5] mac80211: Framework to get wifi-driver " greearb
2012-04-12 16:32 ` [PATCH 4/5] mac80211: Add more ethtools stats: survey, rates, etc greearb
2012-04-12 16:32 ` greearb-my8/4N5VtI7c+919tysfdA
2012-04-12 16:42 ` Florian Fainelli
2012-04-12 16:51 ` Ben Greear
2012-04-12 17:56 ` Jan Ceuleers
2012-04-12 19:30 ` Ben Hutchings
2012-04-12 19:30 ` Ben Hutchings
2012-04-12 20:46 ` Ben Greear [this message]
2012-04-12 20:46 ` Ben Greear
2012-04-12 21:05 ` Ben Hutchings
2012-04-12 21:21 ` Ben Greear
2012-04-12 19:53 ` Georgiewskiy Yuriy
2012-04-12 19:53 ` Georgiewskiy Yuriy
2012-04-13 22:01 ` Ben Greear
2012-04-12 16:32 ` [PATCH 5/5] mac80211: Add sta_state to ethtool stats greearb
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=4F873F10.6010207@candelatech.com \
--to=greearb@candelatech.com \
--cc=bhutchings@solarflare.com \
--cc=florian@openwrt.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.