From: Ido Schimmel <idosch@mellanox.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
open list <linux-kernel@vger.kernel.org>,
"open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
"moderated list:ETHERNET BRIDGE"
<bridge@lists.linux-foundation.org>,
Jiri Pirko <jiri@mellanox.com>, "andrew@lunn.ch" <andrew@lunn.ch>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>
Subject: Re: [PATCH net-next v4 0/9] net: Remove switchdev_ops
Date: Tue, 12 Feb 2019 13:14:47 +0000 [thread overview]
Message-ID: <20190212131443.GA13819@splinter> (raw)
In-Reply-To: <20190211191001.8623-1-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series finishes by the removal of switchdev_ops. To get there
> we convert the existing switchdev_port_attr_{set,get} switchdev_ops to
> use a blocking notifier, thus making it consistent with how the objects
> are pushed to the switchdev enabled devices.
>
> Please review and let me know what you think!
>
> David, I would like to get Ido's feedback on this to make sure I did not
> miss something, thank you!
Hi Florian,
Why do you still keep switchdev_port_attr_get()? I believe we can remove
it and simplify things.
After your recent patchset to remove 'PORT_BRIDGE_FLAGS', the only
remaining user of get() is 'PORT_BRIDGE_FLAGS_SUPPORT'. It can be
converted to a blocking set() with 'PORT_PRE_BRIDGE_FLAGS' (or a similar
name).
I would like to make sure we're in sync with regards to future changes.
After this patchset to get rid of switchdev_ops we can continue to
completely removing switchdev (I believe Jiri approves). The
prepare-commit model is not really needed and the two switchdev
notification chains can be split into bridge and vxlan specific chains.
Notifications sent in an atomic context can be handled by drivers
directly in this context. Similar to how FDB/route/neighbour are
handled. It will really simplify things. No need for the defer flag
anymore and tricks like 'PORT_BRIDGE_FLAGS_SUPPORT' and
'PORT_PRE_BRIDGE_FLAGS'. In the atomic context the driver can veto the
requested bridge flags, but program the device from a blocking context
(using a workqueue).
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@mellanox.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"moderated list:ETHERNET BRIDGE"
<bridge@lists.linux-foundation.org>,
open list <linux-kernel@vger.kernel.org>,
"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
Jiri Pirko <jiri@mellanox.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net-next v4 0/9] net: Remove switchdev_ops
Date: Tue, 12 Feb 2019 13:14:47 +0000 [thread overview]
Message-ID: <20190212131443.GA13819@splinter> (raw)
In-Reply-To: <20190211191001.8623-1-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series finishes by the removal of switchdev_ops. To get there
> we convert the existing switchdev_port_attr_{set,get} switchdev_ops to
> use a blocking notifier, thus making it consistent with how the objects
> are pushed to the switchdev enabled devices.
>
> Please review and let me know what you think!
>
> David, I would like to get Ido's feedback on this to make sure I did not
> miss something, thank you!
Hi Florian,
Why do you still keep switchdev_port_attr_get()? I believe we can remove
it and simplify things.
After your recent patchset to remove 'PORT_BRIDGE_FLAGS', the only
remaining user of get() is 'PORT_BRIDGE_FLAGS_SUPPORT'. It can be
converted to a blocking set() with 'PORT_PRE_BRIDGE_FLAGS' (or a similar
name).
I would like to make sure we're in sync with regards to future changes.
After this patchset to get rid of switchdev_ops we can continue to
completely removing switchdev (I believe Jiri approves). The
prepare-commit model is not really needed and the two switchdev
notification chains can be split into bridge and vxlan specific chains.
Notifications sent in an atomic context can be handled by drivers
directly in this context. Similar to how FDB/route/neighbour are
handled. It will really simplify things. No need for the defer flag
anymore and tricks like 'PORT_BRIDGE_FLAGS_SUPPORT' and
'PORT_PRE_BRIDGE_FLAGS'. In the atomic context the driver can veto the
requested bridge flags, but program the device from a blocking context
(using a workqueue).
next prev parent reply other threads:[~2019-02-12 13:14 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 19:09 [PATCH net-next v4 0/9] net: Remove switchdev_ops Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-11 19:09 ` [PATCH net-next v4 1/9] Documentation: networking: switchdev: Update port parent ID section Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-12 12:19 ` Ido Schimmel
2019-02-12 12:19 ` [Bridge] " Ido Schimmel
2019-02-11 19:09 ` [PATCH net-next v4 2/9] switchdev: Add SWITCHDEV_PORT_ATTR_SET, SWITCHDEV_PORT_ATTR_GET Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-12 13:55 ` Ido Schimmel
2019-02-12 13:55 ` [Bridge] " Ido Schimmel
2019-02-11 19:09 ` [PATCH net-next v4 3/9] rocker: Handle SWITCHDEV_PORT_ATTR_GET/SET Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-11 19:09 ` [PATCH net-next v4 4/9] mlxsw: spectrum_switchdev: " Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-12 14:07 ` Ido Schimmel
2019-02-12 14:07 ` [Bridge] " Ido Schimmel
2019-02-11 19:09 ` [PATCH net-next v4 5/9] net: mscc: ocelot: " Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-11 19:09 ` [PATCH net-next v4 6/9] staging: fsl-dpaa2: ethsw: " Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-11 19:09 ` [PATCH net-next v4 7/9] net: dsa: " Florian Fainelli
2019-02-11 19:09 ` [Bridge] " Florian Fainelli
2019-02-11 19:10 ` [PATCH net-next v4 8/9] net: switchdev: Replace port attr get/set SDO with a notification Florian Fainelli
2019-02-11 19:10 ` [Bridge] " Florian Fainelli
2019-02-11 19:10 ` [PATCH net-next v4 9/9] net: Remove switchdev_ops Florian Fainelli
2019-02-11 19:10 ` [Bridge] " Florian Fainelli
2019-02-12 14:10 ` Ido Schimmel
2019-02-12 14:10 ` [Bridge] " Ido Schimmel
2019-02-11 20:16 ` [PATCH net-next v4 0/9] " David Miller
2019-02-11 20:16 ` [Bridge] " David Miller
2019-02-11 21:40 ` Ido Schimmel
2019-02-11 21:40 ` [Bridge] " Ido Schimmel
2019-02-12 13:14 ` Ido Schimmel [this message]
2019-02-12 13:14 ` Ido Schimmel
2019-02-12 13:53 ` Jiri Pirko
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=20190212131443.GA13819@splinter \
--to=idosch@mellanox.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=devel@driverdev.osuosl.org \
--cc=f.fainelli@gmail.com \
--cc=jiri@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.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 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.