| Message ID | b23dbee93ecf34837f58dc48c26c3df17e247e05.1526053548.git.petrm@mellanox.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Ido Schimmel |
| Headers | show |
On Fri, May 11, 2018 at 05:49:26PM +0200, Petr Machata wrote: > When resolving a path that the packet will take after being encapsulated > in mirror-to-gretap scenarios, one of the devices en route could be a > LAG. In that case, mirror to first up slave that corresponds to a front > panel port. > > Signed-off-by: Petr Machata <petrm@mellanox.com> > --- > > Notes: > Unlike VLANs, we don't support LAG in SPAN and RSPAN situations, only > ERSPAN ones. mlxsw can't actually support LAG well--since it needs to > resolve the mirroring to a particular front panel port, there's no way > to express the load balancing that the LAG is supposed to do. > > In SPAN and RSPAN scenarios, the decision to set up a certain mirror is > purely an administrative one, and a given administrator can always > resolve a particular front panel port themselves. For ERSPAN however, > while the decision to mirror is administrative, routing of underlay > packets is a matter of routing protocols that might just happen to put > the remote tunnel end behind a LAG port. For these cases rather than > dropping the mirroring altogether, and reinstating it again only when > routes change, have mlxsw choose an arbitrary LAG member. This is useful info. Can I just copy this into the commit message? The patch looks fine to me otherwise, so I'll apply it now.
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c index e5f4f76..da3f7f5 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c @@ -245,6 +245,19 @@ mlxsw_sp_span_entry_vlan(const struct net_device *vlan_dev, return vlan_dev_real_dev(vlan_dev); } +static struct net_device * +mlxsw_sp_span_entry_lag(struct net_device *lag_dev) +{ + struct net_device *dev; + struct list_head *iter; + + netdev_for_each_lower_dev(lag_dev, dev, iter) + if ((dev->flags & IFF_UP) && mlxsw_sp_port_dev_check(dev)) + return dev; + + return NULL; +} + static __maybe_unused int mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *edev, union mlxsw_sp_l3addr saddr, @@ -278,6 +291,14 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *edev, edev = mlxsw_sp_span_entry_vlan(edev, &vid); } + if (netif_is_lag_master(edev)) { + if (!(edev->flags & IFF_UP)) + goto unoffloadable; + edev = mlxsw_sp_span_entry_lag(edev); + if (!edev) + goto unoffloadable; + } + if (!mlxsw_sp_port_dev_check(edev)) goto unoffloadable;
When resolving a path that the packet will take after being encapsulated in mirror-to-gretap scenarios, one of the devices en route could be a LAG. In that case, mirror to first up slave that corresponds to a front panel port. Signed-off-by: Petr Machata <petrm@mellanox.com> --- Notes: Unlike VLANs, we don't support LAG in SPAN and RSPAN situations, only ERSPAN ones. mlxsw can't actually support LAG well--since it needs to resolve the mirroring to a particular front panel port, there's no way to express the load balancing that the LAG is supposed to do. In SPAN and RSPAN scenarios, the decision to set up a certain mirror is purely an administrative one, and a given administrator can always resolve a particular front panel port themselves. For ERSPAN however, while the decision to mirror is administrative, routing of underlay packets is a matter of routing protocols that might just happen to put the remote tunnel end behind a LAG port. For these cases rather than dropping the mirroring altogether, and reinstating it again only when routes change, have mlxsw choose an arbitrary LAG member. drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)