On Mon, Aug 27, 2018 at 12:56 PM, David Ahern <dsah...@gmail.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.
