From: roopa <roopa@cumulusnetworks.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, jhs@mojatatu.com
Subject: Re: [PATCH net-next RFC] rtnetlink: add new RTM_GETSTATS to dump link stats
Date: Thu, 25 Feb 2016 21:01:10 -0800 [thread overview]
Message-ID: <56CFDC16.1090809@cumulusnetworks.com> (raw)
In-Reply-To: <20160225.112638.939367642956951530.davem@davemloft.net>
On 2/25/16, 8:26 AM, David Miller wrote:
> From: roopa <roopa@cumulusnetworks.com>
> Date: Wed, 24 Feb 2016 21:25:50 -0800
>
>> I did go back and forth on the attribute vs mask.
>> cosmetic but, i guess i did not feel good about having to redefine every attribute again
>> for the bitmap filter ...and i anticipate the list of stat attributes to grow overtime (maybe there is a better way).
>> enum {
>> IFLA_LINK_STATS64,
>> IFLA_LINK_INET6_STATS,
>> IFLA_LINK_MPLS_STATS,
>> __IFLA_LINK_STATS_MAX,
>> };
>>
>> #define IFLA_LINK_STATS64_FILTER 0
>> #define IFLA_LINK_INET6_STATS_FILTER (1 << 0)
>> #define IFLA_LINK_MPLS_STATS_FILTER (2 << 0)
> The filter for X is always (1 << X), so we could work with something like:
>
> #define IFLA_LINK_FILTER_BIT(ATTR) (1 << (ATTR))
i like it
>
> Which seems to suggest that emitting no stats unless they are explicitly requested in
> the bitmask makes sense because:
>
> 1) You don't have to special case STATS64 in the filter mask
>
> 2) Application are forced to be aware of filtering and thus choose only
> what they want to see
>
> How about this?
I am ok with it. It keeps the filtering mask handling consistent. Its a bit inconsistent with the other dump functions,
but this gives user full control of what combination of stats she wants. For something like stats, i think this makes sense.
Thanks again!
Roopa
prev parent reply other threads:[~2016-02-26 5:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 6:01 [PATCH net-next RFC] rtnetlink: add new RTM_GETSTATS to dump link stats Roopa Prabhu
2016-02-23 9:26 ` Rosen, Rami
2016-02-25 4:59 ` roopa
2016-02-24 21:40 ` David Miller
2016-02-25 5:25 ` roopa
2016-02-25 16:26 ` David Miller
2016-02-26 5:01 ` roopa [this message]
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=56CFDC16.1090809@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--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.