Lines Matching full:dsa
5 This document describes the **Distributed Switch Architecture (DSA)** subsystem
23 or more CPU or management ports. The DSA subsystem currently relies on the
28 be later referred to as "conduit" and "cpu" in DSA terminology and code.
30 The D in DSA stands for Distributed, because the subsystem has been designed
33 ports are referred to as "dsa" ports in DSA terminology and code. A collection
36 For each front-panel port, DSA creates specialized network devices which are
39 interfaces in DSA terminology and code.
41 The ideal case for using DSA is when an Ethernet switch supports a "switch tag"
54 Note that DSA does not currently create network interfaces for the "cpu" and
55 "dsa" ports because:
61 - the "dsa" port(s) are just conduits between two or more switches, and as such
65 NB: for the past 15 years, the DSA subsystem had been making use of the terms
67 have been removed from the DSA codebase and phased out of the uAPI.
72 DSA supports many vendor-specific tagging protocols, one software-defined
81 All tagging protocols are in ``net/dsa/tag_*.c`` files and implement the
87 shifting to the right (from the perspective of the DSA conduit's frame
90 the MAC DA and MAC SA in place from the DSA conduit's perspective, but
94 that the DSA conduit's frame parser has.
101 with the length in octets of the longest switch frame header/trailer. The DSA
103 accommodate for this extra size in order for DSA user ports to support the
110 Even though applications are not expected to parse DSA-specific frame headers,
120 From the perspective of the network stack, all switches within the same DSA
134 CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA)
135 format, but the DSA links are configured to use the shorter (without Ethertype)
136 DSA frame header, in order to reduce the autonomous packet forwarding overhead.
137 It still remains the case that, if the DSA switch tree is configured for the
139 leaf switches that tagged them with the shorter DSA header. This can be done
141 perform tag translation between DSA and EDSA (which is simply the operation of
144 It is possible to construct cascaded setups of DSA switches even if their
146 no DSA links in this fabric, and each switch constitutes a disjoint DSA switch
147 tree. The DSA links are viewed as simply a pair of a DSA conduit (the out-facing
148 port of the upstream DSA switch) and a CPU port (the in-facing port of the
149 downstream DSA switch).
151 The tagging protocol of the attached DSA switch tree can be viewed through the
152 ``dsa/tagging`` sysfs attribute of the DSA conduit::
154 cat /sys/class/net/eth0/dsa/tagging
156 If the hardware and driver are capable, the tagging protocol of the DSA switch
158 protocol name to the same sysfs device attribute as above (the DSA conduit and
166 for the DSA conduit.
171 ``struct net_device *dev`` represents the virtual DSA user network interface
178 properly, because DSA ensures there is enough space before calling this method.
186 virtual DSA user network interface corresponding to the physical front-facing
190 hardware) packet dissection on the DSA conduit, features such as RPS (Receive
191 Packet Steering) on the DSA conduit would be broken. The DSA framework deals
193 the IP header is to be found in the tagged frame as seen by the DSA conduit.
200 Checksum offload should work with category 1 and 2 taggers when the DSA conduit
202 csum_offset. For those cases, DSA will shift the checksum start and offset by
203 the tag size. If the DSA conduit driver still uses the legacy NETIF_F_IP_CSUM
206 vendors). DSA user ports inherit those flags from the conduit, and it is up to
212 tag is inserted (i.e. inside the tagger). Otherwise, the DSA conduit would
218 with DSA-unaware conduits, mangling what the conduit perceives as MAC DA), the
219 tagging protocol may require the DSA conduit to operate in promiscuous mode, to
222 Note that this assumes a DSA-unaware conduit driver, which is the norm.
229 know whether DSA is enabled (e.g.: to enable/disable specific offload features),
230 but the DSA subsystem has been proven to work with industry standard drivers:
239 When a conduit netdev is used with DSA, a small hook is placed in the
240 networking stack is in order to have the DSA subsystem process the Ethernet
241 switch specific tagging protocol. DSA accomplishes this by registering a
267 4. net/dsa/dsa.c::
270 -> invoke switch tag specific protocol handler in 'net/dsa/tag_*.c'
272 5. net/dsa/tag_*.c:
276 - invoke ``eth_type_trans()`` with the DSA user network device
279 Past this point, the DSA user network devices get delivered regular Ethernet
285 User network devices created by DSA are stacked on top of their conduit network
297 pointers which allow DSA to introduce a level of layering between the networking
300 Upon frame transmission from these user network devices, DSA will look up which
311 device between the DSA user devices and the physical DSA conduits. The LAG
312 device is thus also a DSA conduit, but the LAG slave devices continue to be DSA
314 recovery in case the LAG DSA conduit disappears). Thus, the data path of the LAG
315 DSA conduit is used asymmetrically. On RX, the ``ETH_P_XDSA`` handler, which
316 calls ``dsa_switch_rcv()``, is invoked early (on the physical DSA conduit;
317 LAG slave). Therefore, the RX data path of the LAG DSA conduit is not used.
319 ``dsa_enqueue_skb``, which calls ``dev_queue_xmit`` towards the LAG DSA conduit.
320 The latter calls ``dev_queue_xmit`` towards one physical DSA conduit or the
327 Summarized, this is basically how DSA looks like from a network device
338 | DSA switch driver |
362 In order to be able to read to/from a switch PHY built into it, DSA creates an
378 DSA data structures are defined in ``include/net/dsa.h`` as well as
379 ``net/dsa/dsa_priv.h``:
408 Lack of CPU/DSA network devices
411 DSA does not currently create user network devices for the CPU or DSA ports, as
423 Common pitfalls using DSA setups
426 Once a conduit network device is configured to use DSA (dev->dsa_ptr becomes
437 DSA currently leverages the following subsystems:
447 User network devices exposed by DSA may or may not be interfacing with PHY
448 devices (``struct phy_device`` as defined in ``include/linux/phy.h)``, but the DSA
471 by DSA
477 DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and
480 supported by DSA are the FDB and VLAN objects.
485 DSA registers one devlink device per physical switch in the fabric.
486 For each devlink device, every physical port (i.e. user ports, CPU ports, DSA
489 DSA drivers can make use of the following devlink features:
516 DSA features a standardized binding which is documented in
517 ``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
524 DSA switch drivers need to implement a ``dsa_switch_ops`` structure which will
530 DSA switches are regular ``device`` structures on buses (be they platform, SPI,
531 I2C, MDIO or otherwise). The DSA framework is not involved in their probing
544 - ``ds->ops``: a pointer to the ``dsa_switch_ops`` structure holding the DSA
548 retrieved in all further DSA method callbacks.
551 be configured to obtain driver-specific behavior from the DSA core. Their
552 behavior when set is documented through comments in ``include/net/dsa.h``.
568 Internally, DSA keeps an array of switch trees (group of switches) global to
571 number of the ``dsa,member`` property of the switch's OF node (0 if missing).
583 DSA links are present in the tree's port list). The tree becomes complete when
593 It is mandatory for DSA switch drivers to implement the ``shutdown()`` callback
596 The reason is that DSA keeps a reference on the conduit net device, and if the
597 driver for the conduit device decides to unbind on shutdown, DSA's reference
647 PHY cannot be found. In this case, probing of the DSA switch continues
657 the new DSA conduit ``net_device``. The CPU port associated with the new
660 all the slave devices are physical DSA conduits. LAG DSA also have a
662 duplicate of the first physical DSA conduit's (LAG slave) ``dsa_ptr``. In case
663 of a LAG DSA conduit, a further call to ``port_lag_join`` will be emitted
664 separately for the physical CPU ports associated with the physical DSA
677 - ``phy_read``: Function invoked by the DSA user MDIO bus when attempting to read
682 - ``phy_write``: Function invoked by the DSA user MDIO bus when attempting to write
705 return their values. DSA overlays user network devices general statistics:
745 - ``suspend``: function invoked by the DSA platform device when the system goes to
750 - ``resume``: function invoked by the DSA platform device when the system resumes,
754 - ``port_enable``: function invoked by the DSA user network device ndo_open
756 fully enable a given switch port. DSA takes care of marking the port with
760 - ``port_disable``: function invoked by the DSA user network device ndo_close
762 fully disable a given switch port. DSA takes care of marking the port with
815 DSA (cascade) and CPU ports are also called "shared" ports because they service
817 to is usually embedded in the DSA tag. This means that the CPU port may
829 DSA is able to perform host address filtering for the following kinds of
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
851 bridge as some DSA switch ports, only if ``ds->assisted_learning_on_cpu_port``
855 For various operations detailed below, DSA provides a ``dsa_db`` structure
869 DSA associates each offloaded bridge and each offloaded LAG with a one-based ID
871 refcounting addresses on shared ports. Drivers may piggyback on DSA's numbering
888 another port) becomes the responsibility of the driver, because DSA is unaware
915 ingress switch port. DSA, through ``dsa_port_devlink_setup()``, considers all
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
968 lack of an explicit address filtering mechanism in the DSA core.
1012 physical DSA port interfaces. Since DSA does not attempt to keep in sync its
1033 DSA is capable of offloading a link aggregation group (LAG) to hardware that
1036 ports constitutes a logical port, although DSA has no explicit concept of a
1041 are treated similarly: DSA offloads the same switchdev object / port attribute
1043 supported, since the DSA driver API does not have the concept of a logical port
1047 LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall
1059 retrieved by a DSA switch driver using the ``dsa_lag_id`` function.
1076 however in the case of a device with an offloaded data path such as DSA, it is
1079 implementation. DSA today has no driver which is MRP-aware, therefore it only
1117 DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will
1126 Making SWITCHDEV and DSA converge towards an unified codebase
1131 the other DSA enforces a fairly strict device driver model, and deals with most