1 .. SPDX-License-Identifier: GPL-2.0
2 .. include:: <isonum.txt>
3 .. _switchdev:
4
5 ===============================================
6 Ethernet switch device driver model (switchdev)
7 ===============================================
8
9 Copyright |copy| 2014 Jiri Pirko <jiri@resnulli.us>
10
11 Copyright |copy| 2014-2015 Scott Feldman <sfeldma@gmail.com>
12
13
14 The Ethernet switch device driver model (switchdev) is an in-kernel driver
15 model for switch devices which offload the forwarding (data) plane from the
16 kernel.
17
18 Figure 1 is a block diagram showing the components of the switchdev model for
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.
21
22 ::
23
24
25 User-space tools
26
27 user space |
28 +-------------------------------------------------------------------+
29 kernel | Netlink
30 |
31 +--------------+-------------------------------+
32 | Network stack |
33 | (Linux) |
34 | |
35 +----------------------------------------------+
36
37 sw1p2 sw1p4 sw1p6
38 sw1p1 + sw1p3 + sw1p5 + eth1
39 + | + | + | +
40 | | | | | | |
41 +--+----+----+----+----+----+---+ +-----+-----+
42 | Switch driver | | mgmt |
43 | (this document) | | driver |
44 | | | |
45 +--------------+----------------+ +-----------+
46 |
47 kernel | HW bus (eg PCI)
48 +-------------------------------------------------------------------+
49 hardware |
50 +--------------+----------------+
51 | Switch device (sw1) |
52 | +----+ +--------+
53 | | v offloaded data path | mgmt port
54 | | | |
55 +--|----|----+----+----+----+---+
56 | | | | | |
57 + + + + + +
58 p1 p2 p3 p4 p5 p6
59
60 front-panel ports
61
62
63 Fig 1.
64
65
66 Include Files
67 -------------
68
69 ::
70
71 #include <linux/netdevice.h>
72 #include <net/switchdev.h>
73
74
75 Configuration
76 -------------
77
78 Use "depends NET_SWITCHDEV" in driver's Kconfig to ensure switchdev model
79 support is built for driver.
80
81
82 Switch Ports
83 ------------
84
85 On switchdev driver initialization, the driver will allocate and register a
86 struct net_device (using register_netdev()) for each enumerated physical switch
87 port, called the port netdev. A port netdev is the software representation of
88 the physical port and provides a conduit for control traffic to/from the
89 controller (the kernel) and the network, as well as an anchor point for higher
90 level constructs such as bridges, bonds, VLANs, tunnels, and L3 routers. Using
91 standard netdev tools (iproute2, ethtool, etc), the port netdev can also
92 provide to the user access to the physical properties of the switch port such
93 as PHY link state and I/O statistics.
94
95 There is (currently) no higher-level kernel object for the switch beyond the
96 port netdevs. All of the switchdev driver ops are netdev ops or switchdev ops.
97
98 A switch management port is outside the scope of the switchdev driver model.
99 Typically, the management port is not participating in offloaded data plane and
100 is loaded with a different driver, such as a NIC driver, on the management port
101 device.
102
103 Switch ID
104 ^^^^^^^^^
105
106 The switchdev driver must implement the net_device operation
107 ndo_get_port_parent_id for each port netdev, returning the same physical ID for
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
110 systems.
111
112 The switch ID is used to locate ports on a switch and to know if aggregated
113 ports belong to the same switch.
114
115 Port Netdev Naming
116 ^^^^^^^^^^^^^^^^^^
117
118 Udev rules should be used for port netdev naming, using some unique attribute
119 of the port as a key, for example the port MAC address or the port PHYS name.
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
122 port attribute.
123
124 Using port PHYS name (ndo_get_phys_port_name) for the key is particularly
125 useful for dynamically-named ports where the device names its ports based on
126 external configuration. For example, if a physical 40G port is split logically
127 into 4 10G ports, resulting in 4 port netdevs, the device can give a unique
128 name for each port using port PHYS name. The udev rule would be::
129
130 SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="<phys_switch_id>", \
131 ATTR{phys_port_name}!="", NAME="swX$attr{phys_port_name}"
132
133 Suggested naming convention is "swXpYsZ", where X is the switch name or ID, Y
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.
136
137 Port Features
138 ^^^^^^^^^^^^^
139
140 NETIF_F_NETNS_LOCAL
141
142 If the switchdev driver (and device) only supports offloading of the default
143 network namespace (netns), the driver should set this feature flag to prevent
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
146 hardware to preserve netns containment. This means hardware cannot forward
147 traffic from a port in one namespace to another port in another namespace.
148
149 Port Topology
150 ^^^^^^^^^^^^^
151
152 The port netdevs representing the physical switch ports can be organized into
153 higher-level switching constructs. The default construct is a standalone
154 router port, used to offload L3 forwarding. Two or more ports can be bonded
155 together to form a LAG. Two or more ports (or LAGs) can be bridged to bridge
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
159 tools such as iproute2.
160
161 The switchdev driver can know a particular port's position in the topology by
162 monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
163 bond will see its upper master change. If that bond is moved into a bridge,
164 the bond's upper master will change. And so on. The driver will track such
165 movements to know what position a port is in in the overall topology by
166 registering for netdevice events and acting on NETDEV_CHANGEUPPER.
167
168 L2 Forwarding Offload
169 ---------------------
170
171 The idea is to offload the L2 data forwarding (switching) path from the kernel
172 to the switchdev device by mirroring bridge FDB entries down to the device. An
173 FDB entry is the {port, MAC, VLAN} tuple forwarding destination.
174
175 To offloading L2 bridging, the switchdev driver/device should support:
176
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
181
182 Static FDB Entries
183 ^^^^^^^^^^^^^^^^^^
184
185 A driver which implements the ``ndo_fdb_add``, ``ndo_fdb_del`` and
186 ``ndo_fdb_dump`` operations is able to support the command below, which adds a
187 static bridge FDB entry::
188
189 bridge fdb add dev DEV ADDRESS [vlan VID] [self] static
190
191 (the "static" keyword is non-optional: if not specified, the entry defaults to
192 being "local", which means that it should not be forwarded)
193
194 The "self" keyword (optional because it is implicit) has the role of
195 instructing the kernel to fulfill the operation through the ``ndo_fdb_add``
196 implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this
197 will bypass the bridge and therefore leave the software database out of sync
198 with the hardware one.
199
200 To avoid this, the "master" keyword can be used::
201
202 bridge fdb add dev DEV ADDRESS [vlan VID] master static
203
204 The above command instructs the kernel to search for a master interface of
205 ``DEV`` and fulfill the operation through the ``ndo_fdb_add`` method of that.
206 This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification
207 which the port driver can handle and use it to program its hardware table. This
208 way, the software and the hardware database will both contain this static FDB
209 entry.
210
211 Note: for new switchdev drivers that offload the Linux bridge, implementing the
212 ``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly
213 discouraged: all static FDB entries should be added on a bridge port using the
214 "master" flag. The ``ndo_fdb_dump`` is an exception and can be implemented to
215 visualize the hardware tables, if the device does not have an interrupt for
216 notifying the operating system of newly learned/forgotten dynamic FDB
217 addresses. In that case, the hardware FDB might end up having entries that the
218 software FDB does not, and implementing ``ndo_fdb_dump`` is the only way to see
219 them.
220
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::
223
224 echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
225
226 Notification of Learned/Forgotten Source MAC/VLANs
227 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
228
229 The switch device will learn/forget source MAC address/VLAN on ingress packets
230 and notify the switch driver of the mac/vlan/port tuples. The switch driver,
231 in turn, will notify the bridge driver using the switchdev notifier call::
232
233 err = call_switchdev_notifiers(val, dev, info, extack);
234
235 Where val is SWITCHDEV_FDB_ADD when learning and SWITCHDEV_FDB_DEL when
236 forgetting, and info points to a struct switchdev_notifier_fdb_info. On
237 SWITCHDEV_FDB_ADD, the bridge driver will install the FDB entry into the
238 bridge's FDB and mark the entry as NTF_EXT_LEARNED. The iproute2 bridge
239 command will label these entries "offload"::
240
241 $ bridge fdb
242 52:54:00:12:35:01 dev sw1p1 master br0 permanent
243 00:02:00:00:02:00 dev sw1p1 master br0 offload
244 00:02:00:00:02:00 dev sw1p1 self
245 52:54:00:12:35:02 dev sw1p2 master br0 permanent
246 00:02:00:00:03:00 dev sw1p2 master br0 offload
247 00:02:00:00:03:00 dev sw1p2 self
248 33:33:00:00:00:01 dev eth0 self permanent
249 01:00:5e:00:00:01 dev eth0 self permanent
250 33:33:ff:00:00:00 dev eth0 self permanent
251 01:80:c2:00:00:0e dev eth0 self permanent
252 33:33:00:00:00:01 dev br0 self permanent
253 01:00:5e:00:00:01 dev br0 self permanent
254 33:33:ff:12:35:01 dev br0 self permanent
255
256 Learning on the port should be disabled on the bridge using the bridge command::
257
258 bridge link set dev DEV learning off
259
260 Learning on the device port should be enabled, as well as learning_sync::
261
262 bridge link set dev DEV learning on self
263 bridge link set dev DEV learning_sync on self
264
265 Learning_sync attribute enables syncing of the learned/forgotten FDB entry to
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.
268
269 To support learning, the driver implements switchdev op
270 switchdev_port_attr_set for SWITCHDEV_ATTR_PORT_ID_{PRE}_BRIDGE_FLAGS.
271
272 FDB Ageing
273 ^^^^^^^^^^
274
275 The bridge will skip ageing FDB entries marked with NTF_EXT_LEARNED and it is
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
278 driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the
279 device does not support ageing, the driver can simulate ageing using a
280 garbage collection timer to monitor FDB entries. Expired entries will be
281 notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for
282 example of driver running ageing timer.
283
284 To keep an NTF_EXT_LEARNED entry "alive", the driver should refresh the FDB
285 entry by calling call_switchdev_notifiers(SWITCHDEV_FDB_ADD, ...). The
286 notification will reset the FDB entry's last-used time to now. The driver
287 should rate limit refresh notifications, for example, no more than once a
288 second. (The last-used time is visible using the bridge -s fdb option).
289
290 STP State Change on Port
291 ^^^^^^^^^^^^^^^^^^^^^^^^
292
293 Internally or with a third-party STP protocol implementation (e.g. mstpd), the
294 bridge driver maintains the STP state for ports, and will notify the switch
295 driver of STP state change on a port using the switchdev op
296 switchdev_attr_port_set for SWITCHDEV_ATTR_PORT_ID_STP_UPDATE.
297
298 State is one of BR_STATE_*. The switch driver can use STP state updates to
299 update ingress packet filter list for the port. For example, if port is
300 DISABLED, no packets should pass, but if port moves to BLOCKED, then STP BPDUs
301 and other IEEE 01:80:c2:xx:xx:xx link-local multicast packets can pass.
302
303 Note that STP BDPUs are untagged and STP state applies to all VLANs on the port
304 so packet filters should be applied consistently across untagged and tagged
305 VLANs on the port.
306
307 Flooding L2 domain
308 ^^^^^^^^^^^^^^^^^^
309
310 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
311 and unknown unicast packets to all ports in domain, if allowed by port's
312 current STP state. The switch driver, knowing which ports are within which
313 vlan L2 domain, can program the switch device for flooding. The packet may
314 be sent to the port netdev for processing by the bridge driver. The
315 bridge should not reflood the packet to the same ports the device flooded,
316 otherwise there will be duplicate packets on the wire.
317
318 To avoid duplicate packets, the switch driver should mark a packet as already
319 forwarded by setting the skb->offload_fwd_mark bit. The bridge driver will mark
320 the skb using the ingress bridge port's mark and prevent it from being forwarded
321 through any bridge port with the same mark.
322
323 It is possible for the switch device to not handle flooding and push the
324 packets up to the bridge driver for flooding. This is not ideal as the number
325 of ports scale in the L2 domain as the device is much more efficient at
326 flooding packets that software.
327
328 If supported by the device, flood control can be offloaded to it, preventing
329 certain netdevs from flooding unicast traffic for which there is no FDB entry.
330
331 IGMP Snooping
332 ^^^^^^^^^^^^^
333
334 In order to support IGMP snooping, the port netdevs should trap to the bridge
335 driver all IGMP join and leave messages.
336 The bridge multicast module will notify port netdevs on every multicast group
337 changed whether it is static configured or dynamically joined/leave.
338 The hardware implementation should be forwarding all registered multicast
339 traffic groups only to the configured ports.
340
341 L3 Routing Offload
342 ------------------
343
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
347 forwards the packet to the matching FIB entry's nexthop(s) egress ports.
348
349 To program the device, the driver has to register a FIB notifier handler
350 using register_fib_notifier. The following events are available:
351
352 =================== ===================================================
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.
355 FIB_EVENT_ENTRY_DEL used for removing a FIB entry
356 FIB_EVENT_RULE_ADD,
357 FIB_EVENT_RULE_DEL used to propagate FIB rule changes
358 =================== ===================================================
359
360 FIB_EVENT_ENTRY_ADD and FIB_EVENT_ENTRY_DEL events pass::
361
362 struct fib_entry_notifier_info {
363 struct fib_notifier_info info; /* must be first */
364 u32 dst;
365 int dst_len;
366 struct fib_info *fi;
367 u8 tos;
368 u8 type;
369 u32 tb_id;
370 u32 nlflags;
371 };
372
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
375 of the port netdevs mentioned in the route's next hop list.
376
377 Routes offloaded to the device are labeled with "offload" in the ip route
378 listing::
379
380 $ ip route show
381 default via 192.168.0.2 dev eth0
382 11.0.0.0/30 dev sw1p1 proto kernel scope link src 11.0.0.2 offload
383 11.0.0.4/30 via 11.0.0.1 dev sw1p1 proto zebra metric 20 offload
384 11.0.0.8/30 dev sw1p2 proto kernel scope link src 11.0.0.10 offload
385 11.0.0.12/30 via 11.0.0.9 dev sw1p2 proto zebra metric 20 offload
386 12.0.0.2 proto zebra metric 30 offload
387 nexthop via 11.0.0.1 dev sw1p1 weight 1
388 nexthop via 11.0.0.9 dev sw1p2 weight 1
389 12.0.0.3 via 11.0.0.1 dev sw1p1 proto zebra metric 20 offload
390 12.0.0.4 via 11.0.0.9 dev sw1p2 proto zebra metric 20 offload
391 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.15
392
393 The "offload" flag is set in case at least one device offloads the FIB entry.
394
395 XXX: add/mod/del IPv6 FIB API
396
397 Nexthop Resolution
398 ^^^^^^^^^^^^^^^^^^
399
400 The FIB entry's nexthop list contains the nexthop tuple (gateway, dev), but for
401 the switch device to forward the packet with the correct dst mac address, the
402 nexthop gateways must be resolved to the neighbor's mac address. Neighbor mac
403 address discovery comes via the ARP (or ND) process and is available via the
404 arp_tbl neighbor table. To resolve the routes nexthop gateways, the driver
405 should trigger the kernel's neighbor resolution process. See the rocker
406 driver's rocker_port_ipv4_resolve() for an example.
407
408 The driver can monitor for updates to arp_tbl using the netevent notifier
409 NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops
410 for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy
411 to know when arp_tbl neighbor entries are purged from the port.
412
413 Device driver expected behavior
414 -------------------------------
415
416 Below is a set of defined behavior that switchdev enabled network devices must
417 adhere to.
418
419 Configuration-less state
420 ^^^^^^^^^^^^^^^^^^^^^^^^
421
422 Upon driver bring up, the network devices must be fully operational, and the
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
425 from other network devices/ports (e.g.: as is frequent with a switch ASIC). How
426 this is achieved is heavily hardware dependent, but a simple solution can be to
427 use per-port VLAN identifiers unless a better mechanism is available
428 (proprietary metadata for each network port for instance).
429
430 The network device must be capable of running a full IP protocol stack
431 including multicast, DHCP, IPv4/6, etc. If necessary, it should program the
432 appropriate filters for VLAN, multicast, unicast etc. The underlying device
433 driver must effectively be configured in a similar fashion to what it would do
434 when IGMP snooping is enabled for IP multicast over these switchdev network
435 devices and unsolicited multicast must be filtered as early as possible in
436 the hardware.
437
438 When configuring VLANs on top of the network device, all VLANs must be working,
439 irrespective of the state of other network devices (e.g.: other ports being part
440 of a VLAN-aware bridge doing ingress VID checking). See below for details.
441
442 If the device implements e.g.: VLAN filtering, putting the interface in
443 promiscuous mode should allow the reception of all VLAN tags (including those
444 not present in the filter(s)).
445
446 Bridged switch ports
447 ^^^^^^^^^^^^^^^^^^^^
448
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
452 configuration knobs below, the expected behavior is documented.
453
454 Bridge VLAN filtering
455 ^^^^^^^^^^^^^^^^^^^^^
456
457 The Linux bridge allows the configuration of a VLAN filtering mode (statically,
458 at device creation time, and dynamically, during run time) which must be
459 observed by the underlying switchdev network device/hardware:
460
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.
463 The bridge VLAN database can still be modified, but the modifications should
464 have no effect while VLAN filtering is turned off. Frames ingressing the
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).
467
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
470 table must be dropped (strict VID checking).
471
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
474 network stack must be preserved, or the configuration must be refused if that
475 is not possible.
476
477 - with VLAN filtering turned off, the bridge will process all ingress traffic
478 for the port, except for the traffic tagged with a VLAN ID destined for a
479 VLAN upper. The VLAN upper interface (which consumes the VLAN tag) can even
480 be added to a second bridge, which includes other switch ports or software
481 interfaces. Some approaches to ensure that the forwarding domain for traffic
482 belonging to the VLAN upper interfaces are managed properly:
483
484 * If forwarding destinations can be managed per VLAN, the hardware could be
485 configured to map all traffic, except the packets tagged with a VID
486 belonging to a VLAN upper interface, to an internal VID corresponding to
487 untagged packets. This internal VID spans all ports of the VLAN-unaware
488 bridge. The VID corresponding to the VLAN upper interface spans the
489 physical port of that VLAN interface, as well as the other ports that
490 might be bridged with it.
491 * Treat bridge ports with VLAN upper interfaces as standalone, and let
492 forwarding be handled in the software data path.
493
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
496 bridge port. These VLAN devices cannot be enslaved into the bridge since they
497 duplicate functionality/use case with the bridge's VLAN data path processing.
498
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
501 filtering setting is global to the entire chip, then the standalone ports
502 should indicate to the network stack that VLAN filtering is required by setting
503 'rx-vlan-filter: on [fixed]' in the ethtool features.
504
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
507 toggling of that option and behave appropriately. If that is not possible, the
508 switchdev driver can also refuse to support dynamic toggling of the VLAN
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
511 ensure VLAN awareness is pushed down to the hardware.
512
513 Even when VLAN filtering in the bridge is turned off, the underlying switch
514 hardware and driver may still configure itself in a VLAN-aware mode provided
515 that the behavior described above is observed.
516
517 The VLAN protocol of the bridge plays a role in deciding whether a packet is
518 treated as tagged or not: a bridge using the 802.1ad protocol must treat both
519 VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as
520 untagged.
521
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
524 VID 0 in its database.
525
526 When the bridge has VLAN filtering enabled and a PVID is not configured on the
527 ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge
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
530 bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering
531 disabled, the presence/lack of a PVID should not influence the packet
532 forwarding decision.
533
534 Bridge IGMP snooping
535 ^^^^^^^^^^^^^^^^^^^^
536
537 The Linux bridge allows the configuration of IGMP snooping (statically, at
538 interface creation time, or dynamically, during runtime) which must be observed
539 by the underlying switchdev network device/hardware in the following way:
540
541 - when IGMP snooping is turned off, multicast traffic must be flooded to all
542 ports within the same bridge that have mcast_flood=true. The CPU/management
543 port should ideally not be flooded (unless the ingress interface has
544 IFF_ALLMULTI or IFF_PROMISC) and continue to learn multicast traffic through
545 the network stack notifications. If the hardware is not capable of doing that
546 then the CPU/management port must also be flooded and multicast filtering
547 happens in software.
548
549 - when IGMP snooping is turned on, multicast traffic must selectively flow
550 to the appropriate network ports (including CPU/management port). Flooding of
551 unknown multicast should be only towards the ports connected to a multicast
552 router (the local device may also act as a multicast router).
553
554 The switch must adhere to RFC 4541 and flood multicast traffic accordingly
555 since that is what the Linux bridge implementation does.
556
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
559 toggling of that option and behave appropriately.
560
561 A switchdev driver can also refuse to support dynamic toggling of the multicast
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
564 value.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.