| Message ID | 20210629203215.2639720-1-vladimir.oltean@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | [net-next] net: dsa: return -EOPNOTSUPP when driver does not implement .port_lag_join | expand |
On 6/29/2021 1:32 PM, Vladimir Oltean wrote: > The DSA core has a layered structure, and even though we end up > returning 0 (success) to user space when setting a bonding/team upper > that can't be offloaded, some parts of the framework actually need to > know that we couldn't offload that. > > For example, if dsa_switch_lag_join returns 0 as it currently does, > dsa_port_lag_join has no way to tell a successful offload from a > software fallback, and it will call dsa_port_bridge_join afterwards. > Then we'll think we're offloading the bridge master of the LAG, when in > fact we're not even offloading the LAG. In turn, this will make us set > skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't > like it. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Tue, 29 Jun 2021 23:32:15 +0300 you wrote: > The DSA core has a layered structure, and even though we end up > returning 0 (success) to user space when setting a bonding/team upper > that can't be offloaded, some parts of the framework actually need to > know that we couldn't offload that. > > For example, if dsa_switch_lag_join returns 0 as it currently does, > dsa_port_lag_join has no way to tell a successful offload from a > software fallback, and it will call dsa_port_bridge_join afterwards. > Then we'll think we're offloading the bridge master of the LAG, when in > fact we're not even offloading the LAG. In turn, this will make us set > skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't > like it. > > [...] Here is the summary with links: - [net-next] net: dsa: return -EOPNOTSUPP when driver does not implement .port_lag_join https://git.kernel.org/netdev/net-next/c/b71d09871566 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/net/dsa/switch.c b/net/dsa/switch.c index af71b8638098..248455145982 100644 --- a/net/dsa/switch.c +++ b/net/dsa/switch.c @@ -427,7 +427,7 @@ static int dsa_switch_lag_join(struct dsa_switch *ds, info->port, info->lag, info->info); - return 0; + return -EOPNOTSUPP; } static int dsa_switch_lag_leave(struct dsa_switch *ds, @@ -440,7 +440,7 @@ static int dsa_switch_lag_leave(struct dsa_switch *ds, return ds->ops->crosschip_lag_leave(ds, info->sw_index, info->port, info->lag); - return 0; + return -EOPNOTSUPP; } static int dsa_switch_mdb_add(struct dsa_switch *ds,
The DSA core has a layered structure, and even though we end up returning 0 (success) to user space when setting a bonding/team upper that can't be offloaded, some parts of the framework actually need to know that we couldn't offload that. For example, if dsa_switch_lag_join returns 0 as it currently does, dsa_port_lag_join has no way to tell a successful offload from a software fallback, and it will call dsa_port_bridge_join afterwards. Then we'll think we're offloading the bridge master of the LAG, when in fact we're not even offloading the LAG. In turn, this will make us set skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't like it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> --- net/dsa/switch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)