Re: [PATCH v2] net/ipv6: allow device-only routes via the multipath API

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 28/11/2025 à 18:49, azey a écrit :
> On 2025-11-28 17:28:41 +0100  Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>> Le 28/11/2025 à 16:54, azey a écrit :
>>>> On 2025-11-28 09:38:07 +0100  Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>>>>> With IPv6, unlike IPv4, the ECMP next hops can be added one by one. Your commit
>>>>> doesn't allow this:
>>>
>>> Hold on, I think I understand what you actually meant by this, sorry.
>>> I got too focused on regressions from the discussion in v1, I'll make
>>> a v3 of the patch that allows dev-only routes to be added via append.
>> Yes, that is what I pointed out.
>>
>> Please, add some self-tests to show that there is no regression. You probably
>> have to test different combinations of NLM_F_* flags. See:
>>
>> https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iproute.c#n2418
> 
> Will do, thanks for the pointer.
> One last thing I'd like to clarify though: would this behavior not also
> itself be considered a regression?
> 
> Currently the add and append routes get added separately, and someone
> could theoretically be relying on the kernel always picking the last
> route instead of making them multipath - essentially still the same
> v1 regression.
That's a good question. I let others speak.
But using the nexthop API would definitely close this question. I wonder why
using this API is not possible for you.

> 
> If not, would it also be acceptable for just any non-RTPROT_KERNEL
> routes to automatically be made multipath like this? It's a simple fix,
> it'd make appending work and it'd still prevent the specific v1
> regression for the case of two interfaces on the same subnet - example
> diff attached.

I don't think that the protocol field is reliable. The user can set it to
whatever he wants.