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 | ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is | 727 | ``BR_STATE_DISABLED`` and propagating changes to the hardware if this port is |
| 728 | disabled while being a bridge member | 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 | Bridge layer | 860 | Bridge layer |
| 731 | ------------ | 861 | ------------ |
| 732 | 862 | ||
| @@ -835,9 +965,6 @@ Bridge VLAN filtering · 102 unmodified lines | |||
| 835 | function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to | 965 | function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to |
| 836 | a software implementation. | 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 | - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a | 968 | - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a |
| 842 | Forwarding Database entry, the switch hardware should be programmed to delete | 969 | Forwarding Database entry, the switch hardware should be programmed to delete |
| 843 | the specified MAC address from the specified VLAN ID if it was mapped into | 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 | specified address in the specified VLAN ID in the forwarding database | 981 | specified address in the specified VLAN ID in the forwarding database |
| 855 | associated with this VLAN ID. | 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 | - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a | 984 | - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a |
| 861 | multicast database entry, the switch hardware should be programmed to delete | 985 | multicast database entry, the switch hardware should be programmed to delete |
| 862 | the specified MAC address from the specified VLAN ID if it was mapped into | 986 | the specified MAC address from the specified VLAN ID if it was mapped into |