On 4/2/19 11:10 AM, Martin Lau wrote:
>> @@ -182,11 +183,10 @@ struct fib_result_nl {
>> int err;
>> };
>>
>> -#ifdef CONFIG_IP_ROUTE_MULTIPATH
>> -#define FIB_RES_NH(res) ((res).fi->fib_nh[(res).nh_sel])
> If nh_sel is still needed, I am likely missing something to understand why
It is part of the uapi, so I can not delete it.
> a new '*nhc' pointer is needed. Is nhc always pointing to the "nh_sel"-ed nh,
> like the current FIB_RES_NH() does?
Right now, yes. In the future, no.
>
> Can you explain more on the commit message:
> "Later, fib_nh can point to data with a nexthop struct."
Today:
fib_info --> fib_nh
fib_nh
...
fib_nh
With nexthops as a separate object
fib_info --> nexthop --> fib_nh
or with a nexthop group:
fib_info --> nexthop --> nexthop --> fib_nh
nexthop --> fib_nh
...
nexthop --> fib_nh
I outlined this here:
https://www.mail-archive.com/[email protected]/msg290606.html
Now, the UAPI that uses nhsel still works in the sense that it tells
which fib_nh is used for a lookup even though internally it is part of a
different struct.
