Technical Details: eSwitch Switchdev Mode

In switchdev mode, the 800 Series Controller’s PF driver supports a standard Linux kernel abstraction layer (switchdev API) to expose the control plane of the Ethernet controller's eSwitch to the software vSwitch (OVS/Linux Bridge). This switchdev API was originally developed in the Linux Kernels to configure switch hardware ASICs. The switchdev API enables limited vSwitch functionality offload to the Ethernet controller's eSwitch to allow hardware switch assist for OVS/Linux Bridge.

As detailed in Technical Details: eSwitch Legacy Mode, in Legacy mode (without switchdev), only MAC/VLAN are configured and used in VEB (eSwitch) for hardware switching. Based on policies configured by the host admin or SDN controller, flows are configured in the software switch (vSwitch) through a slow path mechanism. Flows, in this case, refer to (filter-match)/action tables for different filter/classifier (L2/L3 and L4 fields). To make use of hardware switching capabilities for vSwitch, it is required for the eSwitch to have the same flows as the vSwitch.

When the PF's eSwitch mode is set as switchdev, Port Representor netdevs are created for the PF and each VF associated to that eSwitch. The PF netdev is replaced by an UpLink Port Representor (UL_​PR) netdev and a VF Port Representor (VF_​PR) netdev is created for each VF. PRs are similar to hardware accelerated networking ports and function like standard Linux network interfaces. The PF_​VSI backs up the PF (UL_​PR) netdev, creates a new Control Plane VSI (CP_​VSI), and backs up all the VF_​PR netdevs. UL_​PR can be used for two-way communication ports with VFs. VF_​PRs are used for control plane communications through the OVS control plane.

These PRs enable exposing statistics as well as configuring and monitoring link state, MTU, filters, FDB/VLAN entries, and so on. These PRs plug into existing kernel software switching subsystems (such as TC and OVS) and allow offload of software traffic rules (flows) to the Ethernet controller (hardware).

To offload a data forwarding path (software vSwitch flows) from the kernel to Ethernet controller hardware (eSwitch), the bridge Forwarding Database (FDB) entries are mirrored down to the Ethernet controller. By default, the hardware FDB has entries for {MAC, VLAN, PORT} tuples.

With switchdev mode, the 800 Series Ethernet Network Controller PF driver also supports the other switch rule programming that can be used for hardware switching. For more information on supported switch rule programming, please refer to Switchdev Mode TC-Flower Hardware Offloads.

For example, when a route is added in OVS, a function calls the Intel ice driver, which then determines whether this route needs to be offloaded to the hardware. Routes that do not involve the eSwitch are typically not offloaded.

The following provides a summary on Port Representor capabilities:

• Netdevs for all switching ports created on an eSwitch in switchdev mode:
  • Uplink ports (UL_​PR)
  • Virtual ports (VF_​PR)
• PR reflects the originating item's link state.
• PR should not be used to control Receive Side Scaling (RSS) input set or Intel® Ethernet Flow Director (Intel® Ethernet FD) settings for the VF.
• PR supports default/exception paths.
• When packets are sent from the PR netdev, they are sourced routed directly to the port.
• Scope is limited to a single Uplink port in one switching domain/switchdev instance.

VF Port Representor:

Each VF must have a unique Port Representor. Intel recommends that you use the corresponding VF_​PRs for any VF-related configuration.

For example, if you want to limit a VF's interrupt rate for Rx and Tx (Bounding interrupt rates using rx-usecs-high), you apply the command using the VF_​PR, as shown here:

The following figure shows the configuration of a single port in switchdev mode.