[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191004104217.23ec4a0d@cakuba.hsd1.ca.comcast.net>
Date: Fri, 4 Oct 2019 10:42:17 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, davem@...emloft.net, idosch@...lanox.com,
dsahern@...il.com, tariqt@...lanox.com, saeedm@...lanox.com,
kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org, shuah@...nel.org,
mlxsw@...lanox.com
Subject: Re: [patch net-next v3 11/15] netdevsim: implement proper devlink
reload
On Fri, 4 Oct 2019 08:19:14 +0200, Jiri Pirko wrote:
> >> @@ -84,20 +82,10 @@ int nsim_fib_set_max(struct nsim_fib_data *fib_data,
> >> entry = &fib_data->ipv6.rules;
> >> break;
> >> default:
> >> - return 0;
> >> - }
> >> -
> >> - /* not allowing a new max to be less than curren occupancy
> >> - * --> no means of evicting entries
> >> - */
> >> - if (val < entry->num) {
> >> - NL_SET_ERR_MSG_MOD(extack, "New size is less than current occupancy");
> >> - err = -EINVAL;
> >
> >This change in behaviour should perhaps be mentioned in the commit
> >message. The reload will no longer fail if the resources are
> >insufficient.
>
> Reload is going to fail if the resources are insufficient. I have a
> selftest for that, please see the last patch.
Oh, because re-registering the fib notifier itself will fail?
All good then, thanks.
> >Since we want to test reload more widely than just for the FIB limits
> >that does make sense to me. Is that the thinking?
Powered by blists - more mailing lists