[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190227123232.GE13567@splinter>
Date: Wed, 27 Feb 2019 12:32:34 +0000
From: Ido Schimmel <idosch@...lanox.com>
To: Florian Fainelli <f.fainelli@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
open list <linux-kernel@...r.kernel.org>,
"open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
"moderated list:ETHERNET BRIDGE" <bridge@...ts.linux-foundation.org>,
Jiri Pirko <jiri@...lanox.com>,
"andrew@...n.ch" <andrew@...n.ch>,
"vivien.didelot@...il.com" <vivien.didelot@...il.com>
Subject: Re: [PATCH net-next 7/8] net: switchdev: Replace port attr set SDO
with a notification
On Mon, Feb 25, 2019 at 11:47:12AM -0800, Florian Fainelli wrote:
> On 2/25/19 1:49 AM, Ido Schimmel wrote:
> > On Sun, Feb 24, 2019 at 08:47:27AM -0800, Florian Fainelli wrote:
> >> Le 2/23/19 à 2:32 AM, Ido Schimmel a écrit :
> >>> On Fri, Feb 22, 2019 at 03:59:25PM -0800, Florian Fainelli wrote:
> >>>> - if (attr->flags & SWITCHDEV_F_NO_RECURSE)
> >>>> + if (attr & SWITCHDEV_F_DEFER)
> >>>> + rc = call_switchdev_blocking_notifiers(nt, dev,
> >>>> + &attr_info.info, NULL);
> >>>> + else
> >>>> + rc = call_switchdev_notifiers(nt, dev, &attr_info.info, NULL);
> >>>
> >>> I don't believe this is needed. You're calling this function from
> >>> switchdev_port_attr_set_now() which is always called from process
> >>> context. switchdev_port_attr_set() takes care of that. Similar to
> >>> switchdev_port_obj_add().
> >>
> >> Except for net/bridge/br_switchdev.c when we check the bridge port's
> >> flags support with PRE_BRIDGE_FLAGS. In that case we are executing from
> >> the caller (atomic) context and we can't defer otherwise that trumps the
> >> whole idea of being able to do a quick check and return that to the
> >> caller that we cannot support specific flags. How would you recommend
> >> approaching that?
> >
> > In this case you can invoke call_switchdev_notifiers() directly from
> > br_switchdev_set_port_flag(). Eventually switchdev_port_attr_set() will
> > be gone and bridge code will invoke the notifiers directly.
>
> That can be done, but it still requires the target driver (mlxsw,
> ocelot, dsa, etc.) to support attribute notification from blocking and
> non-blocking context. Are you fine with that?
Yes. Sorry for the latency. I was away yesterday. Reviewed your v2 and
only found one problem. Will run some tests now.
Thanks!
Powered by blists - more mailing lists