[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230724161152.2177196-1-anthony.l.nguyen@intel.com>
Date: Mon, 24 Jul 2023 09:11:40 -0700
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: davem@...emloft.net,
kuba@...nel.org,
pabeni@...hat.com,
edumazet@...gle.com,
netdev@...r.kernel.org
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>,
wojciech.drewek@...el.com,
jiri@...nulli.us,
ivecera@...hat.com,
simon.horman@...igine.com,
vladbu@...dia.com
Subject: [PATCH net-next v2 00/12][pull request] ice: switchdev bridge offload
Wojciech Drewek says:
Linux bridge provides ability to learn MAC addresses and vlans
detected on bridge's ports. As a result of this, FDB (forward data base)
entries are created and they can be offloaded to the HW. By adding
VF's port representors to the bridge together with the uplink netdev,
we can learn VF's and link partner's MAC addresses. This is achieved
by slow/exception-path, where packets that do not match any filters
(FDB entries in this case) are send to the bridge ports.
Driver keeps track of the netdevs added to the bridge
by listening for NETDEV_CHANGEUPPER event. We distinguish two types
of bridge ports: uplink port and VF's representor port. Linux
bridge always learns src MAC of the packet on rx path. With the
current slow-path implementation, it means that we will learn
VF's MAC on port repr (when the VF transmits the packet) and
link partner's MAC on uplink (when we receive it on uplink from LAN).
The driver is notified about learning of the MAC/VLAN by
SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation
of the HW filter. The direction of the filter is based on port
type (uplink or VF repr). In case of the uplink, rule forwards
the packets to the LAN (matching on link partner's MAC). When the
notification is received on VF repr then the rule forwards the
packets to the associated VF (matching on VF's MAC).
This approach would not work on its own however. This is because if
one of the directions is offloaded, then the bridge would not be able
to learn the other one. If the egress rule is added (learned on uplink)
then the response from the VF will be sent directly to the LAN.
The packet will not got through slow-path, it would not be seen on
VF's port repr. Because of that, the bridge would not learn VF's MAC.
This is solved by introducing guard rule. It prevents forward rule from
working until the opposite direction is offloaded.
Aging is not fully supported yet, aging time is static for now. The
follow up submissions will introduce counters that will allow us to
keep track if the rule is actually being used or not.
A few fixes/changes are needed for this feature to work with ice driver.
These are introduced in first 5 patches.
Reviewed-by: Vlad Buslov <vladbu@...dia.com>
---
v2: delete FDB entries associated with deleted vlan
add missing vlan_ops calls when clearing pvid
v1: https://lore.kernel.org/netdev/20230620174423.4144938-1-anthony.l.nguyen@intel.com/
The following are changes since commit 5322a27c0d461ab3938dd513b1672b86ee722da7:
Merge branch 'ionic-FLR-support'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE
Marcin Szycik (2):
ice: Add guard rule when creating FDB in switchdev
ice: Add VLAN FDB support in switchdev mode
Michal Swiatkowski (2):
ice: implement bridge port vlan
ice: implement static version of ageing
Pawel Chmielewski (1):
ice: add tracepoints for the switchdev bridge
Wojciech Drewek (7):
ice: Skip adv rules removal upon switchdev release
ice: Prohibit rx mode change in switchdev mode
ice: Don't tx before switchdev is fully configured
ice: Disable vlan pruning for uplink VSI
ice: Unset src prune on uplink VSI
ice: Implement basic eswitch bridge setup
ice: Switchdev FDB events support
drivers/net/ethernet/intel/ice/Makefile | 2 +-
drivers/net/ethernet/intel/ice/ice.h | 5 +-
drivers/net/ethernet/intel/ice/ice_eswitch.c | 46 +-
.../net/ethernet/intel/ice/ice_eswitch_br.c | 1309 +++++++++++++++++
.../net/ethernet/intel/ice/ice_eswitch_br.h | 120 ++
drivers/net/ethernet/intel/ice/ice_lib.c | 25 +
drivers/net/ethernet/intel/ice/ice_lib.h | 1 +
drivers/net/ethernet/intel/ice/ice_main.c | 4 +-
drivers/net/ethernet/intel/ice/ice_repr.c | 2 +-
drivers/net/ethernet/intel/ice/ice_repr.h | 3 +-
drivers/net/ethernet/intel/ice/ice_switch.c | 150 +-
drivers/net/ethernet/intel/ice/ice_switch.h | 6 +-
drivers/net/ethernet/intel/ice/ice_trace.h | 90 ++
drivers/net/ethernet/intel/ice/ice_type.h | 1 +
.../ethernet/intel/ice/ice_vf_vsi_vlan_ops.c | 186 +--
.../ethernet/intel/ice/ice_vf_vsi_vlan_ops.h | 4 +
.../net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 84 +-
.../net/ethernet/intel/ice/ice_vsi_vlan_lib.h | 8 +
.../net/ethernet/intel/ice/ice_vsi_vlan_ops.h | 1 +
19 files changed, 1861 insertions(+), 186 deletions(-)
create mode 100644 drivers/net/ethernet/intel/ice/ice_eswitch_br.c
create mode 100644 drivers/net/ethernet/intel/ice/ice_eswitch_br.h
--
2.38.1
Powered by blists - more mailing lists