Lines Matching refs:DSA
5 This document describes the **Distributed Switch Architecture (DSA)** subsystem
23 or more CPU or management port. The DSA subsystem currently relies on the
28 be later referred to as "master" 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 will create 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
68 DSA supports many vendor-specific tagging protocols, one software-defined
83 shifting to the right (from the perspective of the DSA master's frame
86 the MAC DA and MAC SA in place from the DSA master's perspective, but
90 that the DSA master's frame parser has.
97 with the length in octets of the longest switch frame header/trailer. The DSA
99 accommodate for this extra size in order for DSA user ports to support the
106 Even though applications are not expected to parse DSA-specific frame headers,
116 From the perspective of the network stack, all switches within the same DSA
130 CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA)
131 format, but the DSA links are configured to use the shorter (without Ethertype)
132 DSA frame header, in order to reduce the autonomous packet forwarding overhead.
133 It still remains the case that, if the DSA switch tree is configured for the
135 leaf switches that tagged them with the shorter DSA header. This can be done
137 perform tag translation between DSA and EDSA (which is simply the operation of
140 It is possible to construct cascaded setups of DSA switches even if their
142 no DSA links in this fabric, and each switch constitutes a disjoint DSA switch
143 tree. The DSA links are viewed as simply a pair of a DSA master (the out-facing
144 port of the upstream DSA switch) and a CPU port (the in-facing port of the
145 downstream DSA switch).
147 The tagging protocol of the attached DSA switch tree can be viewed through the
148 ``dsa/tagging`` sysfs attribute of the DSA master::
152 If the hardware and driver are capable, the tagging protocol of the DSA switch
154 protocol name to the same sysfs device attribute as above (the DSA master and
162 for the DSA master.
167 ``struct net_device *dev`` represents the virtual DSA user network interface
174 properly, because DSA ensures there is enough space before calling this method.
182 virtual DSA user network interface corresponding to the physical front-facing
186 hardware) packet dissection on the DSA master, features such as RPS (Receive
187 Packet Steering) on the DSA master would be broken. The DSA framework deals
189 the IP header is to be found in the tagged frame as seen by the DSA master.
197 with DSA-unaware masters, mangling what the master perceives as MAC DA), the
198 tagging protocol may require the DSA master to operate in promiscuous mode, to
201 Note that this assumes a DSA-unaware master driver, which is the norm.
208 know whether DSA is enabled (e.g.: to enable/disable specific offload features),
209 but the DSA subsystem has been proven to work with industry standard drivers:
218 When a master netdev is used with DSA, a small hook is placed in the
219 networking stack is in order to have the DSA subsystem process the Ethernet
220 switch specific tagging protocol. DSA accomplishes this by registering a
255 - invoke ``eth_type_trans()`` with the DSA slave network device
258 Past this point, the DSA slave network devices get delivered regular Ethernet
264 Slave network devices created by DSA are stacked on top of their master network
276 pointers which allow DSA to introduce a level of layering between the networking
279 Upon frame transmission from these slave network devices, DSA will look up which
292 Summarized, this is basically how DSA looks like from a network device
303 | DSA switch driver |
327 In order to be able to read to/from a switch PHY built into it, DSA creates a
343 DSA data structures are defined in ``include/net/dsa.h`` as well as
373 Lack of CPU/DSA network devices
376 DSA does not currently create slave network devices for the CPU or DSA ports, as
388 Common pitfalls using DSA setups
391 Once a master network device is configured to use DSA (dev->dsa_ptr becomes
402 DSA currently leverages the following subsystems:
412 Slave network devices exposed by DSA may or may not be interfacing with PHY
413 devices (``struct phy_device`` as defined in ``include/linux/phy.h)``, but the DSA
436 by DSA
442 DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and
445 supported by DSA are the FDB and VLAN objects.
450 DSA registers one devlink device per physical switch in the fabric.
451 For each devlink device, every physical port (i.e. user ports, CPU ports, DSA
454 DSA drivers can make use of the following devlink features:
481 DSA features a standardized binding which is documented in
489 DSA switch drivers need to implement a dsa_switch_ops structure which will
495 Unless requested differently by setting the priv_size member accordingly, DSA
504 - ``probe``: probe routine which will be invoked by the DSA platform device upon
532 - ``phy_read``: Function invoked by the DSA slave MDIO bus when attempting to read
537 - ``phy_write``: Function invoked by the DSA slave MDIO bus when attempting to write
560 return their values. DSA overlays slave network devices general statistics:
600 - ``suspend``: function invoked by the DSA platform device when the system goes to
605 - ``resume``: function invoked by the DSA platform device when the system resumes,
609 - ``port_enable``: function invoked by the DSA slave network device ndo_open
611 fully enabling a given switch port. DSA takes care of marking the port with
615 - ``port_disable``: function invoked by the DSA slave network device ndo_close
617 fully disabling a given switch port. DSA takes care of marking the port with
646 types of traffic, then the DSA core notifies of any change to the bridge port
647 flags when the port joins and leaves a bridge. DSA does not currently manage
651 lack of an explicit address filtering mechanism in the DSA core.
702 of DSA, would be its port-based VLAN, used by the associated bridge device.
721 of DSA, would be its port-based VLAN, used by the associated bridge device.
737 DSA is capable of offloading a link aggregation group (LAG) to hardware that
740 ports constitutes a logical port, although DSA has no explicit concept of a
745 are treated similarly: DSA offloads the same switchdev object / port attribute
747 supported, since the DSA driver API does not have the concept of a logical port
751 LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall
763 retrieved by a DSA switch driver using the ``dsa_lag_id`` function.
780 however in the case of a device with an offloaded data path such as DSA, it is
783 implementation. DSA today has no driver which is MRP-aware, therefore it only
821 DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will
830 Making SWITCHDEV and DSA converge towards an unified codebase
835 the other DSA enforces a fairly strict device driver model, and deals with most