Lines Matching +full:on +full:- +full:device
1 .. SPDX-License-Identifier: GPL-2.0
6 Ethernet switch device driver model (switchdev)
11 Copyright |copy| 2014-2015 Scott Feldman <sfeldma@gmail.com>
14 The Ethernet switch device driver model (switchdev) is an in-kernel driver
19 an example setup using a data-center-class switch ASIC chip. Other setups
20 with SR-IOV or soft switches, such as OVS, are possible.
25 User-space tools
28 +-------------------------------------------------------------------+
31 +--------------+-------------------------------+
35 +----------------------------------------------+
41 +--+----+----+----+----+----+---+ +-----+-----+
45 +--------------+----------------+ +-----------+
48 +-------------------------------------------------------------------+
50 +--------------+----------------+
51 | Switch device (sw1) |
52 | +----+ +--------+
55 +--|----|----+----+----+----+---+
60 front-panel ports
67 -------------
76 -------------
83 ------------
85 On switchdev driver initialization, the driver will allocate and register a
95 There is (currently) no higher-level kernel object for the switch beyond the
100 is loaded with a different driver, such as a NIC driver, on the management port
101 device.
108 each port of a switch. The ID must be unique between switches on the same
109 system. The ID does not need to be unique between switches on different
112 The switch ID is used to locate ports on a switch and to know if aggregated
120 Hard-coding of kernel netdev names within the driver is discouraged; let the
121 kernel pick the default netdev name, and let udev set the final name based on a
125 useful for dynamically-named ports where the device names its ports based on
127 into 4 10G ports, resulting in 4 port netdevs, the device can give a unique
134 is the port name or ID, and Z is the sub-port name or ID. For example, sw1p1s0
135 would be sub-port 0 on port 1 on switch 1.
140 dev->netns_local
142 If the switchdev driver (and device) only supports offloading of the default
144 the port netdev from being moved out of the default netns. A netns-aware
145 driver/device would not set this flag and be responsible for partitioning
153 higher-level switching constructs. The default construct is a standalone
156 L2 networks. VLANs can be applied to sub-divide L2 networks. L2-over-L3
157 tunnels can be built on ports. These constructs are built using standard Linux
158 tools such as the bridge driver, the bonding/team drivers, and netlink-based
164 the bond's upper master will change. And so on. The driver will track such
166 registering for netdevice events and acting on NETDEV_CHANGEUPPER.
169 ---------------------
172 to the switchdev device by mirroring bridge FDB entries down to the device. An
175 To offloading L2 bridging, the switchdev driver/device should support:
177 - Static FDB entries installed on a bridge port
178 - Notification of learned/forgotten src mac/vlans from device
179 - STP state changes on the port
180 - VLAN flooding of multicast/broadcast and unknown unicast packets
191 (the "static" keyword is non-optional: if not specified, the entry defaults to
196 implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this
213 discouraged: all static FDB entries should be added on a bridge port using the
215 visualize the hardware tables, if the device does not have an interrupt for
221 Note: by default, the bridge does not filter on VLAN and only bridges untagged
222 traffic. To enable VLAN support, turn on VLAN filtering::
229 The switch device will learn/forget source MAC address/VLAN on ingress packets
236 forgetting, and info points to a struct switchdev_notifier_fdb_info. On
256 Learning on the port should be disabled on the bridge using the bridge command::
260 Learning on the device port should be enabled, as well as learning_sync::
262 bridge link set dev DEV learning on self
263 bridge link set dev DEV learning_sync on self
266 the bridge's FDB. It's possible, but not optimal, to enable learning on the
267 device port and on the bridge port, and disable learning_sync.
276 the responsibility of the port driver/device to age out these entries. If the
277 port device supports ageing, when the FDB entry expires, it will notify the
279 device does not support ageing, the driver can simulate ageing using a
286 notification will reset the FDB entry's last-used time to now. The driver
288 second. (The last-used time is visible using the bridge -s fdb option).
290 STP State Change on Port
293 Internally or with a third-party STP protocol implementation (e.g. mstpd), the
295 driver of STP state change on a port using the switchdev op
301 and other IEEE 01:80:c2:xx:xx:xx link-local multicast packets can pass.
303 Note that STP BDPUs are untagged and STP state applies to all VLANs on the port
305 VLANs on the port.
310 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
313 vlan L2 domain, can program the switch device for flooding. The packet may
315 bridge should not reflood the packet to the same ports the device flooded,
316 otherwise there will be duplicate packets on the wire.
319 forwarded by setting the skb->offload_fwd_mark bit. The bridge driver will mark
323 It is possible for the switch device to not handle flooding and push the
325 of ports scale in the L2 domain as the device is much more efficient at
328 If supported by the device, flood control can be offloaded to it, preventing
336 The bridge multicast module will notify port netdevs on every multicast group
342 ------------------
344 Offloading L3 routing requires that device be programmed with FIB entries from
345 the kernel, with the device doing the FIB lookup and forwarding. The device
346 does a longest prefix match (LPM) on FIB entries matching route prefix and
349 To program the device, the driver has to register a FIB notifier handler
353 FIB_EVENT_ENTRY_ADD used for both adding a new FIB entry to the device,
354 or modifying an existing entry on the device.
373 to add/modify/delete IPv4 dst/dest_len prefix on table tb_id. The ``*fi``
374 structure holds details on the route and route's nexthops. ``*dev`` is one
377 Routes offloaded to the device are labeled with "offload" in the ip route
393 The "offload" flag is set in case at least one device offloads the FIB entry.
401 the switch device to forward the packet with the correct dst mac address, the
409 NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops
413 Device driver expected behavior
414 -------------------------------
419 Configuration-less state
423 backing driver must configure the network device such that it is possible to
424 send and receive traffic to this network device and it is properly separated
427 use per-port VLAN identifiers unless a better mechanism is available
430 The network device must be capable of running a full IP protocol stack
432 appropriate filters for VLAN, multicast, unicast etc. The underlying device
438 When configuring VLANs on top of the network device, all VLANs must be working,
440 of a VLAN-aware bridge doing ingress VID checking). See below for details.
442 If the device implements e.g.: VLAN filtering, putting the interface in
449 When a switchdev enabled network device is added as a bridge member, it should
450 not disrupt any functionality of non-bridged network devices and they
451 should continue to behave as normal network devices. Depending on the bridge
458 at device creation time, and dynamically, during run time) which must be
459 observed by the underlying switchdev network device/hardware:
461 - with VLAN filtering turned off: the bridge is strictly VLAN unaware and its
462 data path will process all Ethernet frames as if they are VLAN-untagged.
465 device with a VID that is not programmed into the bridge/switch's VLAN table
466 must be forwarded and may be processed using a VLAN device (see below).
468 - with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing
469 the device with a VID that is not programmed into the bridges/switch's VLAN
472 When there is a VLAN device (e.g: sw0p1.100) configured on top of a switchdev
473 network device which is a bridge port member, the behavior of the software
477 - with VLAN filtering turned off, the bridge will process all ingress traffic
487 untagged packets. This internal VID spans all ports of the VLAN-unaware
494 - with VLAN filtering turned on, these VLAN devices can be created as long as
495 the bridge does not have an existing VLAN entry with the same VID on any
499 Non-bridged network ports of the same switch fabric must not be disturbed in any
500 way by the enabling of VLAN filtering on the bridge device(s). If the VLAN
503 'rx-vlan-filter: on [fixed]' in the ethtool features.
505 Because VLAN filtering can be turned on/off at runtime, the switchdev driver
506 must be able to reconfigure the underlying hardware on the fly to honor the
509 filtering knob at runtime and require a destruction of the bridge device(s) and
510 creation of new bridge device(s) with a different VLAN filtering value to
514 hardware and driver may still configure itself in a VLAN-aware mode provided
519 VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as
522 The 802.1p (VID 0) tagged packets must be treated in the same way by the device
523 as untagged packets, since the bridge device does not allow the manipulation of
526 When the bridge has VLAN filtering enabled and a PVID is not configured on the
528 has VLAN filtering enabled and a PVID exists on the ingress port, untagged and
529 priority-tagged packets must be accepted and forwarded according to the
539 by the underlying switchdev network device/hardware in the following way:
541 - when IGMP snooping is turned off, multicast traffic must be flooded to all
549 - when IGMP snooping is turned on, multicast traffic must selectively flow
552 router (the local device may also act as a multicast router).
557 Because IGMP snooping can be turned on/off at runtime, the switchdev driver
558 must be able to reconfigure the underlying hardware on the fly to honor the
562 snooping knob at runtime and require the destruction of the bridge device(s)
563 and creation of a new bridge device(s) with a different multicast snooping