• Home
  • Raw
  • Download

Lines Matching full:bridge

18 Linux tools such as bridge, iproute2, ifconfig to work transparently whether
477 DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and
495 to the standard iproute2 user space programs (ip-link, bridge), like address
757 ``BR_STATE_BLOCKING`` if the port is a bridge member, or ``BR_STATE_FORWARDING`` if it
764 disabled while being a bridge member
776 For example, all ports that belong to a VLAN-unaware bridge (which is
778 database associated by the driver with that bridge (and not with other
780 VLAN-unaware bridge port should be able to find a VLAN-unaware FDB entry having
782 same bridge. At the same time, the FDB lookup process must be able to not find
784 a port which is a member of a different VLAN-unaware bridge (and is therefore
787 Similarly, each VLAN of each offloaded VLAN-aware bridge should have an
797 At the bridge layer, VLAN-unaware FDB entries have the special VID value of 0,
799 VLAN-unaware bridge may have VLAN-aware (non-zero VID) FDB entries, and a
800 VLAN-aware bridge may have VLAN-unaware FDB entries. As in hardware, the
801 software bridge keeps separate address databases, and offloads to hardware the
819 classified by hardware in one address database), and from a bridge port (which
841 - Local/permanent bridge FDB entries (``BR_FDB_LOCAL``). These are the MAC
842 addresses of the bridge ports, for which packets must be terminated locally
844 bridge.
846 - Static bridge FDB entries installed towards foreign (non-DSA) interfaces
847 present in the same bridge as some DSA switch ports. These are also
848 associated with the address database for that bridge.
851 bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port``
853 for that bridge.
860 - ``DSA_DB_BRIDGE``: the entry belongs to one of the address databases of bridge
861 ``db->bridge``. Separation between the VLAN-unaware database and the per-VID
862 databases of this bridge is expected to be done by the driver.
869 DSA associates each offloaded bridge and each offloaded LAG with a one-based ID
872 scheme (the ID is readable through ``db->bridge.num`` and ``db->lag.id`` or may
878 drivers even if they do not support FDB isolation. However, ``db->bridge.num``
896 Bridge layer
899 Offloading the bridge forwarding plane is optional and handled by the methods
901 be non-zero and exceeded, and in this case, joining a bridge port is still
903 under a software bridge must remain configured in the same way as for
907 Concretely, a port starts offloading the forwarding plane of a bridge once it
909 ``port_bridge_leave`` has been called. Offloading the bridge means autonomously
910 learning FDB entries in accordance with the software bridge port's state, and
912 This is optional even when offloading a bridge port. Tagging protocol drivers
916 switch ports part of the same tree ID to be part of the same bridge forwarding
919 Offloading the TX forwarding process of a bridge is a distinct concept from
922 bridge device's transmit function to potentially multiple egress ports (and
925 Packets for which the bridge requests this behavior are called data plane
930 handled in hardware and the bridge driver will transmit a single skb for each
937 driver for its VLAN-unaware address database associated with that bridge.
938 Alternatively, the bridge may be VLAN-aware, and in that case, it is guaranteed
939 that the packet is also VLAN-tagged with the VLAN ID that the bridge processed
943 - ``port_bridge_join``: bridge layer function invoked when a given switch port is
944 added to a bridge, this function should do what's necessary at the switch
946 domain for it to ingress/egress traffic with other members of the bridge.
948 of this bridge is also offloaded.
950 - ``port_bridge_leave``: bridge layer function invoked when a given switch port is
951 removed from a bridge, this function should do what's necessary at the
953 remaining bridge members.
955 - ``port_stp_state_set``: bridge layer function invoked when a given switch port STP
956 state is computed by the bridge layer and should be propagated to switch
959 - ``port_bridge_flags``: bridge layer function invoked when a port must
963 types of traffic, then the DSA core notifies of any change to the bridge port
964 flags when the port joins and leaves a bridge. DSA does not currently manage
965 the bridge port flags for the CPU port. The assumption is that address
970 - ``port_fast_age``: bridge layer function invoked when flushing the
973 state where it shouldn't, or when leaving a bridge, or when address learning
976 Bridge VLAN filtering
979 - ``port_vlan_filtering``: bridge layer function invoked when the bridge gets
989 - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured
991 of a VLAN only if a foreign bridge port is also a member of it (and
993 VLAN group of the bridge device itself, for termination purposes
994 (``bridge vlan add dev br0 vid 100 self``). VLANs on shared ports are
998 - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the
1001 - ``port_fdb_add``: bridge layer function invoked when the bridge wants to install a
1006 - ``port_fdb_del``: bridge layer function invoked when the bridge wants to remove a
1011 - ``port_fdb_dump``: bridge bypass function invoked by ``ndo_fdb_dump`` on the
1013 hardware FDB entries with the software bridge, this method is implemented as
1016 the ``bridge fdb show`` command.
1018 - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install
1023 - ``port_mdb_del``: bridge layer function invoked when the bridge wants to remove a
1038 bridge are treated as if all individual physical ports that are members of that
1039 LAG join/leave the bridge. Switchdev port attributes (VLAN filtering, STP
1040 state, etc) and objects (VLANs, MDB entries) offloaded to a LAG as bridge port
1042 on all members of the LAG. Static bridge FDB entries on a LAG are not yet
1066 implemented as a function of the bridge driver. MRP uses management PDUs