Commit 95ca3819 authored by Vladimir Oltean's avatar Vladimir Oltean Committed by David S. Miller

docs: net: dsa: document the new methods for bridge TX forwarding offload

Two new methods have been introduced, add some verbiage about what they do.
Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 37f299d9
......@@ -650,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
---------------------
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment