From: Ben Greear <greearb@candelatech.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
Subject: Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Tue, 20 Mar 2018 08:39:33 -0700 [thread overview]
Message-ID: <37830d46-762b-2a92-4506-5792a65d2ebd@candelatech.com> (raw)
In-Reply-To: <20180320103747.7kcfdu4yzof6bwxw@unicorn.suse.cz>
On 03/20/2018 03:37 AM, Michal Kubecek wrote:
> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This is similar to ETHTOOL_GSTATS, but it allows you to specify
>> a 'level'. This level can be used by the driver to decrease the
>> amount of stats refreshed. In particular, this helps with ath10k
>> since getting the firmware stats can be slow.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>>
>> NOTE: I know to make it upstream I would need to split the patch and
>> remove the #define for 'backporting' that I added. But, is the
>> feature in general wanted? If so, I'll do the patch split and
>> other tweaks that might be suggested.
>
> I'm not familiar enough with the technical background of stats
> collecting to comment on usefulness and desirability of this feature.
> Adding a new command just to add a numeric parameter certainly doesn't
> feel right but it's how the ioctl interface works. I take it as
> a reminder to find some time to get back to the netlink interface.
>
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index 674b6c9..d3b709f 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -1947,6 +1947,54 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)
>> return ret;
>> }
>>
>> +static int ethtool_get_stats2(struct net_device *dev, void __user *useraddr)
>> +{
>> + struct ethtool_stats stats;
>> + const struct ethtool_ops *ops = dev->ethtool_ops;
>> + u64 *data;
>> + int ret, n_stats;
>> + u32 stats_level = 0;
>> +
>> + if (!ops->get_ethtool_stats2 || !ops->get_sset_count)
>> + return -EOPNOTSUPP;
>> +
>> + n_stats = ops->get_sset_count(dev, ETH_SS_STATS);
>> + if (n_stats < 0)
>> + return n_stats;
>> + if (n_stats > S32_MAX / sizeof(u64))
>> + return -ENOMEM;
>> + WARN_ON_ONCE(!n_stats);
>> + if (copy_from_user(&stats, useraddr, sizeof(stats)))
>> + return -EFAULT;
>> +
>> + /* User can specify the level of stats to query. How the
>> + * level value is used is up to the driver, but in general,
>> + * 0 means 'all', 1 means least, and higher means more.
>> + * The idea is that some stats may be expensive to query, so user
>> + * space could just ask for the cheap ones...
>> + */
>> + stats_level = stats.n_stats;
>> +
>> + stats.n_stats = n_stats;
>> + data = vzalloc(n_stats * sizeof(u64));
>> + if (n_stats && !data)
>> + return -ENOMEM;
>> +
>> + ops->get_ethtool_stats2(dev, &stats, data, stats_level);
>> +
>> + ret = -EFAULT;
>> + if (copy_to_user(useraddr, &stats, sizeof(stats)))
>> + goto out;
>> + useraddr += sizeof(stats);
>> + if (n_stats && copy_to_user(useraddr, data, n_stats * sizeof(u64)))
>> + goto out;
>> + ret = 0;
>> +
>> + out:
>> + vfree(data);
>> + return ret;
>> +}
>> +
>> static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)
>> {
>> struct ethtool_stats stats;
>
> IMHO it would be more practical to set "0 means same as GSTATS" as a
> rule and make ethtool_get_stats() a wrapper for ethtool_get_stats2() to
> avoid code duplication (or perhaps a use fall-through in the switch). It
> would also allow drivers to provide only one of the callbacks.
Yes, but that would require changing all drivers at once, and would make backporting
and out-of-tree drivers harder to manage. I had low hopes that this feature would
make it upstream, so I didn't want to propose any large changes up front.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-03-20 15:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-07 19:51 [RFC] ethtool: Support ETHTOOL_GSTATS2 command greearb
2018-03-20 10:37 ` Michal Kubecek
2018-03-20 15:39 ` Ben Greear [this message]
2018-03-20 16:11 ` Steve deRosier
2018-03-20 16:24 ` Ben Greear
2018-03-20 18:24 ` Michal Kubecek
2018-03-20 18:29 ` Ben Greear
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=37830d46-762b-2a92-4506-5792a65d2ebd@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mkubecek@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox