On Thu, Jun 20, 2019 at 8:50 PM David Ahern <dsah...@gmail.com> wrote: > > On 6/20/19 6:36 PM, Wei Wang wrote: > > From: Wei Wang <wei...@google.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 <dsah...@gmail.com>
Reviewed-by: Eric Dumazet <eduma...@google.com>
