netdev - Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during route lookup

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: <b7e58c88-a1d8-323d-caa2-99360ca5144e@gmail.com>
Date:   Thu, 20 Jun 2019 18:50:11 -0600
From:   David Ahern <dsahern@...il.com>
To:     Wei Wang <tracywwnj@...il.com>, David Miller <davem@...emloft.net>,
        netdev@...r.kernel.org
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Martin KaFai Lau <kafai@...com>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Wei Wang <weiwan@...gle.com>
Subject: Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during
 route lookup

On 6/20/19 6:36 PM, Wei Wang wrote:
> From: Wei Wang <weiwan@...gle.com>
> 
> Ipv6 route lookup code always grabs refcnt on the dst for the caller.
> But for certain cases, grabbing refcnt is not always necessary if the
> call path is rcu protected and the caller does not cache the dst.
> Another issue in the route lookup logic is:
> When there are multiple custom rules, we have to do the lookup into
> each table associated to each rule individually. And when we can't
> find the route in one table, we grab and release refcnt on
> net->ipv6.ip6_null_entry before going to the next table.
> This operation is completely redundant, and causes false issue because
> net->ipv6.ip6_null_entry is a shared object.
> 
> This patch set introduces a new flag RT6_LOOKUP_F_DST_NOREF for route
> lookup callers to set, to avoid any manipulation on the dst refcnt. And
> it converts the major input and output path to use it.
> 
> The performance gain is noticable.
> I ran synflood tests between 2 hosts under the same switch. Both hosts
> have 20G mlx NIC, and 8 tx/rx queues.
> Sender sends pure SYN flood with random src IPs and ports using trafgen.
> Receiver has a simple TCP listener on the target port.
> Both hosts have multiple custom rules:
> - For incoming packets, only local table is traversed.
> - For outgoing packets, 3 tables are traversed to find the route.
> The packet processing rate on the receiver is as follows:
> - Before the fix: 3.78Mpps
> - After the fix:  5.50Mpps
> 

LGTM. Thanks for doing this - big improvement.

Reviewed-by: David Ahern <dsahern@...il.com>