lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 20 Jan 2017 11:58:04 -0500 (EST) From: David Miller <davem@...emloft.net> To: sekraj@...il.com Cc: kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC] net: ipv6: return the first matched rt6_info for multicast packets in find_rr_leaf() From: Rajasekar Kumar <sekraj@...il.com> Date: Wed, 18 Jan 2017 20:43:37 +0530 > There is a performance issue when large number of interfaces are > enabled with VRRP protocol in 2 router nodes which are connected > to each other. When VRRP hello is received (which is multicast > packet with DIP: ff02::18), a rt6_info node is added to fib6_node > of address ff02::18. This happens for each interface on which > VRRP is enabled. For 2000 interfaces with VRRP enabled, 2000 > rt6_info nodes are added to the same fib6_node. As of today, > find_rr_leaf() goes further to find better match, even after first > successful match based on interface key. In this case, it walks > 2000 nodes for every incoming packet/outgoing packet, which is > expensive and not needed. rt6_info match based on supplied > interface match should be sufficient. The first match occurs > when there is interface match, and after that there can not be > another match for multicast packets. So, first match should be > returned for multicast packets. > > find_rr_leaf() tries to find best available gateway, mainly based on > interface match and gateway's reachablity info.When this is required > for unicast packets, multicast packets do not need either gateway's > reachability status or gateway's Layer2 address as it is derived > from Destination IP (group address). rt6_info match based on supplied > interface match should be sufficient. > > This fix helps in scenario wherein multicast packets arrive in some > interfaces frequently than other interfaces. rt6_info is added to > beginning of list for former cases. Verified this case. > > Signed-off-by: Rajasekar Kumar <sekraj@...il.com> So the only thing different in each rt6_info in the list is the interface, right? Well, that's a part of the lookup key, multicast or not. If the user binds a socket to a specific interface, they want the route lookup to return the rt6_info node with that device. So I think your change introduces a regression, therefore another solution will need to be found for your performance problem.
Powered by blists - more mailing lists