Lines Matching refs:the
8 model for switch devices which offload the forwarding (data) plane from the
11 Figure 1 is a block diagram showing the components of the switchdev model for
74 On switchdev driver initialization, the driver will allocate and register a
76 port, called the port netdev. A port netdev is the software representation of
77 the physical port and provides a conduit for control traffic to/from the
78 controller (the kernel) and the network, as well as an anchor point for higher
80 standard netdev tools (iproute2, ethtool, etc), the port netdev can also
81 provide to the user access to the physical properties of the switch port such
84 There is (currently) no higher-level kernel object for the switch beyond the
85 port netdevs. All of the switchdev driver ops are netdev ops or switchdev ops.
87 A switch management port is outside the scope of the switchdev driver model.
88 Typically, the management port is not participating in offloaded data plane and
89 is loaded with a different driver, such as a NIC driver, on the management port
96 of the port as a key, for example the port MAC address or the port PHYS name.
97 Hard-coding of kernel netdev names within the driver is discouraged; let the
98 kernel pick the default netdev name, and let udev set the final name based on a
101 Using port PHYS name (ndo_get_phys_port_name) for the key is particularly
102 useful for dynamically-named ports where the device names its ports based on
104 into 4 10G ports, resulting in 4 port netdevs, the device can give a unique
110 Suggested naming convention is "swXpYsZ", where X is the switch name or ID, Y
111 is the port name or ID, and Z is the sub-port name or ID. For example, sw1p1s0
117 The switchdev driver must implement the switchdev op switchdev_port_attr_get
118 for SWITCHDEV_ATTR_ID_PORT_PARENT_ID for each port netdev, returning the same
120 on the same system. The ID does not need to be unique between switches on
124 ports belong to the same switch.
131 If the switchdev driver (and device) only supports offloading of the default
132 network namespace (netns), the driver should set this feature flag to prevent
133 the port netdev from being moved out of the default netns. A netns-aware
141 The port netdevs representing the physical switch ports can be organized into
147 tools such as the bridge driver, the bonding/team drivers, and netlink-based
150 The switchdev driver can know a particular port's position in the topology by
153 the bond's upper master will change. And so on. The driver will track such
154 movements to know what position a port is in in the overall topology by
160 The idea is to offload the L2 data forwarding (switching) path from the kernel
161 to the switchdev device by mirroring bridge FDB entries down to the device. An
162 FDB entry is the {port, MAC, VLAN} tuple forwarding destination.
164 To offloading L2 bridging, the switchdev driver/device should support:
168 - STP state changes on the port
175 to support static FDB entries installed to the device. Static bridge FDB
180 The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx
187 Note: by default, the bridge does not filter on VLAN and only bridges untagged
196 and notify the switch driver of the mac/vlan/port tuples. The switch driver,
197 in turn, will notify the bridge driver using the switchdev notifier call:
203 SWITCHDEV_FDB_ADD, the bridge driver will install the FDB entry into the
204 bridge's FDB and mark the entry as NTF_EXT_LEARNED. The iproute2 bridge
222 Learning on the port should be disabled on the bridge using the bridge command:
226 Learning on the device port should be enabled, as well as learning_sync:
231 Learning_sync attribute enables syncing of the learned/forgotton FDB entry to
232 the bridge's FDB. It's possible, but not optimal, to enable learning on the
233 device port and on the bridge port, and disable learning_sync.
235 To support learning and learning_sync port attributes, the driver implements
237 SWITCHDEV_ATTR_PORT_ID_BRIDGE_FLAGS. The driver should initialize the attributes
238 to the hardware defaults.
244 the responsibility of the port driver/device to age out these entries. If the
245 port device supports ageing, when the FDB entry expires, it will notify the
246 driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the
247 device does not support ageing, the driver can simulate ageing using a
249 notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for
252 To keep an NTF_EXT_LEARNED entry "alive", the driver should refresh the FDB
254 notification will reset the FDB entry's last-used time to now. The driver
256 second. (The last-used time is visible using the bridge -s fdb option).
261 Internally or with a third-party STP protocol implementation (e.g. mstpd), the
262 bridge driver maintains the STP state for ports, and will notify the switch
263 driver of STP state change on a port using the switchdev op
267 update ingress packet filter list for the port. For example, if port is
271 Note that STP BDPUs are untagged and STP state applies to all VLANs on the port
273 VLANs on the port.
278 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
281 vlan L2 domain, can program the switch device for flooding. The packet may
282 be sent to the port netdev for processing by the bridge driver. The
283 bridge should not reflood the packet to the same ports the device flooded,
284 otherwise there will be duplicate packets on the wire.
286 To avoid duplicate packets, the device/driver should mark a packet as already
287 forwarded using skb->offload_fwd_mark. The same mark is set on the device
288 ports in the domain using dev->offload_fwd_mark. If the skb->offload_fwd_mark
289 is non-zero and matches the forwarding egress port's dev->skb_mark, the kernel
290 will drop the skb right before transmit on the egress port, with the
291 understanding that the device already forwarded the packet on same egress port.
293 for port's dev->offload_fwd_mark, based on the port's parent ID (switch ID) and
296 It is possible for the switch device to not handle flooding and push the
297 packets up to the bridge driver for flooding. This is not ideal as the number
298 of ports scale in the L2 domain as the device is much more efficient at
301 If supported by the device, flood control can be offloaded to it, preventing
314 the kernel, with the device doing the FIB lookup and forwarding. The device
316 forwards the packet to the matching FIB entry's nexthop(s) egress ports.
318 To program the device, the driver implements support for
320 switchdev_port_obj_add is used for both adding a new FIB entry to the device,
321 or modifying an existing entry on the device.
338 structure holds details on the route and route's nexthops. *dev is one of the
339 port netdevs mentioned in the routes next hop list. If the output port netdevs
340 referenced in the route's nexthop list don't all have the same switch ID, the
341 driver is not called to add/modify/delete the FIB entry.
343 Routes offloaded to the device are labeled with "offload" in the ip route
364 The FIB entry's nexthop list contains the nexthop tuple (gateway, dev), but for
365 the switch device to forward the packet with the correct dst mac address, the
366 nexthop gateways must be resolved to the neighbor's mac address. Neighbor mac
367 address discovery comes via the ARP (or ND) process and is available via the
368 arp_tbl neighbor table. To resolve the routes nexthop gateways, the driver
369 should trigger the kernel's neighbor resolution process. See the rocker
372 The driver can monitor for updates to arp_tbl using the netevent notifier
374 for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy
375 to know when arp_tbl neighbor entries are purged from the port.
382 memory allocation, etc. The goal is to handle the stuff that is not unlikely
383 to fail here. The second phase is to "commit" the actual changes.
386 allocations) between the two phases.
390 During the "commit" phase, the driver gets the object by:
394 cleanup of the queued-up objects.