Netdev List
 help / color / mirror / Atom feed
From: Antoine Tenart <atenart@kernel.org>
To: Julian Anastasov <ja@ssi.bg>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, netdev@vger.kernel.org,
	liuhangbin@gmail.com
Subject: Re: [PATCH net-next] net: ipv4: replace the right route in case prefsrc is used
Date: Mon, 20 Nov 2023 10:32:02 +0100	[thread overview]
Message-ID: <170047272220.4264.16199175262224821201@kwain> (raw)
In-Reply-To: <85f52258-d1cb-9c3c-0ea4-602954e929e8@ssi.bg>

Quoting Julian Anastasov (2023-11-17 17:56:57)
> On Fri, 17 Nov 2023, Antoine Tenart wrote:
> > 
> > Note: a selftest wasn't added as `ip route` use NLM_F_EXCL which
> > prevents us from constructing the above routes. But this is a valid
> 
> ip route append/prepend are standard way to create alternative routes,
> if you want to encode a selftest.

Thanks for the pointer.

> > +                     if (cfg->fc_prefsrc &&
> > +                         cfg->fc_prefsrc == fa->fa_info->fib_prefsrc)
> 
>         You may prefer to restrict it for the change operation by
> adding && (cfg->fc_nlflags & NLM_F_REPLACE) check, otherwise if
> we change the prepend position (fa_first) route with such prefsrc
> can not be installed as first one:

Good point, I'll fix in v2 (if any).

>         Even if we consider just the change operation, this patch
> will change the expectation that we replace the first alternative
> route. But I don't know if one uses alternative routes that
> differ in prefsrc.

For example NetworkManager does, but I don't think NLM_F_REPLACE is
used. One could do it manually, but I don't think that is used in
practice either.

>         Note that link routes (nhc_scope RT_SCOPE_HOST) or
> routes with prefixlen!=0 (fib_select_path) are not considered
> as alternatives by the kernel. So, even if we can create such
> routes, they are probably not used. So, deleting link routes
> by prefsrc is good as we remove routes with deleted prefsrc
> but for routing we are using just the first link route.

Right. Replacing routes by prefsrc could help configuring those routes
so they have the right config when the first link route is deleted, but
that's theoretical too. Reasoning here was since we can delete by
prefsrc, we might want to allow to replace too. As you said, there is a
good reason to allow this for route deletion which might not extend to
the change operation.

Thanks!
Antoine

      reply	other threads:[~2023-11-20  9:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 11:48 [PATCH net-next] net: ipv4: replace the right route in case prefsrc is used Antoine Tenart
2023-11-17 16:56 ` Julian Anastasov
2023-11-20  9:32   ` Antoine Tenart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=170047272220.4264.16199175262224821201@kwain \
    --to=atenart@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ja@ssi.bg \
    --cc=kuba@kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox