From: Ido Schimmel <idosch@idosch.org>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com,
mlxsw@mellanox.com, shm@cumulusnetworks.com,
kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
kaber@trash.net, lorenzo@google.com, mateusz.bajorski@nokia.com
Subject: Re: [patch net-next 10/10] mlxsw: spectrum_router: Don't abort on l3mdev rules
Date: Mon, 13 Mar 2017 17:22:25 +0200 [thread overview]
Message-ID: <20170313152225.GA8034@splinter.mtl.com> (raw)
In-Reply-To: <7ba7c3ca-f9ba-0ee1-7b56-f139bc4e1fc4@cumulusnetworks.com>
On Mon, Mar 13, 2017 at 08:59:11AM -0600, David Ahern wrote:
> On 3/13/17 1:38 AM, Jiri Pirko wrote:
> > From: Ido Schimmel <idosch@mellanox.com>
> >
> > Now that port netdevs can be enslaved to a VRF master we need to make
> > sure the device's routing tables won't be flushed upon the insertion of
> > a l3mdev rule.
> >
> > Note that we assume the notified l3mdev rule is a simple rule as used by
> > the VRF master. We don't check for the presence of other selectors such
> > as 'iif' and 'oif'.
> >
> > Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > index de54382..fa73ee2 100644
> > --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > @@ -2552,7 +2552,8 @@ static void mlxsw_sp_router_fib_event_work(struct work_struct *work)
> > break;
> > case FIB_EVENT_RULE_ADD: /* fall through */
> > case FIB_EVENT_RULE_DEL:
> > - if (!fib_work->fr_info.rule->def)
> > + if (!fib_work->fr_info.rule->def &&
> > + !fib_work->fr_info.rule->l3mdev)
> > mlxsw_sp_router_fib4_abort(mlxsw_sp);
> > fib_rule_put(fib_work->fr_info.rule);
> > break;
> >
>
> You do not want to abort if the default rules are re-ordered. For
> example, the rule for the local table is moved from priority 0 to just
> before the main. ie., from this order:
Are you aware of configurations employing the VRF device and leaving the
rule for the local table at priority 0?
>
> $ ip ru ls
> 0: from all lookup local
> 32766: from all lookup main
> 32767: from all lookup default
>
> to this order
> $ ip ru ls
> 1000: from all lookup [l3mdev-table]
> 32765: from all lookup local
> 32766: from all lookup main
> 32767: from all lookup default
>
> should not abort offloads.
>
> The default flag added to rules in patch 1 is not really needed; you can
> key off basic references to hardcoded table ids: RT_TABLE_MAIN and
> RT_TABLE_LOCAL are set in stone. Simple rules (from all lookup X) where
> only the priority changes should be enough information to not abort.
OK. Will look into that. I didn't like having the local rule first, so
this might the solution.
> In addition, if rules are added that reference oif or iif that is not a
> port netdev for this h/w then why abort offloads? e.g, consider PBR
> rules related to the management interface.
I'm aware, but not sure this belongs in this patchset. I prefer to deal
with the l3mdev rule and re-ordering of the default rules first, then
move to more advanced use cases.
Thanks David.
next prev parent reply other threads:[~2017-03-13 15:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 7:35 [patch net-next 00/10] mlxsw: Enable VRF offload Jiri Pirko
2017-03-13 7:38 ` [patch net-next 01/10] net: fib_rules: Add default rule indication Jiri Pirko
2017-03-13 7:38 ` [patch net-next 02/10] ipv4: fib_rules: Add notifier info to FIB rules notifications Jiri Pirko
2017-03-13 7:38 ` [patch net-next 03/10] ipv4: fib_rules: Dump FIB rules when registering FIB notifier Jiri Pirko
2017-03-13 14:52 ` David Ahern
2017-03-13 17:33 ` Ido Schimmel
2017-03-13 7:38 ` [patch net-next 04/10] net: Add netif_is_vrf_master helper Jiri Pirko
2017-03-13 14:39 ` David Ahern
2017-03-13 15:01 ` Ido Schimmel
2017-03-13 15:15 ` David Ahern
2017-03-13 15:58 ` Ido Schimmel
2017-03-13 7:38 ` [patch net-next 05/10] net: vrf: Set slave's private flag before linking Jiri Pirko
2017-03-13 15:19 ` David Ahern
2017-03-13 7:38 ` [patch net-next 06/10] mlxsw: spectrum_router: Associate RIFs with correct VR Jiri Pirko
2017-03-13 7:38 ` [patch net-next 07/10] mlxsw: spectrum_router: Don't destroy RIF if L3 slave Jiri Pirko
2017-03-13 7:38 ` [patch net-next 08/10] mlxsw: spectrum_router: Add support for VRFs Jiri Pirko
2017-03-13 7:38 ` [patch net-next 09/10] mlxsw: spectrum_router: Add support for VRFs on top of bridges Jiri Pirko
2017-03-13 7:38 ` [patch net-next 10/10] mlxsw: spectrum_router: Don't abort on l3mdev rules Jiri Pirko
2017-03-13 14:59 ` David Ahern
2017-03-13 15:22 ` Ido Schimmel [this message]
2017-03-13 15:37 ` David Ahern
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=20170313152225.GA8034@splinter.mtl.com \
--to=idosch@idosch.org \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=lorenzo@google.com \
--cc=mateusz.bajorski@nokia.com \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=shm@cumulusnetworks.com \
--cc=yoshfuji@linux-ipv6.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.