aboutsummaryrefslogtreecommitdiff
path: root/Documentation/networking/dsa/dsa.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/networking/dsa/dsa.rst')
-rw-r--r--Documentation/networking/dsa/dsa.rst29
1 files changed, 16 insertions, 13 deletions
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index 20baacf2bc5c..89bb4fa4c362 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -200,19 +200,6 @@ receive all frames regardless of the value of the MAC DA. This can be done by
setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``.
Note that this assumes a DSA-unaware master driver, which is the norm.
-Hardware manufacturers are strongly discouraged to do this, but some tagging
-protocols might not provide source port information on RX for all packets, but
-e.g. only for control traffic (link-local PDUs). In this case, by implementing
-the ``filter`` method of ``struct dsa_device_ops``, the tagger might select
-which packets are to be redirected on RX towards the virtual DSA user network
-interfaces, and which are to be left in the DSA master's RX data path.
-
-It might also happen (although silicon vendors are strongly discouraged to
-produce hardware like this) that a tagging protocol splits the switch-specific
-information into a header portion and a tail portion, therefore not falling
-cleanly into any of the above 3 categories. DSA does not support this
-configuration.
-
Master network devices
----------------------
@@ -663,6 +650,22 @@ Bridge layer
CPU port, and flooding towards the CPU port should also be enabled, due to a
lack of an explicit address filtering mechanism in the DSA core.
+- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after
+ ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to
+ a non-zero value. Returning success in this function activates the TX
+ forwarding offload bridge feature for this port, which enables the tagging
+ protocol driver to inject data plane packets towards the bridging domain that
+ the port is a part of. Data plane packets are subject to FDB lookup, hardware
+ learning on the CPU port, and do not override the port STP state.
+ Additionally, replication of data plane packets (multicast, flooding) is
+ handled in hardware and the bridge driver will transmit a single skb for each
+ packet that needs replication. The method is provided as a configuration
+ point for drivers that need to configure the hardware for enabling this
+ feature.
+
+- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver
+ leaves a bridge port which had the TX forwarding offload feature enabled.
+
Bridge VLAN filtering
---------------------