The given definition for what VID 0 represents in the current port_fdb_add and port_mdb_add is blatantly wrong. Delete it and explain the concepts surrounding DSA's understanding of FDB isolation.
Unified · Split
| @@ -727,6 +727,136 @@ Power management · 726 unmodified lines | ||
| 727 | 727 | ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is |
| 728 | 728 | disabled while being a bridge member |
| 729 | 729 | |
| 730 | +Address databases | |
| 731 | +----------------- | |
| 732 | + | |
| 733 | +Switching hardware is expected to have a table for FDB entries, however not all | |
| 734 | +of them are active at the same time. An address database is the subset (partition) | |
| 735 | +of FDB entries that is active (can be matched by address learning on RX, or FDB | |
| 736 | +lookup on TX) depending on the state of the port. An address database may | |
| 737 | +occasionally be called "FID" (Filtering ID) in this document, although the | |
| 738 | +underlying implementation may choose whatever is available to the hardware. | |
| 739 | + | |
| 740 | +For example, all ports that belong to a VLAN-unaware bridge (which is | |
| 741 | +*currently* VLAN-unaware) are expected to learn source addresses in the | |
| 742 | +database associated by the driver with that bridge (and not with other | |
| 743 | +VLAN-unaware bridges). During forwarding and FDB lookup, a packet received on a | |
| 744 | +VLAN-unaware bridge port should be able to find a VLAN-unaware FDB entry having | |
| 745 | +the same MAC DA as the packet, which is present on another port member of the | |
| 746 | +same bridge. At the same time, the FDB lookup process must be able to not find | |
| 747 | +an FDB entry having the same MAC DA as the packet, if that entry points towards | |
| 748 | +a port which is a member of a different VLAN-unaware bridge (and is therefore | |
| 749 | +associated with a different address database). | |
| 750 | + | |
| 751 | +Similarly, each VLAN of each offloaded VLAN-aware bridge should have an | |
| 752 | +associated address database, which is shared by all ports which are members of | |
| 753 | +that VLAN, but not shared by ports belonging to different bridges that are | |
| 754 | +members of the same VID. | |
| 755 | + | |
| 756 | +In this context, a VLAN-unaware database means that all packets are expected to | |
| 757 | +match on it irrespective of VLAN ID (only MAC address lookup), whereas a | |
| 758 | +VLAN-aware database means that packets are supposed to match based on the VLAN | |
| 759 | +ID from the classified 802.1Q header (or the pvid if untagged). | |
| 760 | + | |
| 761 | +At the bridge layer, VLAN-unaware FDB entries have the special VID value of 0, | |
| 762 | +whereas VLAN-aware FDB entries have non-zero VID values. Note that a | |
| 763 | +VLAN-unaware bridge may have VLAN-aware (non-zero VID) FDB entries, and a | |
| 764 | +VLAN-aware bridge may have VLAN-unaware FDB entries. As in hardware, the | |
| 765 | +software bridge keeps separate address databases, and offloads to hardware the | |
| 766 | +FDB entries belonging to these databases, through switchdev, asynchronously | |
| 767 | +relative to the moment when the databases become active or inactive. | |
| 768 | + | |
| 769 | +When a user port operates in standalone mode, its driver should configure it to | |
| 770 | +use a separate database called a port private database. This is different from | |
| 771 | +the databases described above, and should impede operation as standalone port | |
| 772 | +(packet in, packet out to the CPU port) as little as possible. For example, | |
| 773 | +on ingress, it should not attempt to learn the MAC SA of ingress traffic, since | |
| 774 | +learning is a bridging layer service and this is a standalone port, therefore | |
| 775 | +it would consume useless space. With no address learning, the port private | |
| 776 | +database should be empty in a naive implementation, and in this case, all | |
| 777 | +received packets should be trivially flooded to the CPU port. | |
| 778 | + | |
| 779 | +DSA (cascade) and CPU ports are also called "shared" ports because they service | |
| 780 | +multiple address databases, and the database that a packet should be associated | |
| 781 | +to is usually embedded in the DSA tag. This means that the CPU port may | |
| 782 | +simultaneously transport packets coming from a standalone port (which were | |
| 783 | +classified by hardware in one address database), and from a bridge port (which | |
| 784 | +were classified to a different address database). | |
| 785 | + | |
| 786 | +Switch drivers which satisfy certain criteria are able to optimize the naive | |
| 787 | +configuration by removing the CPU port from the flooding domain of the switch, | |
| 788 | +and just program the hardware with FDB entries pointing towards the CPU port | |
| 789 | +for which it is known that software is interested in those MAC addresses. | |
| 790 | +Packets which do not match a known FDB entry will not be delivered to the CPU, | |
| 791 | +which will save CPU cycles required for creating an skb just to drop it. | |
| 792 | + | |
| 793 | +DSA is able to perform host address filtering for the following kinds of | |
| 794 | +addresses: | |
| 795 | + | |
| 796 | +- Primary unicast MAC addresses of ports (``dev->dev_addr``). These are | |
| 797 | + associated with the port private database of the respective user port, | |
| 798 | + and the driver is notified to install them through ``port_fdb_add`` towards | |
| 799 | + the CPU port. | |
| 800 | + | |
| 801 | +- Secondary unicast and multicast MAC addresses of ports (addresses added | |
| 802 | + through ``dev_uc_add()`` and ``dev_mc_add()``). These are also associated | |
| 803 | + with the port private database of the respective user port. | |
| 804 | + | |
| 805 | +- Local/permanent bridge FDB entries (``BR_FDB_LOCAL``). These are the MAC | |
| 806 | + addresses of the bridge ports, for which packets must be terminated locally | |
| 807 | + and not forwarded. They are associated with the address database for that | |
| 808 | + bridge. | |
| 809 | + | |
| 810 | +- Static bridge FDB entries installed towards foreign (non-DSA) interfaces | |
| 811 | + present in the same bridge as some DSA switch ports. These are also | |
| 812 | + associated with the address database for that bridge. | |
| 813 | + | |
| 814 | +- Dynamically learned FDB entries on foreign interfaces present in the same | |
| 815 | + bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port`` | |
| 816 | + is set to true by the driver. These are associated with the address database | |
| 817 | + for that bridge. | |
| 818 | + | |
| 819 | +For various operations detailed below, DSA provides a ``dsa_db`` structure | |
| 820 | +which can be of the following types: | |
| 821 | + | |
| 822 | +- ``DSA_DB_PORT``: the FDB (or MDB) entry to be installed or deleted belongs to | |
| 823 | + the port private database of user port ``db->dp``. | |
| 824 | +- ``DSA_DB_BRIDGE``: the entry belongs to one of the address databases of bridge | |
| 825 | + ``db->bridge``. Separation between the VLAN-unaware database and the per-VID | |
| 826 | + databases of this bridge is expected to be done by the driver. | |
| 827 | +- ``DSA_DB_LAG``: the entry belongs to the address database of LAG ``db->lag``. | |
| 828 | + Note: ``DSA_DB_LAG`` is currently unused and may be removed in the future. | |
| 829 | + | |
| 830 | +The drivers which act upon the ``dsa_db`` argument in ``port_fdb_add``, | |
| 831 | +``port_mdb_add`` etc should declare ``ds->fdb_isolation`` as true. | |
| 832 | + | |
| 833 | +DSA associates each offloaded bridge and each offloaded LAG with a one-based ID | |
| 834 | +(``struct dsa_bridge :: num``, ``struct dsa_lag :: id``) for the purposes of | |
| 835 | +refcounting addresses on shared ports. Drivers may piggyback on DSA's numbering | |
| 836 | +scheme (the ID is readable through ``db->bridge.num`` and ``db->lag.id`` or may | |
| 837 | +implement their own. | |
| 838 | + | |
| 839 | +Only the drivers which declare support for FDB isolation are notified of FDB | |
| 840 | +entries on the CPU port belonging to ``DSA_DB_PORT`` databases. | |
| 841 | +For compatibility/legacy reasons, ``DSA_DB_BRIDGE`` addresses are notified to | |
| 842 | +drivers even if they do not support FDB isolation. However, ``db->bridge.num`` | |
| 843 | +and ``db->lag.id`` are always set to 0 in that case (to denote the lack of | |
| 844 | +isolation, for refcounting purposes). | |
| 845 | + | |
| 846 | +Note that it is not mandatory for a switch driver to implement physically | |
| 847 | +separate address databases for each standalone user port. Since FDB entries in | |
| 848 | +the port private databases will always point to the CPU port, there is no risk | |
| 849 | +for incorrect forwarding decisions. In this case, all standalone ports may | |
| 850 | +share the same database, but the reference counting of host-filtered addresses | |
| 851 | +(not deleting the FDB entry for a port's MAC address if it's still in use by | |
| 852 | +another port) becomes the responsibility of the driver, because DSA is unaware | |
| 853 | +that the port databases are in fact shared. This can be achieved by calling | |
| 854 | +``dsa_fdb_present_in_other_db()`` and ``dsa_mdb_present_in_other_db()``. | |
| 855 | +The down side is that the RX filtering lists of each user port are in fact | |
| 856 | +shared, which means that user port A may accept a packet with a MAC DA it | |
| 857 | +shouldn't have, only because that MAC address was in the RX filtering list of | |
| 858 | +user port B. These packets will still be dropped in software, however. | |
| 859 | + | |
| 730 | 860 | Bridge layer |
| 731 | 861 | ------------ |
| 732 | 862 | |
| @@ -835,9 +965,6 @@ Bridge VLAN filtering · 102 unmodified lines | ||
| 835 | 965 | function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to |
| 836 | 966 | a software implementation. |
| 837 | 967 | |
| 838 | −.. note:: VLAN ID 0 corresponds to the port private database, which, in the context | |
| 839 | − of DSA, would be its port-based VLAN, used by the associated bridge device. | |
| 840 | − | |
| 841 | 968 | - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a |
| 842 | 969 | Forwarding Database entry, the switch hardware should be programmed to delete |
| 843 | 970 | the specified MAC address from the specified VLAN ID if it was mapped into |
| @@ -854,9 +981,6 @@ Bridge VLAN filtering · 10 unmodified lines | ||
| 854 | 981 | specified address in the specified VLAN ID in the forwarding database |
| 855 | 982 | associated with this VLAN ID. |
| 856 | 983 | |
| 857 | −.. note:: VLAN ID 0 corresponds to the port private database, which, in the context | |
| 858 | − of DSA, would be its port-based VLAN, used by the associated bridge device. | |
| 859 | − | |
| 860 | 984 | - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a |
| 861 | 985 | multicast database entry, the switch hardware should be programmed to delete |
| 862 | 986 | the specified MAC address from the specified VLAN ID if it was mapped into |