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: Windows password security audit tool. GUI, reports in PDF.

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

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

Just a comment: on the system that I work on, the kernel closely
matches the hardware data plane, so the kernel has both roles as data
and control plane.
Whatever routes are installed on the hardware are installed also in the kernel.

On Sun, Mar 24, 2019 at 11:27 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Sun, Mar 24, 2019 at 06:56:42AM -0600, David Ahern wrote:
> >
> > This change also enables many other key features:
> > 1. IPv4 multipath routes are not evicted just because 1 hop goes down.
> > 2. IPv6 multipath routes with device only nexthops (e.g., tunnels).
> > 3. IPv6 nexthop with IPv4 route (aka, RFC 5549) which enables a more
> > natural BGP unnumbered.
> > 4. Lower memory consumption for IPv6 FIB entries which has no sharing at
> > all like IPv4 does.
> > 5. Allows atomic update of nexthop definitions with a single replace
> > command as opposed to replacing the N-routes using it.
>
> Does kernel work as data plane or control plane in any of the above
> features ?
> Sadly the patches allow it to do both, but cumulus doesn't use it
> for data path. The kernel on control plane cpu is merely a database.
> And today it doesn't scale when used as a database.
> The kernel has to be fast as a dataplane but these extra features
> will slow down the routing by making kernel-as-database scale a bit better.
> Hence my suggestion in the previous email: use proper database
> to store routes, nexthops and whatever else necessary to program the asic.
> The kernel doesn't need to hold this information.
>