IFLA_INET6_[ICMP6]STATS

IFLA_INET6_[ICMP6]STATS

[Sowmini Varadhan]

I'm doing some experiments that are trying to simultaneously
scaling the number of CPUs, and the number of processes 
and encountering getifaddrs() weaknesses.

Others have run into similar things in the past,  e.g., 
  http://lists.openwall.net/netdev/2014/01/23/119
and more relevant to my experiment: the findings behind 
the recent commit a3a77372.

In my case, it looks like getifaddrs() doesnt even use the
results of IFLA_INET6_STATS or IFLA_INET6_ICMP6STATS- 
from my scan of glibc, this information is ignored (it only 
looks at IFLA_STATS).  Moreover, if I hack out  all of 
snmp_fold_field() (so that it always returns 0),  it helps 
my cpu utilization and scaling, and no errors are reported.

So the question is- who uses IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS?
Is this intended for some ND/ripngd etc daemon?  Doesnt seem to 
be documented in rtnetlink(7), and couldnt find any users in glibc,
and google did not find any usage. 

--Sowmini

Re: IFLA_INET6_[ICMP6]STATS

[David Miller]

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Wed, 9 Sep 2015 17:34:44 -0400

> So the question is- who uses IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS?
> Is this intended for some ND/ripngd etc daemon?  Doesnt seem to 
> be documented in rtnetlink(7), and couldnt find any users in glibc,
> and google did not find any usage. 

It doesn't really matter who uses it, it's there forever and we
therefore can't remove it.

But what we could do is add a flag in the netlink request which
elides the stats.  GLIBC et al. could then start setting the flag.

Re: IFLA_INET6_[ICMP6]STATS

[Sowmini Varadhan]

On (09/09/15 14:43), David Miller wrote:
> 
> But what we could do is add a flag in the netlink request which
> elides the stats.  GLIBC et al. could then start setting the flag.
> 

Yes, interestingly that's what I was experimenting with myself 
(though I was using a setsockopt in my version). I'll send out 
a patch rfc later this week for this.

--Sowmini

Re: IFLA_INET6_[ICMP6]STATS

[roopa]

On 9/9/15, 2:45 PM, Sowmini Varadhan wrote:
> On (09/09/15 14:43), David Miller wrote:
>> But what we could do is add a flag in the netlink request which
>> elides the stats.  GLIBC et al. could then start setting the flag.
>>
> Yes, interestingly that's what I was experimenting with myself
> (though I was using a setsockopt in my version). I'll send out
> a patch rfc later this week for this.
>
If you decide to use a flag, there is IFLA_EXT_MASK which is used to 
specify such filters from userspace today.

/* New extended info filters for IFLA_EXT_MASK */
#define RTEXT_FILTER_VF         (1 << 0)
#define RTEXT_FILTER_BRVLAN     (1 << 1)
#define RTEXT_FILTER_BRVLAN_COMPRESSED  (1 << 2)

ideally long term, it would be nice for RTM_GETLINK request msg to 
contain the attributes it is interested in (This would  again be 
optional with the default being get all attributes).

Re: IFLA_INET6_[ICMP6]STATS

[Sowmini Varadhan]

On (09/10/15 08:43), roopa wrote:
> If you decide to use a flag, there is IFLA_EXT_MASK which is used to
> specify such filters from userspace today.
> 
> /* New extended info filters for IFLA_EXT_MASK */
> #define RTEXT_FILTER_VF         (1 << 0)
> #define RTEXT_FILTER_BRVLAN     (1 << 1)
> #define RTEXT_FILTER_BRVLAN_COMPRESSED  (1 << 2)

I was actually going to use a NLM_F* flag, which is what
I thought Dave as suggesting (seems a bit simpler
than IFLA_EXT_MASK). 

--Sowmini

Re: IFLA_INET6_[ICMP6]STATS

[David Miller]

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Thu, 10 Sep 2015 11:48:19 -0400

> On (09/10/15 08:43), roopa wrote:
>> If you decide to use a flag, there is IFLA_EXT_MASK which is used to
>> specify such filters from userspace today.
>> 
>> /* New extended info filters for IFLA_EXT_MASK */
>> #define RTEXT_FILTER_VF         (1 << 0)
>> #define RTEXT_FILTER_BRVLAN     (1 << 1)
>> #define RTEXT_FILTER_BRVLAN_COMPRESSED  (1 << 2)
> 
> I was actually going to use a NLM_F* flag, which is what
> I thought Dave as suggesting (seems a bit simpler
> than IFLA_EXT_MASK). 

I don't think using such a generic netlink flag works best, the
IFLA_EXT_MASK is definitely more suitable.

Re: IFLA_INET6_[ICMP6]STATS

[Sowmini Varadhan]

On (09/10/15 10:13), David Miller wrote:
> I don't think using such a generic netlink flag works best, the
> IFLA_EXT_MASK is definitely more suitable.

Ok, though this more of a IFLA_TRUNCATE_MASK than a IFLA_EXT_MASK.

Re: IFLA_INET6_[ICMP6]STATS

[David Miller]

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Thu, 10 Sep 2015 13:16:30 -0400

> On (09/10/15 10:13), David Miller wrote:
>> I don't think using such a generic netlink flag works best, the
>> IFLA_EXT_MASK is definitely more suitable.
> 
> Ok, though this more of a IFLA_TRUNCATE_MASK than a IFLA_EXT_MASK.

IFLA_EXT_MASK is precisely for filtering out objects and attributes
from a netlink dump or reply, there is no reason to make a new
attribute with a different name for this.

Re: IFLA_INET6_[ICMP6]STATS

[Raghavendra K T]

On 09/10/2015 03:13 AM, David Miller wrote:
> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Wed, 9 Sep 2015 17:34:44 -0400
>
>> So the question is- who uses IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS?
>> Is this intended for some ND/ripngd etc daemon?  Doesnt seem to
>> be documented in rtnetlink(7), and couldnt find any users in glibc,
>> and google did not find any usage.
>
> It doesn't really matter who uses it, it's there forever and we
> therefore can't remove it.
>
> But what we could do is add a flag in the netlink request which
> elides the stats.  GLIBC et al. could then start setting the flag.
>

+1 for this. Had similar thought. Wanted to use a flag at the higher
  level function to avoid snmp stat walk through during i/f creation.

But above idea is better.

Other idea I had was to defer the update using work queue/completion
etc..

Re: IFLA_INET6_[ICMP6]STATS

[Eric Dumazet]

On Wed, 2015-09-09 at 17:34 -0400, Sowmini Varadhan wrote:
> I'm doing some experiments that are trying to simultaneously
> scaling the number of CPUs, and the number of processes 
> and encountering getifaddrs() weaknesses.
> 
> Others have run into similar things in the past,  e.g., 
>   http://lists.openwall.net/netdev/2014/01/23/119
> and more relevant to my experiment: the findings behind 
> the recent commit a3a77372.
> 
> In my case, it looks like getifaddrs() doesnt even use the
> results of IFLA_INET6_STATS or IFLA_INET6_ICMP6STATS- 
> from my scan of glibc, this information is ignored (it only 
> looks at IFLA_STATS).  Moreover, if I hack out  all of 
> snmp_fold_field() (so that it always returns 0),  it helps 
> my cpu utilization and scaling, and no errors are reported.
> 
> So the question is- who uses IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS?
> Is this intended for some ND/ripngd etc daemon?  Doesnt seem to 
> be documented in rtnetlink(7), and couldnt find any users in glibc,
> and google did not find any usage. 

At least ICMP6 stats do not have O(Ncpu) cost anymore,
after commit be281e554e2a4cf2478df7a8b8926c89454bccfa
("ipv6: reduce per device ICMP mib sizes")