netdev - Re: [PATCH net-next v3 0/2] net: introduce and use route hint

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 20 Nov 2019 09:08:01 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, willemdebruijn.kernel@...il.com,
        ecree@...arflare.com, dsahern@...il.com
Subject: Re: [PATCH net-next v3 0/2] net: introduce and use route hint

On Tue, 2019-11-19 at 18:47 -0800, David Miller wrote:
> From: Paolo Abeni <pabeni@...hat.com>
> Date: Tue, 19 Nov 2019 15:38:35 +0100
> 
> > This series leverages the listification infrastructure to avoid
> > unnecessary route lookup on ingress packets. In absence of policy routing,
> > packets with equal daddr will usually land on the same dst.
> > 
> > When processing packet bursts (lists) we can easily reference the previous
> > dst entry. When we hit the 'same destination' condition we can avoid the
> > route lookup, coping the already available dst.
> > 
> > Detailed performance numbers are available in the individual commit
> > messages. Figures are slightly better then previous iteration because
> > thanks to Willem's suggestion we additionally skip early demux when using
> > the route hint.
> > 
> > v2 -> v3:
> >  - use fib*_has_custom_rules() helpers (David A.)
> >  - add ip*_extract_route_hint() helper (Edward C.)
> >  - use prev skb as hint instead of copying data (Willem )
> > 
> > v1 -> v2:
> >  - fix build issue with !CONFIG_IP*_MULTIPLE_TABLES
> >  - fix potential race in ip6_list_rcv_finish()
> 
> To reiterate David A.'s feedback, 

Yep, I'm working to address it...

> having this depend upon
> IP_MULTIPLE_TABLES being disabled is %100 a non-starter.

...anyway in its current form it 'just' depends on CONFIG_IPV6_SUBTREE
being disabled. Next iteration will remove such dep, as per David's
feedback.

Thanks,

Paolo