Lines Matching +full:network +full:- +full:on +full:- +full:chip
1 .. SPDX-License-Identifier: GPL-2.0
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 +--------------+-------------------------------+
32 | Network stack |
35 +----------------------------------------------+
41 +--+----+----+----+----+----+---+ +-----+-----+
45 +--------------+----------------+ +-----------+
48 +-------------------------------------------------------------------+
50 +--------------+----------------+
52 | +----+ +--------+
55 +--|----|----+----+----+----+---+
60 front-panel ports
67 -------------
76 -------------
83 ------------
85 On switchdev driver initialization, the driver will allocate and register a
89 controller (the kernel) and the network, as well as an anchor point for higher
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
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
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
143 network namespace (netns), the driver should set this private flag to prevent
144 the port netdev from being moved out of the default netns. A netns-aware
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 ---------------------
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
213 discouraged: all static FDB entries should be added on a bridge port using the
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.
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.
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
336 The bridge multicast module will notify port netdevs on every multicast group
342 ------------------
346 does a longest prefix match (LPM) on FIB entries matching route prefix and
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
414 -------------------------------
416 Below is a set of defined behavior that switchdev enabled network devices must
419 Configuration-less state
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
427 use per-port VLAN identifiers unless a better mechanism is available
428 (proprietary metadata for each network port for instance).
430 The network device must be capable of running a full IP protocol stack
434 when IGMP snooping is enabled for IP multicast over these switchdev network
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.
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
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.
468 - with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing
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
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
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.
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
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
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
545 the network stack notifications. If the hardware is not capable of doing that
549 - when IGMP snooping is turned on, multicast traffic must selectively flow
550 to the appropriate network ports (including CPU/management port). Flooding of
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