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 | Bridge layer | 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 | - ``port_bridge_join``: bridge layer function invoked when a given switch port is | 777 | - ``port_bridge_join``: bridge layer function invoked when a given switch port is |
| 734 | added to a bridge, this function should do what's necessary at the switch | 778 | added to a bridge, this function should do what's necessary at the switch |
| 735 | level to permit the joining port to be added to the relevant logical | 779 | level to permit the joining port to be added to the relevant logical |
| 736 | domain for it to ingress/egress traffic with other members of the bridge. | 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 | - ``port_bridge_leave``: bridge layer function invoked when a given switch port is | 784 | - ``port_bridge_leave``: bridge layer function invoked when a given switch port is |
| 739 | removed from a bridge, this function should do what's necessary at the | 785 | removed from a bridge, this function should do what's necessary at the |
| @@ -755,22 +801,6 @@ Bridge layer · 15 unmodified lines | |||
| 755 | CPU port, and flooding towards the CPU port should also be enabled, due to a | 801 | CPU port, and flooding towards the CPU port should also be enabled, due to a |
| 756 | lack of an explicit address filtering mechanism in the DSA core. | 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 | - ``port_fast_age``: bridge layer function invoked when flushing the | 804 | - ``port_fast_age``: bridge layer function invoked when flushing the |
| 775 | dynamically learned FDB entries on the port is necessary. This is called when | 805 | dynamically learned FDB entries on the port is necessary. This is called when |
| 776 | transitioning from an STP state where learning should take place to an STP | 806 | transitioning from an STP state where learning should take place to an STP |