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]

Date:   Fri, 21 Jun 2019 08:33:57 -0400
From:   Eric Dumazet <edumazet@...gle.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Wei Wang <tracywwnj@...il.com>, David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>, 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 Thu, Jun 20, 2019 at 8:50 PM David Ahern <dsahern@...il.com> wrote:
>
> 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>

Reviewed-by: Eric Dumazet <edumazet@...gle.com>