[patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[Jiri Pirko]

There has been a discussion about if it's better to let masters to
propagate call down themself or if its better just blindly go down and
try to call ndo on every lower netdev. Turned out that more people (me
not included) like the second option better.

This patch changes bridge setlink/dellink in that direction.
Sorry Roopa for forcing you to do it the way I liked initially.

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
 drivers/net/bonding/bond_main.c |  2 --
 drivers/net/team/team.c         |  2 --
 include/net/switchdev.h         |  4 ---
 net/switchdev/switchdev.c       | 78 ++++++++++-------------------------------
 4 files changed, 19 insertions(+), 67 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c026ce9..c1dce04 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4036,8 +4036,6 @@ static const struct net_device_ops bond_netdev_ops = {
 	.ndo_add_slave		= bond_enslave,
 	.ndo_del_slave		= bond_release,
 	.ndo_fix_features	= bond_fix_features,
-	.ndo_bridge_setlink	= ndo_dflt_netdev_switch_port_bridge_setlink,
-	.ndo_bridge_dellink	= ndo_dflt_netdev_switch_port_bridge_dellink,
 };
 
 static const struct device_type bond_type = {
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index a23319f..dbd39b9 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1977,8 +1977,6 @@ static const struct net_device_ops team_netdev_ops = {
 	.ndo_del_slave		= team_del_slave,
 	.ndo_fix_features	= team_fix_features,
 	.ndo_change_carrier     = team_change_carrier,
-	.ndo_bridge_setlink     = ndo_dflt_netdev_switch_port_bridge_setlink,
-	.ndo_bridge_dellink     = ndo_dflt_netdev_switch_port_bridge_dellink,
 };
 
 /***********************
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index e5de53f..489c5c0 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -86,10 +86,6 @@ int netdev_switch_port_bridge_setlink(struct net_device *dev,
 				struct nlmsghdr *nlh, u16 flags);
 int netdev_switch_port_bridge_dellink(struct net_device *dev,
 				struct nlmsghdr *nlh, u16 flags);
-int ndo_dflt_netdev_switch_port_bridge_dellink(struct net_device *dev,
-					       struct nlmsghdr *nlh, u16 flags);
-int ndo_dflt_netdev_switch_port_bridge_setlink(struct net_device *dev,
-					       struct nlmsghdr *nlh, u16 flags);
 int netdev_switch_fib_ipv4_add(u32 dst, int dst_len, struct fib_info *fi,
 			       u8 tos, u8 type, u32 nlflags, u32 tb_id);
 int netdev_switch_fib_ipv4_del(u32 dst, int dst_len, struct fib_info *fi,
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index c9bfa00..ce494cd 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -132,14 +132,24 @@ int netdev_switch_port_bridge_setlink(struct net_device *dev,
 				      struct nlmsghdr *nlh, u16 flags)
 {
 	const struct net_device_ops *ops = dev->netdev_ops;
+	struct net_device *lower_dev;
+	struct list_head *iter;
+	int err;
+	int ret = -EOPNOTSUPP;
 
 	if (!(dev->features & NETIF_F_HW_SWITCH_OFFLOAD))
 		return 0;
 
-	if (!ops->ndo_bridge_setlink)
-		return -EOPNOTSUPP;
+	if (ops->ndo_bridge_setlink)
+		return ops->ndo_bridge_setlink(dev, nlh, flags);
+
+        netdev_for_each_lower_dev(dev, lower_dev, iter) {
+		err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
+		if (err && err != -EOPNOTSUPP)
+			ret = err;
+	}
+	return ret;
 
-	return ops->ndo_bridge_setlink(dev, nlh, flags);
 }
 EXPORT_SYMBOL_GPL(netdev_switch_port_bridge_setlink);
 
@@ -157,66 +167,16 @@ int netdev_switch_port_bridge_dellink(struct net_device *dev,
 				      struct nlmsghdr *nlh, u16 flags)
 {
 	const struct net_device_ops *ops = dev->netdev_ops;
-
-	if (!(dev->features & NETIF_F_HW_SWITCH_OFFLOAD))
-		return 0;
-
-	if (!ops->ndo_bridge_dellink)
-		return -EOPNOTSUPP;
-
-	return ops->ndo_bridge_dellink(dev, nlh, flags);
-}
-EXPORT_SYMBOL_GPL(netdev_switch_port_bridge_dellink);
-
-/**
- *	ndo_dflt_netdev_switch_port_bridge_setlink - default ndo bridge setlink
- *						     op for master devices
- *
- *	@dev: port device
- *	@nlh: netlink msg with bridge port attributes
- *	@flags: bridge setlink flags
- *
- *	Notify master device slaves of bridge port attributes
- */
-int ndo_dflt_netdev_switch_port_bridge_setlink(struct net_device *dev,
-					       struct nlmsghdr *nlh, u16 flags)
-{
 	struct net_device *lower_dev;
 	struct list_head *iter;
-	int ret = 0, err = 0;
+	int err;
+	int ret = -EOPNOTSUPP;
 
 	if (!(dev->features & NETIF_F_HW_SWITCH_OFFLOAD))
-		return ret;
-
-	netdev_for_each_lower_dev(dev, lower_dev, iter) {
-		err = netdev_switch_port_bridge_setlink(lower_dev, nlh, flags);
-		if (err && err != -EOPNOTSUPP)
-			ret = err;
-	}
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(ndo_dflt_netdev_switch_port_bridge_setlink);
-
-/**
- *	ndo_dflt_netdev_switch_port_bridge_dellink - default ndo bridge dellink
- *						     op for master devices
- *
- *	@dev: port device
- *	@nlh: netlink msg with bridge port attributes
- *	@flags: bridge dellink flags
- *
- *	Notify master device slaves of bridge port attribute deletes
- */
-int ndo_dflt_netdev_switch_port_bridge_dellink(struct net_device *dev,
-					       struct nlmsghdr *nlh, u16 flags)
-{
-	struct net_device *lower_dev;
-	struct list_head *iter;
-	int ret = 0, err = 0;
+		return 0;
 
-	if (!(dev->features & NETIF_F_HW_SWITCH_OFFLOAD))
-		return ret;
+	if (ops->ndo_bridge_dellink)
+		return ops->ndo_bridge_dellink(dev, nlh, flags);
 
 	netdev_for_each_lower_dev(dev, lower_dev, iter) {
 		err = netdev_switch_port_bridge_dellink(lower_dev, nlh, flags);
@@ -226,7 +186,7 @@ int ndo_dflt_netdev_switch_port_bridge_dellink(struct net_device *dev,
 
 	return ret;
 }
-EXPORT_SYMBOL_GPL(ndo_dflt_netdev_switch_port_bridge_dellink);
+EXPORT_SYMBOL_GPL(netdev_switch_port_bridge_dellink);
 
 static struct net_device *netdev_switch_get_lowest_dev(struct net_device *dev)
 {
-- 
1.9.3

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[roopa]

On 3/16/15, 7:22 AM, Jiri Pirko wrote:
> There has been a discussion about if it's better to let masters to
> propagate call down themself or if its better just blindly go down and
> try to call ndo on every lower netdev. Turned out that more people (me
> not included) like the second option better.
>
> This patch changes bridge setlink/dellink in that direction.
> Sorry Roopa for forcing you to do it the way I liked initially.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>

no worries. thanks for submitting the patch Jiri.

One thing though (Which i also mentioned in one of the threads on this),
the below command will not work with layered devices with the below patch.
Because 'self' commands will directly try to find the switch port driver 
from
rtnetlink.c and they dont use the switch dev api.

bridge link set dev bond0 learning off self


The code that currently exists in the tree with bond and team supporting 
the op
will actually work.

If you agree with the above, I can rethink how this can be made to work 
with the 'self'
indirection from rtnetlink.c and still use transparent lowerdev 
traversal and resubmit.
Or if you prefer to resubmit, you can.

Thanks,
Roopa

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[Jiri Pirko]

Mon, Mar 16, 2015 at 04:21:03PM CET, roopa@cumulusnetworks.com wrote:
>On 3/16/15, 7:22 AM, Jiri Pirko wrote:
>>There has been a discussion about if it's better to let masters to
>>propagate call down themself or if its better just blindly go down and
>>try to call ndo on every lower netdev. Turned out that more people (me
>>not included) like the second option better.
>>
>>This patch changes bridge setlink/dellink in that direction.
>>Sorry Roopa for forcing you to do it the way I liked initially.
>>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>no worries. thanks for submitting the patch Jiri.
>
>One thing though (Which i also mentioned in one of the threads on this),
>the below command will not work with layered devices with the below patch.
>Because 'self' commands will directly try to find the switch port driver from
>rtnetlink.c and they dont use the switch dev api.
>
>bridge link set dev bond0 learning off self
>
>
>The code that currently exists in the tree with bond and team supporting the
>op
>will actually work.

Hmm, interesting.

DaveM, this might be a good argument for call propagation. What do you
think?


>
>If you agree with the above, I can rethink how this can be made to work with
>the 'self'
>indirection from rtnetlink.c and still use transparent lowerdev traversal and
>resubmit.
>Or if you prefer to resubmit, you can.
>
>Thanks,
>Roopa
>

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[roopa]

On 3/16/15, 9:36 AM, Jiri Pirko wrote:
> Mon, Mar 16, 2015 at 04:21:03PM CET, roopa@cumulusnetworks.com wrote:
>> On 3/16/15, 7:22 AM, Jiri Pirko wrote:
>>> There has been a discussion about if it's better to let masters to
>>> propagate call down themself or if its better just blindly go down and
>>> try to call ndo on every lower netdev. Turned out that more people (me
>>> not included) like the second option better.
>>>
>>> This patch changes bridge setlink/dellink in that direction.
>>> Sorry Roopa for forcing you to do it the way I liked initially.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> no worries. thanks for submitting the patch Jiri.
>>
>> One thing though (Which i also mentioned in one of the threads on this),
>> the below command will not work with layered devices with the below patch.
>> Because 'self' commands will directly try to find the switch port driver from
>> rtnetlink.c and they dont use the switch dev api.
>>
>> bridge link set dev bond0 learning off self
>>
>>
>> The code that currently exists in the tree with bond and team supporting the
>> op
>> will actually work.
> Hmm, interesting.
>
> DaveM, this might be a good argument for call propagation. What do you
> think?
>
For the stp api, it is not...because stp is run in the bridge driver and 
always involves the switchdev api.

lets hold on to in-tree getlink/setlink before we find a better way.

my 2c

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[Jiri Pirko]

Mon, Mar 16, 2015 at 06:07:02PM CET, roopa@cumulusnetworks.com wrote:
>On 3/16/15, 9:36 AM, Jiri Pirko wrote:
>>Mon, Mar 16, 2015 at 04:21:03PM CET, roopa@cumulusnetworks.com wrote:
>>>On 3/16/15, 7:22 AM, Jiri Pirko wrote:
>>>>There has been a discussion about if it's better to let masters to
>>>>propagate call down themself or if its better just blindly go down and
>>>>try to call ndo on every lower netdev. Turned out that more people (me
>>>>not included) like the second option better.
>>>>
>>>>This patch changes bridge setlink/dellink in that direction.
>>>>Sorry Roopa for forcing you to do it the way I liked initially.
>>>>
>>>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>>no worries. thanks for submitting the patch Jiri.
>>>
>>>One thing though (Which i also mentioned in one of the threads on this),
>>>the below command will not work with layered devices with the below patch.
>>>Because 'self' commands will directly try to find the switch port driver from
>>>rtnetlink.c and they dont use the switch dev api.
>>>
>>>bridge link set dev bond0 learning off self
>>>
>>>
>>>The code that currently exists in the tree with bond and team supporting the
>>>op
>>>will actually work.
>>Hmm, interesting.
>>
>>DaveM, this might be a good argument for call propagation. What do you
>>think?
>>
>For the stp api, it is not...because stp is run in the bridge driver and
>always involves the switchdev api.
>
>lets hold on to in-tree getlink/setlink before we find a better way.

Okay. Makes sense.

>
>my 2c

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[John Fastabend]

On 03/16/2015 07:22 AM, Jiri Pirko wrote:
> There has been a discussion about if it's better to let masters to
> propagate call down themself or if its better just blindly go down and
> try to call ndo on every lower netdev. Turned out that more people (me
> not included) like the second option better.
>
> This patch changes bridge setlink/dellink in that direction.
> Sorry Roopa for forcing you to do it the way I liked initially.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>

Hi Jiri,

I'm going to ask the dumb question here because it wasn't clear from
the emails I could dredge up.

Why do you want to do this? Can you add it to the commit message so
in the future it is clear. Specifically what does it mean to propagate
these calls down? Can you give a stacked example?

Thanks,
John

-- 
John Fastabend         Intel Corporation

Re: [patch net-next] switchdev: call bridge setlink/dellink ndos recursively

[Jiri Pirko]

Mon, Mar 16, 2015 at 11:08:32PM CET, john.fastabend@gmail.com wrote:
>On 03/16/2015 07:22 AM, Jiri Pirko wrote:
>>There has been a discussion about if it's better to let masters to
>>propagate call down themself or if its better just blindly go down and
>>try to call ndo on every lower netdev. Turned out that more people (me
>>not included) like the second option better.
>>
>>This patch changes bridge setlink/dellink in that direction.
>>Sorry Roopa for forcing you to do it the way I liked initially.
>>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Hi Jiri,
>
>I'm going to ask the dumb question here because it wasn't clear from
>the emails I could dredge up.
>
>Why do you want to do this? Can you add it to the commit message so

I don't want to do this. It just look like there has been a consensus
that most of the people want this.

>in the future it is clear. Specifically what does it mean to propagate
>these calls down? Can you give a stacked example?

Example of propagation of ndo call through stacked devices:

dev->ops->ndo_bridge_setlink (team_ndo_bridge_setlink)
		-> for_each_team_port(port_dev)
			-> port_dev->ops->ndo_bridge_setlink(rocker_ndo_bridge_setlink)





>
>Thanks,
>John
>
>-- 
>John Fastabend         Intel Corporation