netdev - Re: [PATCH RFC net-next] net/fib: Poptrie based FIB 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] [day] [month] [year] [list]

Message-ID: <CAFgPn1B2e2T2pK1cyO-rxzxWLCDFy+-6Fbno+0VEL1UZT9dLXw@mail.gmail.com>
Date:   Mon, 27 Aug 2018 19:03:38 -0400
From:   "Md. Islam" <mislam4@...t.edu>
To:     David Ahern <dsahern@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        makita.toshiaki@....ntt.co.jp, panda@...go.wide.ad.jp,
        yasuhiro.ohara@....com, john fastabend <john.fastabend@...il.com>,
        alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC net-next] net/fib: Poptrie based FIB lookup

On Mon, Aug 27, 2018 at 12:56 PM, David Ahern <dsahern@...il.com> wrote:
> On 8/27/18 10:24 AM, Stephen Hemminger wrote:
>>
>> Also, as Dave mentioned any implementation needs to handle multiple namespaces
>> and routing tables.
>>
>> Could this alternative lookup be enabled via sysctl at runtime rather than kernel config?
>>
>
> I spent time a couple of years ago refactoring IPv4 fib lookups with the
> intent of allowing different algorithms - for use cases like this:
>
> https://github.com/dsahern/linux/commits/net/ipv4-fib-ops
>
> (it is also another way to solve the API nightmare that ipv6 has become).
>
> But the poptrie patches that have been sent so far have much bigger
> problems that need to be addressed before anyone worries about how to
> select poptrie vs lc-trie.
>

> The patch does not handle errors (e.g., if attributes such as tos,
> metric/priority and multipath are not allowed you need to fail the route
> insert;

Poptrie is not intended to replace LC-trie for processing incoming
packets. It rather tries to provide an alternative way to do FIB
lookup in XDP forwarding. I know, its confusing that in the patch,
fib_lookup calls poptrie_lookup. This is just to show how
poptrie_lookup should be called. We shouldn't actually use
poptrie_lookup in fib_lookup.

TOS, metric/priority and multipath can  easily be incorporated by
storing fib_alias rather than netdevice, But the main objective here
is not to worry about TOS, metric/priority, and so on. Let's assume
that we want Linux to work as a TCAM/ ASIC based router. The only job
of Linux here is to forward incoming packet to a destination port ASAP
without worrying about those TOS, metric/priority, and so on.

further, what happens if someone creates > 255 netdevices?),

Most of the commercial ASIC/TCAM routers have no more than 64 ports
these days. I think, 255 netdevice is sufficient in that case. If we
need more than 255 NICs, we can accommodate that by using u16 rather
than u8.

> last patch has both fib tables populated (a no-go), does not handle
> delete or dumps. In the current form, the poptrie algorithm can not be

Yeah, we will need to implement delete/update and dumps. Those will
not be the hardest part, I think. Insertion and lookup are the main
challenge. Once everyone agree on Insertion and Lookup, those can be
implemented incrementally.

Yes, delete and dumps will be needed. This
> taken for a test drive. My suggestion to make it a compile time
> selection is just so people can actually try it out using current admin
> tools.