netdev - Re: [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Mar 2019 20:05:39 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        edumazet@...gle.com, kafai@...com
Subject: Re: [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file

On Mon, Mar 25, 2019 at 11:02:07AM -0600, David Ahern wrote:
> 
> That is followed by refactoring IPv6 again in a direction that makes
> IPv4 and IPv6 more consistent and enables changes (outside of the
> nexthop sets) that will improve IPv6 for a number of cases by removing
> the need to always generate a dst_entry.

That would be a nice feature to have.

> After that are a few patches exporting functions for use by nexthop code
> and then diving into the refactoring enabling separate nexthop objects.
> Again, impacts to performance have been top of mind, and I have done
> what I can to minimize any overhead in the datapath - to the point of a
> few ‘if  (nh)’ checks wrapped in an unlikely. And with the nexthop code
> in place it gives users an alternative to a broken IPv6 multipath API as
> one example.
...
> Again, I have tried to be very careful with the intrusion of checks into
> the datapath with the goal of no measurable impact to performance. I am
> invested to seeing that through and will continue looking for ways to
> improve it for all use cases.

Great to hear.
Can you split up your set into reviewable chunks?
Just this patch alone is too small to see the road ahead
and 80+ patches are too much to review properly.
I still have reservations regarding nexthop id concept, but sounds like
the first 20 or so patches should clean things up.
Especially if you can get rid of dst alloc/free back and forth in ipv6 case.