From: Vladimir Oltean Date: Sat, 21 Aug 2021 23:04:41 +0000 (+0300) Subject: docs: net: dsa: document the new methods for bridge TX forwarding offload X-Git-Tag: v5.15~428^2~146^2 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=95ca38194c5aa670e54be2c4511dfaea87849d67;p=platform%2Fkernel%2Flinux-starfive.git 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: Vladimir Oltean Signed-off-by: David S. Miller --- diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index b64cb40..89bb4fa 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -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 ---------------------