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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170120.115804.2161107773230365505.davem@davemloft.net>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ