IFLA_INET6_[ICMP6]STATS
Subsystems (2)
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
David Miller
maintainerFrom: Sowmini Varadhan <[email protected]>
Date: Wed, 9 Sep 2015 17:34:44 -0400
Quoted 4 lines
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.
Quoted 4 lines · David Miller
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
Quoted 16 lines · 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 commita3a77372.In my case, it looks like
getifaddrs()doesnt even use the results ofIFLA_INET6_STATSor IFLA_INET6_ICMP6STATS- from my scan of glibc, this information is ignored (it only looks atIFLA_STATS). Moreover, if I hack out all ofsnmp_fold_field()(so that it always returns 0), it helps my cpu utilization and scaling, and no errors are reported.
Quoted 4 lines
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")
Quoted 8 lines · David Miller
From: Sowmini Varadhan <[email protected]>
Date: Wed, 9 Sep 2015 17:34:44 -0400Quoted 4 lines
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.
Quoted 6 lines
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..
Quoted 8 lines · Sowmini Varadhan
Quoted 3 lines · David Miller
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).
Quoted 7 lines · roopa
If you decide to use a flag, there is
IFLA_EXT_MASKwhich is used to specify such filters from userspace today./* New extended info filters for
IFLA_EXT_MASK*/
#defineRTEXT_FILTER_VF(1 << 0)
#defineRTEXT_FILTER_BRVLAN(1 << 1)
#defineRTEXT_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
David Miller
maintainerFrom: Sowmini Varadhan <[email protected]>
Date: Thu, 10 Sep 2015 11:48:19 -0400
Quoted 12 lines · roopa
Quoted 7 lines
If you decide to use a flag, there is
IFLA_EXT_MASKwhich is used to specify such filters from userspace today./* New extended info filters for
IFLA_EXT_MASK*/
#defineRTEXT_FILTER_VF(1 << 0)
#defineRTEXT_FILTER_BRVLAN(1 << 1)
#defineRTEXT_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.
Quoted 2 lines · David Miller
I don't think using such a generic netlink flag works best, the
IFLA_EXT_MASKis definitely more suitable.
Ok, though this more of a IFLA_TRUNCATE_MASK than a IFLA_EXT_MASK.
David Miller
maintainerFrom: Sowmini Varadhan <[email protected]>
Date: Thu, 10 Sep 2015 13:16:30 -0400
Quoted 5 lines · David Miller
Quoted 2 lines
I don't think using such a generic netlink flag works best, the
IFLA_EXT_MASKis definitely more suitable.Ok, though this more of a
IFLA_TRUNCATE_MASKthan aIFLA_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.