We've changed the API through which we can offload the bridge TX forwarding process. Update the documentation in light of the removal of 2 DSA switch ops.
Unified · Split
| @@ -730,10 +730,56 @@ Power management · 729 unmodified lines | ||
| 730 | 730 | Bridge layer |
| 731 | 731 | ------------ |
| 732 | 732 | |
| 733 | +Offloading the bridge forwarding plane is optional and handled by the methods | |
| 734 | +below. They may be absent, return -EOPNOTSUPP, or ``ds->max_num_bridges`` may | |
| 735 | +be non-zero and exceeded, and in this case, joining a bridge port is still | |
| 736 | +possible, but the packet forwarding will take place in software, and the ports | |
| 737 | +under a software bridge must remain configured in the same way as for | |
| 738 | +standalone operation, i.e. have all bridging service functions (address | |
| 739 | +learning etc) disabled, and send all received packets to the CPU port only. | |
| 740 | + | |
| 741 | +Concretely, a port starts offloading the forwarding plane of a bridge once it | |
| 742 | +returns success to the ``port_bridge_join`` method, and stops doing so after | |
| 743 | +``port_bridge_leave`` has been called. Offloading the bridge means autonomously | |
| 744 | +learning FDB entries in accordance with the software bridge port's state, and | |
| 745 | +autonomously forwarding (or flooding) received packets without CPU intervention. | |
| 746 | +This is optional even when offloading a bridge port. Tagging protocol drivers | |
| 747 | +are expected to call ``dsa_default_offload_fwd_mark(skb)`` for packets which | |
| 748 | +have already been autonomously forwarded in the forwarding domain of the | |
| 749 | +ingress switch port. DSA, through ``dsa_port_devlink_setup()``, considers all | |
| 750 | +switch ports part of the same tree ID to be part of the same bridge forwarding | |
| 751 | +domain (capable of autonomous forwarding to each other). | |
| 752 | + | |
| 753 | +Offloading the TX forwarding process of a bridge is a distinct concept from | |
| 754 | +simply offloading its forwarding plane, and refers to the ability of certain | |
| 755 | +driver and tag protocol combinations to transmit a single skb coming from the | |
| 756 | +bridge device's transmit function to potentially multiple egress ports (and | |
| 757 | +thereby avoid its cloning in software). | |
| 758 | + | |
| 759 | +Packets for which the bridge requests this behavior are called data plane | |
| 760 | +packets and have ``skb->offload_fwd_mark`` set to true in the tag protocol | |
| 761 | +driver's ``xmit`` function. Data plane packets are subject to FDB lookup, | |
| 762 | +hardware learning on the CPU port, and do not override the port STP state. | |
| 763 | +Additionally, replication of data plane packets (multicast, flooding) is | |
| 764 | +handled in hardware and the bridge driver will transmit a single skb for each | |
| 765 | +packet that may or may not need replication. | |
| 766 | + | |
| 767 | +When the TX forwarding offload is enabled, the tag protocol driver is | |
| 768 | +responsible to inject packets into the data plane of the hardware towards the | |
| 769 | +correct bridging domain (FID) that the port is a part of. The port may be | |
| 770 | +VLAN-unaware, and in this case the FID must be equal to the FID used by the | |
| 771 | +driver for its VLAN-unaware address database associated with that bridge. | |
| 772 | +Alternatively, the bridge may be VLAN-aware, and in that case, it is guaranteed | |
| 773 | +that the packet is also VLAN-tagged with the VLAN ID that the bridge processed | |
| 774 | +this packet in. It is the responsibility of the hardware to untag the VID on | |
| 775 | +the egress-untagged ports, or keep the tag on the egress-tagged ones. | |
| 776 | + | |
| 733 | 777 | - ``port_bridge_join``: bridge layer function invoked when a given switch port is |
| 734 | 778 | added to a bridge, this function should do what's necessary at the switch |
| 735 | 779 | level to permit the joining port to be added to the relevant logical |
| 736 | 780 | domain for it to ingress/egress traffic with other members of the bridge. |
| 781 | + By setting the ``tx_fwd_offload`` argument to true, the TX forwarding process | |
| 782 | + of this bridge is also offloaded. | |
| 737 | 783 | |
| 738 | 784 | - ``port_bridge_leave``: bridge layer function invoked when a given switch port is |
| 739 | 785 | removed from a bridge, this function should do what's necessary at the |
| @@ -755,22 +801,6 @@ Bridge layer · 15 unmodified lines | ||
| 755 | 801 | CPU port, and flooding towards the CPU port should also be enabled, due to a |
| 756 | 802 | lack of an explicit address filtering mechanism in the DSA core. |
| 757 | 803 | |
| 758 | −- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after | |
| 759 | − ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to | |
| 760 | − a non-zero value. Returning success in this function activates the TX | |
| 761 | − forwarding offload bridge feature for this port, which enables the tagging | |
| 762 | − protocol driver to inject data plane packets towards the bridging domain that | |
| 763 | − the port is a part of. Data plane packets are subject to FDB lookup, hardware | |
| 764 | − learning on the CPU port, and do not override the port STP state. | |
| 765 | − Additionally, replication of data plane packets (multicast, flooding) is | |
| 766 | − handled in hardware and the bridge driver will transmit a single skb for each | |
| 767 | − packet that needs replication. The method is provided as a configuration | |
| 768 | − point for drivers that need to configure the hardware for enabling this | |
| 769 | − feature. | |
| 770 | − | |
| 771 | −- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoked when a driver | |
| 772 | − leaves a bridge port which had the TX forwarding offload feature enabled. | |
| 773 | − | |
| 774 | 804 | - ``port_fast_age``: bridge layer function invoked when flushing the |
| 775 | 805 | dynamically learned FDB entries on the port is necessary. This is called when |
| 776 | 806 | transitioning from an STP state where learning should take place to an STP |