[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE4R7bDTV38bR2Oo2nfO6gFQQBhC4avmWdYeK_2sj1bqZWQiEg@mail.gmail.com>
Date: Wed, 4 Mar 2015 20:50:28 -0800
From: Scott Feldman <sfeldma@...il.com>
To: David Miller <davem@...emloft.net>
Cc: Netdev <netdev@...r.kernel.org>,
Jiří Pírko <jiri@...nulli.us>,
Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next v3 0/7] switchdev: add IPv4 routing offload
On Wed, Mar 4, 2015 at 1:06 PM, David Miller <davem@...emloft.net> wrote:
>
> From: Scott Feldman <sfeldma@...il.com>
> Date: Tue, 3 Mar 2015 23:28:06 -0800
>
> > On Tue, Mar 3, 2015 at 9:38 PM, David Miller <davem@...emloft.net> wrote:
> > In v3, the setting and clearing of RTNH_F_EXTERNAL moved to the
> > driver, the implementer of the add/del ndo ops. So RTNH_F_EXTERNAL
> > does get cleared by the driver on fib_flush_external(). We could add
> > an additional clear above the driver, just in case the driver screwed
> > up and forgot to clear it. Driver bug in that case; not sure where to
> > draw the line.
>
> I'd rather the state bit get managed by net/ipv4/*.c rather than
> duplicate this into every driver, that's error prone and duplicates
> logic unnecessarily.
That's the way it was in v2 :(
In v3, net/ipv4/*.c doesn't know if the driver skipped installing a
route to hw. The driver returns 0 as if it was installed. So the
driver has to mark the ones actually installed.
This is why in v2 had return code -EOPNOTSUPP for routes that are
skipped by driver. For example, rocker currently skips ECMP routes.
It's not an err condition.
But I see driver could skip and not skip the wrong combination of
routes such that we get a prefix split, for example. We can't trust
driver.
I don't know what to do for v4. Bummer, we got pretty close. My only
ideas right now involve more code to handling unwinding some routes
from hw when related route fails to install to hw.
-scott
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists