netdev - [PATCH net-next 0/4] mlxsw: Support VLAN devices in mirroring offloads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 10 May 2018 13:13:02 +0300
From:   Ido Schimmel <idosch@...lanox.com>
To:     netdev@...r.kernel.org, bridge@...ts.linux-foundation.org
Cc:     davem@...emloft.net, jiri@...lanox.com, petrm@...lanox.com,
        stephen@...workplumber.org, nikolay@...ulusnetworks.com,
        mlxsw@...lanox.com, Ido Schimmel <idosch@...lanox.com>
Subject: [PATCH net-next 0/4] mlxsw: Support VLAN devices in mirroring offloads

Petr says:

When offloading "tc action mirred mirror", there are several scenarios
where VLAN devices can show up, that mlxsw can offload on Spectrum
machines.

I) A direct mirror to a VLAN device on top of a front-panel port device
   (commonly referred to as "RSPAN")

II) VLAN device in egress path of a packet when resolving a mirror to
    gretap or ip6gretap netdevice.

Specifically in the latter case, the following are the cases that can be
offloaded:

IIa) VLAN device directly above a physical device.
IIb) A VLAN-unaware bridge where the egress device is as in IIa.
IIc) VLAN device on top of a VLAN-aware bridge where the egress device
     is a physical device.

This patch set implements all the above cases.

First, in patch #1, br_vlan_get_info() is extended to allow bridge
master argument.

Case I is then implemented in patches #2 and #3, case II in patch #4.

Note that handling of VLAN protocol is not included. In case I, mirrored
packets may end up being double-tagged, and it might be reasonable for
the outer tag to be an 802.1ad. However, the protocol type configuration
would have to be put on the same VLAN netdevice that represents normal
VLAN traffic, and mlxsw currently ignores this setting in that case. Thus
this support was left out and the encapsulation always uses 802.1q
protocol.

Petr Machata (4):
  net: bridge: Allow bridge master in br_vlan_get_info()
  mlxsw: reg: Add MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH
  mlxsw: spectrum_span: Support mirror-to-VLAN
  mlxsw: spectrum_span: Support VLAN under mirror-to-gretap

 drivers/net/ethernet/mellanox/mlxsw/reg.h          |  6 ++
 .../net/ethernet/mellanox/mlxsw/spectrum_span.c    | 91 ++++++++++++++++++++--
 net/bridge/br_vlan.c                               |  2 +
 3 files changed, 91 insertions(+), 8 deletions(-)

-- 
2.14.3