HARDWARE-ACCELERATED PBR (POLICY-BASED ROUTING) OVER SFC (SERVICE FUNCTION CHAINING)

Abstract

Technologies for creating an optimized and accelerated network pipeline using a Network Pipeline Abstraction Layer (NPAL) for Policy-Based Routing (PBR) over Service Function Chaining (SFC) are described. A Data Processing Unit (DPU) includes an acceleration hardware engine to provide a single, accelerated data layer. A processing device can create a first virtual bridge and a second virtual bridge. The first virtual bridge is controlled by a first network service hosted on the DPU and has a set of one or more network rules, while the second virtual bridge has a Policy-Based Routing (PBR) policy. The processing device can add the virtual port between the first and second virtual bridges.The acceleration hardware engine, located in the single accelerated data layer, can route network traffic data based on the PBR policy and process the network traffic data based on the set of one or more network rules.

Description

RELATED REGISTRATIONS

[0001] The present application is a partial continuation of US patent application No. 18 / 649,319, filed on April 29, 2024, the entire contents of which are incorporated by reference. The present application relates to the jointly assigned US patent application No. 18 / 649,295, filed on April 29, 2024, US patent application No. 18 / 649,334, filed on April 29, 2024, US patent application No. 18 / 928,778, entitled “Network Pipeline Abstraction Layer (NAPL) Split Interfaces”, US patent application No. 18 / 928,781, entitled “Network Pipeline Abstraction Layer (NAPL) Fast Link Recovery”, and US patent application No. 18 / 928,772, entitled “Network Pipeline Abstraction Layer (NAPL) Emulation”. TECHNICAL AREA

[0002] At least one embodiment relates to processing resources used to perform and facilitate operations for providing hardware-accelerated policy-based routing (PBR) over service function chaining (SFC) architectures. For example, at least one embodiment relates to processors or computing systems used to provision and enable virtual bridges, one of which manages routing according to a PBR policy and another of which manages various network service rules for an acceleration hardware engine to route network traffic data according to the PBR policy and process network traffic data in a single accelerated data plane based on the network rules, according to various novel techniques described herein. BACKGROUND

[0003] In traditional network architectures, various security and performance functions were managed by specialized hardware devices known as middleboxes, each performing distinct tasks. Firewalls, as standalone physical devices, served as the primary defense mechanism at the network edge, inspecting incoming and outgoing traffic against predefined rules to block or allow data transfer and thus protect the internal network from external threats. Load balancers, operating as separate hardware units, intelligently distributed incoming network and application traffic across multiple servers to prevent congestion and ensure efficient resource utilization, thereby improving application availability and performance.Intrusion Detection Systems (IDS) were strategically positioned within the network and served to monitor and analyze network traffic for signs of anomalies, attacks, or violations of security policies. They functioned as a security component for identifying potential security breaches.

[0004] In addition, networks utilized further middlebox functions such as data loss prevention (DLP) systems to monitor and prevent unauthorized data exfiltration, virtual private network (VPN) gateways to establish secure and encrypted connections between networks, and wide area network (WAN) optimization devices to improve data transmission efficiency across wide area networks. These middleboxes were essential but also presented challenges: they required significant investment, occupied valuable data center space, and demanded specialized personnel for operation and maintenance. Scaling these network functions often meant acquiring and integrating additional physical equipment, increasing the complexity and cost of the network infrastructure. SUMMARY

[0005] The invention is defined by the claims. To illustrate the invention, aspects and embodiments are described herein that may or may not fall within the scope of the claims.

[0006] Technologies for creating an optimized and accelerated network pipeline using a Network Pipeline Abstraction Layer (NPAL) for Policy-Based Routing (PBR) over Service Function Chaining (SFC) are described. A Data Processing Unit (DPU) includes an acceleration hardware engine to provide a single, accelerated data layer. A processing device can create a first virtual bridge and a second virtual bridge. The first virtual bridge is controlled by a first network service hosted on the DPU and has a set of one or more network rules, while the second virtual bridge has a Policy-Based Routing (PBR) policy. The processing device can add the virtual port between the first and second virtual bridges.The acceleration hardware engine, located in the single accelerated data layer, can route network traffic data based on the PBR policy and process the network traffic data based on the set of one or more network rules.

[0007] Each feature of an aspect or embodiment can be applied to other aspects or embodiments in any suitable combination. In particular, each feature of a process aspect or embodiment can be applied to a device aspect or embodiment, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Various embodiments according to the present disclosure are described with reference to the drawings. These show: Fig. 1 a block diagram of an integrated circuit with SFC (Service Function Chaining) logic for generating virtual bridges and interface mappings in an SFC architecture according to at least one embodiment; Fig. 2 a block diagram of an exemplary DPU-based SFC (Service Function Chaining) infrastructure for providing an SFC architecture according to at least one embodiment; Fig. 3 a block diagram of an SFC architecture with a first virtual bridge, a second virtual bridge, a virtual port and a network service according to at least one embodiment; Fig. 4 a block diagram of an SFC architecture with a first virtual bridge, a second virtual bridge, a virtual port and a network service according to at least one embodiment; Fig. 5 a block diagram of a non-SFC architecture with a first virtual bridge and a network service according to at least one embodiment; Fig. 6 a flowchart of an exemplary procedure for configuring an SFC architecture with multiple virtual bridges and interface mappings according to at least one embodiment; Fig. 7 a block diagram of an exemplary DPU-based SFC infrastructure for providing hardware-accelerated rules for an SFC architecture 220 according to at least one embodiment; Fig. 8 a block diagram of an SFC architecture with flexible hardware-accelerated rules for a single accelerated data plane according to at least one embodiment; Fig. 9 a block diagram of an SFC architecture with flexible hardware-accelerated rules for a single accelerated data plane according to at least one embodiment; Fig. 10 a flowchart of an exemplary procedure for configuring an SFC architecture with flexible hardware-accelerated rules for acceleration on a single accelerated data plane of a DPU according to at least one embodiment; Fig. 11 a block diagram of an exemplary computing system with a DPU with an NPAL (Network Pipeline Abstraction Layer) for providing an optimized and accelerated network pipeline, which is to be accelerated by an acceleration hardware engine according to at least one embodiment; Fig. 12 a network diagram of an exemplary network pipeline that is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment; Fig. 13 a network diagram of an exemplary network pipeline that is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment; Fig. 14 a network diagram of an exemplary network pipeline that is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment; Fig. 15 a flowchart of an exemplary procedure for generating an optimized and accelerated network pipeline using an NPAL (Network Pipeline Abstraction Layer) according to at least one embodiment; Fig. 16 a block diagram of a software stack of a DPU with an NPAL that supports shared interfaces according to at least one embodiment; Fig. 17 a network diagram of an exemplary network pipeline that is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL that supports shared interfaces according to at least one embodiment; Fig. 18 a flowchart of a method for operating a DPU with shared interfaces according to at least one embodiment; Fig. 19 a block diagram of a software stack of a DPU with an NPAL that supports fast link recovery according to at least one embodiment; Fig. 20 a network diagram of an exemplary network pipeline that is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL that supports fast link recovery according to at least one embodiment; Fig. 21 Flowcharts of ECMP (Equal-Cost Multi-Path) operations before a link failure, after a link failure and after a link restoration according to at least one embodiment; Fig. 22 a flowchart of a method for operating a DPU with fast link recovery according to at least one embodiment; Fig. 23 a block diagram of an SFC architecture with a PBR policy according to at least one embodiment; Fig. 24 a flowchart of a method for operating a DPU that supports PBR via an SFC architecture according to at least one embodiment; Fig. 25 a block diagram of an emulated network pipeline on an emulated acceleration hardware engine of an emulated DPU with an emulated NPAL according to at least one embodiment; Fig. 26 a block diagram of an emulated SFC architecture 2600 with an emulated host device and an emulated DPU according to at least one embodiment; Fig. 27 a flowchart of a method for operating an emulated DPU according to at least one embodiment; Fig. 28 a block diagram of a computing system with two interconnected processing devices and multiple networks according to at least one embodiment; Fig. 29 a block diagram of a computing system comprising a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit) in a single integrated circuit according to at least one embodiment; Fig. 30 a block diagram of a computing system with Tensor Core GPUs (Graphics Processing Units) according to at least one embodiment. DETAILED DESCRIPTION

[0009] This paper describes technologies for providing hardware-accelerated flexible control rules over SFC (Service Function Chaining) architectures. It also describes technologies for optimizing network acceleration using a NAPL (Network Pipeline Abstraction Layer). Furthermore, it describes technologies for providing configurable and dynamic SFC interfaces on a DPU (Data Processing Unit). DPUs are explained in more detail below. Additionally, it describes technologies for providing shared NAPL interfaces, as well as technologies for providing fast NAPL link recovery. Finally, it describes technologies for hardware-accelerated PBR (Policy-Based Routing) over SFC architectures and technologies for NAPL emulation.

[0010] As described above, in traditional network architectures, various security and performance functions were managed by specialized hardware devices known as middleboxes (e.g., firewalls, load balancers, IDS, etc.). Traditional networks were designed under the assumption that all resources reside in an on-premises data center and often feature a centralized model.

[0011] Modern networks are increasingly cloud-centric and designed to support cloud services and applications. This includes the use of public, private, and hybrid cloud infrastructures, which require more flexible and scalable networks. Unlike traditional network architectures that relied heavily on physical hardware (i.e., each network function required its own dedicated device), current network architectures leverage virtualization technologies such as SDN (Software-Defined Networking) and NFV (Network Function Virtualization). These technologies abstract network resources from hardware, providing greater flexibility, easier management, and lower costs. Modern networks increasingly utilize automation and orchestration tools to efficiently manage network resources, reduce operational overhead, and enable faster deployment of network services.Modern networks are designed for scalability and high performance, leveraging technologies like edge computing to process data closer to the source and reduce latency. Current network architectures are more flexible, scalable, and efficient than traditional architectures and are designed to support the dynamic and distributed nature of modern computing resources and work practices. They integrate advanced technologies such as cloud services, virtualization, and automation to meet the demands of today's digital environment. SFC (Service Function Chaining) Architectures

[0012] A networking concept and architecture used in SDN and NFV environments is Service Function Chaining (SFC). SFC can be used to define and orchestrate a sequence of network services across a series of interconnected network nodes. SFC aims to virtualize network services (such as firewalls, load balancers, IDS, and other middlebox functions) and define the order in which network traffic data passes through them to achieve specific processing or handling. Each network service is represented as a Service Function (SF). These SFs can be implemented as virtualized software instances running on a physical or virtual infrastructure. A Service Chain defines the sequence of SFs through which network traffic data passes.A service function chain, for example, might specify that network traffic data first passes through a firewall, then a load balancer, and finally an intrusion detection system (IDS), using service function paths (SFPs) and service function forwarders (SFFs). An SFP refers to the defined sequence of scalable functions (SFs) through which network traffic data is routed in a specific order. An SFP is a logical representation of the path network traffic data takes through the network, passing through various service functions such as firewalls, load balancers, IDSs, and so on. The SFP determines the traffic flow and ensures that it is routed through each designated service function in the correct sequence. SFPs can be used for the flexible and dynamic implementation of policy-based routing and network services.The SFF is a component within the SFC architecture responsible for the actual routing of network traffic data to the designated service functions specified by the SFP. The SFF acts as a router or switch, directing traffic between different service functions and ensuring that network traffic data follows the prescribed path defined by the SFP. Based on the SFC encapsulation information and the SFP, the SFF decides where to send the network traffic data next. It handles routing and forwarding between service functions and performs the encapsulation and decapsulation of traffic necessary for SFC operation. For example, when a packet enters a network, it is classified based on its attributes (such as source / destination IP (Internet Protocol) addresses, protocols, ports, etc.), and the appropriate SFP is selected to determine the path through the correct service functions.The packet is then routed along the SFP by SFFs.

[0013] Service Function Chaining offers several advantages, including increased flexibility, scalability, and agility in the deployment and management of network services. It enables the dynamic generation of service chains based on application requirements, traffic conditions, or policy changes, resulting in more efficient and adaptable network service delivery.

[0014] Current solutions in SFC architectures do not support the creation and use of flexible control rules in a single accelerated data plane on a DPU. Current solutions in SFC architectures do not support configurable and dynamic interface mappings on the DPU. Current solutions do not always support the acceleration of all operations in an SFC architecture.

[0015] Aspects and embodiments of the present disclosure address these and other problems by providing technologies for delivering hardware-accelerated flexible control rules via SFC architectures of a DPU, for delivering configurable and dynamic SFC interfaces on a DPU, and / or for optimizing network acceleration using a network pipeline abstraction layer, as further described below. Aspects and embodiments of the present disclosure can provide virtual bridges with different control rules for an acceleration hardware engine and enable the processing of network traffic data in a single accelerated data plane using a combined set of network rules from different control rules of different virtual bridges.Aspects and embodiments of the present disclosure can provide and enable a Network Pipeline Abstraction Layer (NPAL) that supports multiple network protocols and network functions in a network pipeline, wherein the pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine. Aspects and embodiments of the present disclosure can provide and enable a first virtual bridge, a second virtual bridge, and a virtual port between the first and second virtual bridges, wherein the first virtual bridge is controlled by a first network service hosted on the DPU, and the second virtual bridge is controlled by user-defined logic.Aspects and embodiments of the present disclosure can provide and enable an NPAL that supports shared interfaces. Aspects and embodiments of the present disclosure can provide and enable an NPAL that supports fast link recovery. Aspects and embodiments of the present disclosure can provide and enable a first virtual bridge, a second virtual bridge, and a virtual port between the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is controlled by a first network service hosted on the DPU, and the second virtual bridge is controlled by a policy-based routing (PBR) policy. DPUS (DATA PROCESSING UNITS)

[0016] In modern network architectures, a DPU can be used to provide a set of software-defined networking, storage, security, and management services at data center scale, with the ability to offload, accelerate, and isolate the data center infrastructure. The DPU can offload processing tasks typically handled by a server's CPU (Central Processing Unit), such as any combination of encryption / decryption, firewall, TCP / IP (Transport Control Protocol / Internet Protocol), HTTP (Hypertext Transport Protocol), and network operations. A DPU can be an integrated circuit or a SoC (System on a Chip), considered as data center infrastructure on a single chip. The CPU can comprise DPU hardware and DPU software (e.g., a software framework with acceleration libraries). The DPU hardware can be a CPU (e.g., a dedicated CPU, a dedicated processor, or a dedicated processor).a single-core or multi-core CPU), one or more hardware accelerators, memory, one or more physical host interfaces operationally coupled to one or more host devices (e.g., a CPU of a host device), and one or more physical network interfaces operationally coupled to a network (e.g., a public network (e.g., the Internet), a private network (e.g., a LAN (Local Area Network) or a WAN (Wide Area Network)), a wired network (e.g., an Ethernet network), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., an LTE (Long Term Evolution) network), routers, hubs, switches, server computers, network adapters, NVLink switches, and / or a combination thereof).The DPU can handle network data path processing of network traffic data, while a host device can control path initialization and exception handling. The acceleration hardware engine (e.g., DPU hardware) can be used to offload and filter network traffic based on predefined filters using the hardware functions of the acceleration hardware engine. The software framework and acceleration libraries can include one or more hardware-accelerated services, such as a hardware-accelerated service (e.g., NVIDIA DOCA), hardware-accelerated virtualization services, hardware-accelerated networking services, hardware-accelerated storage services, hardware-accelerated AI / ML (Artificial Intelligence / Machine Learning) services, hardware-accelerated services, and hardware-accelerated management services.

[0017] A DPU can provide accelerated network services (also known as HBN – Host Based Network) services to one or more host devices. These DPU network services can be used to accelerate L2 (Layer 2) protocols, L3 (Layer 3) protocols, tunneling protocols, or similar technologies on the DPU hardware. The HBN infrastructure is based on an SFC topology, where a single virtual bridge (e.g., an OVS (Open vSwitch) bridge) is controlled by the HBN service and provides all accelerated networking capabilities. The HBN service can support various protocols and networking capabilities, such as... B. ACLs (Access Control Lists), ECMP (Equal-Cost Multi-Path), Tunneling, CT (Connection Tracking), QoS (Quality of Service) rule, STP (Spanning Tree Protocol), VLAN (Virtual Local Area Network) mapping, NATs (Network Address Translations), SDN (Software-Defined Networking), MPLS (Multi-Protocol Label Switching), etc. Configurable and dynamic SFC interface mapping to DPU

[0018] Aspects and embodiments of the present disclosure can provide, in addition to a first virtual bridge controlled by an HBN service, a second virtual bridge that can be controlled by user-defined logic. The second virtual bridge can be programmable by a user, a customer, or a controller, such as an OVN (Open Virtual Network) controller. OVN is an open-source project that provides network virtualization for VMs (virtual machines) and container instances. OVN acts as an extension to OVS, a virtual switch primarily used to enable network automation in large network environments. OVN complements OVS by adding native support for virtual network abstractions such as virtual L2 and L3 overlays and security groups.Aspects and embodiments of the present disclosure can support configurable and dynamic interface mappings on the DPU based on SFC infrastructure. Configuration can be supported as part of the DPU operating system (OS) installation, as well as dynamically for DPUs in production. Configuration can be performed on deployed DPUs without reinstalling the DPU OS. The interface configuration in the configuration file can support various use cases for network acceleration on the DPU.

[0019] In at least one embodiment, the DPU includes memory for storing a configuration file that specifies multiple virtual bridges, such as the first and second virtual bridges described above. The configuration file also specifies interface mappings for the multiple virtual bridges. The DPU includes a processing unit that is operationally coupled to the memory. The processing unit creates a first virtual bridge and a second virtual bridge according to the configuration file. The first virtual bridge is controlled by a first network service hosted on the DPU, and the second virtual bridge is controlled by user-defined logic.The processing device adds one or more host interfaces to the second virtual bridge, adds a first service interface to the first virtual bridge to operationally couple it with the first network service, and adds one or more virtual ports between the first and second virtual bridges, all according to the configuration file. The second virtual bridge provides the user, client, or controller with the flexibility to define additional network functions, other than those performed by the first network service. In an implementation, a second network service encompasses the user-defined logic. The processing device adds a second service interface to the second virtual bridge for operational coupling with the second network service.Alternatively, the user-defined logic can be implemented in the second virtual bridge itself or in logic operationally coupled with the second virtual bridge. Hardware-accelerated flexible control rules of the DPU's SFC architecture

[0020] Aspects and embodiments of the present disclosure can provide a second virtual bridge to allow a user, customer, or controller to specify flexible control rules via the SFC architecture of a DPU. Using an SFC on the DPU, a user (or controller) can create flexible and dynamic network control rules that are accelerated by the DPU hardware as a single data layer on the DPU. In particular, the user-defined rules can be accelerated with the existing network rules in the HBN service in a single accelerated data layer, as described in more detail herein. The user (or controller) can flexibly program different control rules via the SFC in parallel with the HBN service, resulting in a single accelerated data layer through the DPU hardware and software.The hardware-accelerated service of the DPU can include an OVS infrastructure based on the open-source OVS with additional features and new acceleration capabilities. For example, the hardware-accelerated service can include OVS-DOCA technology, developed by Nvidia Corporation of Santa Clara, California. OVS-DOCA, an OVS infrastructure for DPUs, is based on the open-source OVS with additional features, new acceleration capabilities, and a purely DOCA-based OVS backend. The hardware-accelerated service can also support OVS kernel and OVS-DPDK, which are the standard modes. All three operating modes utilize flow offloads for hardware acceleration, but due to its architecture and use of DOCA libraries, the OVS-DOCA mode offers the most efficient performance and the broadest feature set.The OVS DOCA mode can leverage the DOCA Flow library to configure and utilize hardware offload mechanisms and application techniques to generate a combined set of network rules. This set is then used by the acceleration hardware engine to process network traffic data into a single accelerated data plane. By defining an SFC infrastructure in a configuration file, users and customers can utilize the DPU as a network accelerator on an edge device, eliminating the need for complex and intelligent switches across various network topologies in DC (Data Center) and SP (Service Provider) networks.

[0021] In at least one embodiment, the DPU includes an acceleration hardware engine to provide a single accelerated data plane. The DPU includes memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first and second virtual bridges. A processing device of the DPU is operationally coupled to the memory and the acceleration hardware engine. The processing device creates the first and second virtual bridges according to the configuration file. The first virtual bridge is controlled by a first network service hosted on the DPU and has a first set of one or more network rules. The second virtual bridge has a second set of one or more user-defined network rules.The processing device adds the virtual port between the first virtual bridge and the second virtual bridge according to the configuration file. The processing device generates a combined set of network rules based on the first set of one or more network rules and the second set of one or more user-defined network rules. The acceleration hardware engine can then process network traffic data in the single accelerated data plane using this combined set of network rules. NPAL (Network Pipeline Abstraction Layer) optimized pipeline for network acceleration

[0022] Aspects and embodiments of the present disclosure can provide NPAL, a software-programmable layer to provide an optimized network pipeline that supports various accelerated network functions, such as L2 bridging, L3 routing, tunnel encapsulation, tunnel decapsulation, hash computations, ECMP operations, static and dynamic ACLs, CT, etc. That is, the NPAL is an accelerated programmable network pipeline that provides an abstraction of the underlying functionality of a network pipeline optimized for hardware acceleration on the DPU hardware. The NPAL can be a DAL (Database Abstraction Layer) or similar to one.Database-as-a-Load (DAL) is a programming concept used in software engineering to provide an abstraction over the underlying database systems, allowing applications to interact directly with various databases, low-level software layers, or hardware without requiring changes to the application code. A DAL typically comprises a set of APIs (Application Programming Interfaces) or classes that provide a unified interface for performing common database operations such as querying, inserting, updating, and deleting data. By using a DAL, developers can write database-independent code, thereby reducing the coupling between the application and the specific database implementation.Similarly, the NPAL can comprise a set of APIs or classes that provide a unified interface for executing common network operations in a network pipeline optimized for hardware acceleration on the DPU hardware. Specifically, the NPAL can provide a unified interface to one or more applications, network services, or the like running on the DPU or host device. The NPAL can provide an optimized network pipeline that supports multiple network protocols and functionalities. The network pipeline can comprise a set of tables and logic in a specific order, optimized for acceleration by the DPU hardware, and deliver a rich set of features and high performance to customers and users.

[0023] Using an NPAL in the DPU can offer several advantages, including operational independence, logic encapsulation, performance, code reusability, platform independence, and the like. For example, developers can write agnostic code, allowing applications (such as network services) with different underlying access logic and network functionality to operate. The NPAL can encapsulate the access or network-related logic, simplifying the management and maintenance of the codebase systems. Changes to the schema or underlying technology can be isolated within the NPAL implementation. The NPAL can provide an optimized and high-performance pipeline to meet diverse networking requirements and functionalities.By separating access logic from application logic, developers can reuse NPAL components across multiple parts of the application (network service), promoting code reusability and maintainability. NPAL can abstract away platform-specific differences, data types, and other access- or network-function-related characteristics, allowing the application (network service) to run seamlessly on different platforms and in different environments. Overall, NPAL can be a powerful tool for building flexible, scalable, and maintainable network-function-driven applications, providing a level of abstraction that simplifies interactions between network functions and promotes code efficiency and portability.

[0024] In at least one embodiment, the DPU comprises DPU hardware, including a processing device and an acceleration hardware engine. The DPU includes a memory that is operationally coupled to the DPU hardware. The memory can store DPU software, including an NPAL that supports multiple network protocols and network functions in a network pipeline. The network pipeline comprises a set of tables and logic organized in a specific sequence to be accelerated by the acceleration hardware engine. The acceleration hardware engine can process network traffic data using the network pipeline. The network pipeline can be optimized for network services running on the DPU. OVS and OVS bridges

[0025] OVS (Open vSwitch) is a multi-tiered, open-source virtual switch used to manage network traffic in virtualized environments, particularly in data centers and cloud computing platforms. OVS provides network connectivity between virtual machines (VMs), containers, and physical devices. It is widely used in virtualization and cloud technologies and is a typical component of many software-defined networking (SDN) and network virtualization solutions.

[0026] A virtual switch, commonly found in virtualized computing environments, is a software application that allows virtual machines (VMs) on a single physical host to communicate with each other and with the external network. The virtual switch can provide network connectivity between VMs, containers, and physical devices. It can emulate the functionality of a physical network switch but operates at the software level within a hypervisor or host operating system. The virtual switch can manage network traffic and route data packets between VMs on the same host or between VMs and the physical network via ports. These ports can be configured for various policies, such as security settings, quality of service (QoS) rules, and more. The virtual switch can segment network traffic to ensure isolation between different virtual networks.The virtual switch can provide an interface between the virtualized environment and the physical network, allowing VMs to communicate outside their host. The virtual switch can support standard network protocols and features, such as VLAN (Virtual Local Area Network) tagging, Layer 2 forwarding, Layer 3 capabilities, and the like. OVS can support the OpenFlow protocol, enabling the virtual switch to be controlled by a network controller to make decisions about how traffic is routed across the network. A network controller, such as an SDN (Software-Defined Networking) controller, is a centralized entity that manages data flow control to network devices. It is the "brain" of the network, maintaining an overview of the entire network and making decisions about where packets should be sent.The OpenFlow (OF) protocol enables the controller to interact directly with the forwarding layer of network devices such as switches and routers, both physical and virtual. An OF configuration refers to setting up and managing network behavior using the OpenFlow protocol in an SDN environment. It defines flow rules and actions to control how network devices handle traffic, typically managed centrally by an SDN controller. An OF configuration can include flow tables that contain rules for handling packets. Each flow table contains a set of flow entries. The flow entry defines what should happen to packets that meet specific criteria. An entry can consist of three parts: matching fields, actions, and counters. The matching fields define packet attributes to be compared, such as...Source / destination IP (Internet Protocol) addresses, MAC (Media Access Control) addresses, port numbers, VLAN tags, etc. Actions can define what should happen to a matching packet, such as forwarding to a specific port, modifying fields within the packet, or discarding it. Counters can be used to track the number of packets and bytes for each flow. The network controller can use control messages to manage flow entries in the switches. It can add, update, or delete flow entries. Optional configurations can include group tables for advanced forwarding actions such as multicasting, load balancing, etc. It's worth noting that OVS is a type of virtual switch technology, but other virtual switch technologies exist, such as SDN-based switches.

[0027] An OVS bridge functions at the software level like a virtual network switch, allowing multiple network interfaces to be connected and managed as if they were ports on a physical switch. The OVS bridge enables the creation and management of virtual networks within a single server or across multiple servers in a data center or cloud environment. An OVS bridge connects virtual and physical network interfaces, facilitating communication between them. These interfaces can include those of VMs, containers, physical network interfaces, or even other virtual bridges. Similar to a physical Ethernet switch, an OVS bridge operates at Layer 2 of the Open Systems Interconnection model (also known as the OSI model), routing, filtering, and managing traffic based on MAC (Media Access Control) addresses.An OVS bridge can support advanced features such as VLAN (Virtual Local Area Network) tagging, QoS (Quality of Service), traffic mirroring, and ACLs (Access Control Lists). An OVS bridge can be controlled by a controller via protocols such as OF (OpenFlow), enabling dynamic and programmable network configurations.

[0028] Some aspects and embodiments of the present disclosure are described here in relation to OVS and include terminology specific to OVS and OpenFlow. However, some aspects and embodiments of the present disclosure can also be used in other virtual switching and bridging technologies. Likewise, various embodiments are described in connection with a DPU, but they can also be used in other virtual switching environments, including virtual bridges, switches, NICs (Network Interface Cards) (also referred to as Network Interface Controllers), intelligent NICs, network interface devices, network switches, network adapters, IPUs (Intelligence Processing Units), or other specialized computing devices designed to offload certain tasks from the CPU of a computer or server.

[0029] Data Processing Units (DPUs) are specialized semiconductor devices designed to offload and accelerate networking, security, and storage tasks traditionally performed on server CPUs. By taking over these functions, DPUs significantly improve the overall efficiency and performance of data centers. Equipped with their own processors and memory, they can handle complex data processing tasks independently of the host CPU. DPUs are embedded within the data center infrastructure, where they manage data movement and processing across networks, freeing up CPU resources that can then be used for application and workload processing. This architectural shift enables higher workload density, improved data throughput, and enhanced hardware-level security.Data processing units (DPUs) play a central role in software-defined networking (SDN), providing hardware acceleration for advanced functions such as encryption, traffic management, and virtualization. By optimizing these critical operations, DPUs contribute to the creation of more agile, secure, and efficient data centers.

[0030] Integrated Processing Units (IPUs) are specialized hardware accelerators designed to optimize the performance of machine learning algorithms and artificial intelligence (AI) workloads. Unlike general-purpose CPUs or GPUs (Graphics Processing Units), which are versatile but may not be optimized for AI tasks, IPUs are specifically designed to meet the high computational and data throughput demands of deep learning models and neural network processing. They achieve this by implementing highly parallel computing architectures and memory systems capable of efficiently handling the large volumes of data associated with AI applications. IPUs aim to reduce latency and increase the speed of AI calculations, enabling faster and more efficient training of more complex models.

[0031] Smart NICs are advanced network interface cards with integrated processing power to offload network tasks from the CPU, thereby improving the efficiency and performance of data processing within servers. Unlike traditional NICs, which primarily serve as data channels between servers and networks, Smart NICs can perform a wide range of network functions directly on the card, including traffic management, encryption / decryption, and network virtualization. These capabilities allow Smart NICs to significantly reduce CPU load and free up resources to improve the overall processing power of the server for application workloads.By handling complex network functions, Smart NICs can lead to lower latency and higher throughput in data center environments, making them particularly valuable for scenarios requiring real-time processing and high-speed networks, such as cloud computing, high-performance computing (HPC), and enterprise data centers. The intelligence and programmability of Smart NICs offer a flexible solution for the ever-evolving demands of modern network infrastructures, contributing to more efficient and adaptable network operations. Shared NPAL interfaces

[0032] As described above, NPAL is a high-performance, accelerated network pipeline for building flexible, scalable, and maintainable database-driven applications. It offers a level of abstraction that simplifies database interactions and promotes code efficiency and portability. Aspects and embodiments of this disclosure can provide an NPAL that supports hardware and software port splitting. Physical ports can be physically split into multiple ports, which requires advanced software support. Splitting a host's physical NIC port into multiple ports (also known as port splitting or physical NIC port breakout) involves dividing a single high-bandwidth physical NIC port into multiple lower-bandwidth logical or physical ports. This can be done at the physical level or via software configuration.There are several use cases and benefits for splitting physical NIC ports, especially in environments where network bandwidth and redundancy requirements vary.

[0033] One use case for splitting physical NIC ports includes bandwidth optimization and efficient resource utilization, network redundancy, and high availability. If a system has a high-speed NIC (e.g., 100 Gbps), many workloads or applications may not require the NIC's full bandwidth. In such cases, splitting a 100 Gbps port into, for example, four 25 Gbps ports allows the host to utilize the available bandwidth more efficiently. This is particularly useful when multiple applications or services have varying bandwidth requirements but do not need the full capacity of a single port.

[0034] Another use case and advantage of splitting physical NIC ports is network redundancy and high availability. Dividing a physical NIC port into multiple ports enables better redundancy and fault tolerance. With multiple physical links, an operator can configure active-active or active-backup redundancy strategies. This setup ensures that if one link fails, traffic can be rerouted through another, increasing reliability and availability.

[0035] Another use case and advantage of splitting physical NIC ports is improved network segmentation and isolation. By physically splitting a NIC port, different physical interfaces can be reserved for different types of traffic (e.g., management, production, backup). This physical isolation improves security by preventing traffic from one network type (e.g., management traffic) from mixing with another type (e.g., production traffic).

[0036] Another use case and advantage of splitting physical NIC ports is increased port density. Splitting physical NIC ports increases the overall port density available to the host without requiring additional NIC hardware. If the number of available PCIe slots in the server is limited, splitting a high-speed port into multiple lower-speed ports helps maximize the number of network connections available to the host.

[0037] Another use case and advantage of splitting physical NIC ports is cost savings. By dividing a physical NIC port into multiple logical ports, fewer additional physical NICs need to be purchased. Instead of buying additional NIC cards to provide more network ports, the host can split an existing port to achieve the same result at a lower cost.

[0038] Another use case and advantage of splitting physical NIC ports is improved control and traffic management. With split physical ports, different priority levels or traffic management policies can be applied individually to each port. This is useful in environments where different services require different QoS (Quality of Service) levels or bandwidth controls.

[0039] Another use case and advantage of splitting physical NIC ports is multi-homing and multiple paths. By splitting a NIC port, a server can be multi-homed with different uplinks to separate networks. This can improve fault tolerance and provide different paths for outgoing and incoming traffic, thus ensuring better load balancing and redundancy.

[0040] When a network interface card's physical port is split into multiple ports, multiple physical functions (PFs) are created for the host. Each PF can be managed independently by the host operating system. This can lead to improved resource allocation. Each PF behaves like a separate NIC interface, meaning resources (such as bandwidth, CPU, and memory) can be allocated more efficiently across the system. Multiple PFs can ensure that specific applications or virtual machines (VMs) have dedicated resources and do not compete for the same network interface, thus improving performance isolation. Furthermore, with multiple PFs, network administrators can assign different policies and configurations to each PF. These can include VLAN tagging, firewall rules, or QoS settings for different workloads, traffic types, or security zones.Furthermore, when dividing a physical NIC into multiple PFs, SR-IOV (Single Root I / O Virtualization) can be used to assign each PF to a different VM or container. SR-IOV enables near-native I / O performance by allowing VMs to bypass the hypervisor for network communication, thereby reducing latency and increasing throughput.

[0041] To support NIC / DPU port splitting, the NIC / DPU requires both hardware (HW) and software (SW) support. From a hardware perspective, special cables are needed to physically divide the physical port. These cables are called breakout cables. In high-speed network environments, especially in data centers, it is common to use breakout cables, which allow a single high-speed port (e.g., 40 Gbps or 100 Gbps) to be "split" into multiple lower-speed ports (e.g., 4 x 10 Gbps or 4 x 25 Gbps). These cables physically separate the data streams, allowing multiple devices or ports to connect to a single high-speed interface. From a software perspective, the NIC / DPU port splitting must be supported in all software stacks, including the NIC / DPU firmware, drivers, a virtual switch, and the NPAL on the virtual switch.In general, the firewall and driver can present multiple physical functions (PFs) to the virtual switch and the network optimization platform (NPAL). The NPAL can be used to configure different policies for different PFs, isolate networking between PFs, achieve better resource utilization, and ultimately support multiple PFs instead of just one or two. As described herein, the NPAL comprises a set of tables in a specific order and logic optimized for acceleration by NIC / DPU hardware, providing customers and users with a comprehensive set of features and high performance. Once the physical port is divided into multiple logical ports, the network pipeline can send network traffic data to each PF as part of the outbound port logic. Furthermore, the network pipeline can be configured with different policies per PF, such as different QoS or different traffic management. Fast NPAL link restoration

[0042] Aspects and embodiments of the present disclosure can provide an NPAL that offers an optimized network pipeline supporting rapid link recovery when a link failure occurs and an ECMP (Equal-Cost Multi-Path) group needs to be updated to reflect a new network topology. A link failure in network topologies refers to a situation in which a communication link between two network devices, such as routers, NICs, switches, or hosts, is no longer available due to various causes, including hardware failure, cable breakage, or network congestion. Link failures can significantly affect the performance, availability, and reliability of network services, especially in large or critical environments such as data centers or enterprise networks. There are several reasons that can lead to link failures, such as physical link failures (e.g.,Damage to or interruption of cables due to fiber optic breakage, defective Ethernet cables, etc.), device failures (e.g., hardware failures leading to interface failures), bottlenecks or congestion (i.e., network links overloaded with too much traffic, resulting in timeouts or packet loss), software errors or misconfigurations causing a network device to break links, power outages, maintenance work (e.g., planned outages for maintenance or upgrade work can also lead to temporary link failures), or the like.

[0043] Link failures can have various effects. When a link fails, packets transmitted over that link are lost. This can lead to transmission delays and affect real-time applications (e.g., VoIP, streaming). Connections between devices that rely on the failed link are unavailable until rerouting occurs. A link failure may require traffic to be routed over alternative, longer paths, resulting in higher latency and negatively impacting application performance. If the failed link was part of a redundant configuration (such as ECMP, STP (Spanning Tree Protocol), or dual-homed devices), traffic could be rerouted to an alternative link. However, this may result in a reduced level of redundancy. In networks using dynamic routing protocols (e.g.,When using protocols like OSPF (Open Shortest Path First), BGF (Border Gateway Protocol), or IS-IS (Intermediate System to Intermediate System), the network must reconverge by recalculating new routes in the event of a link failure. This convergence can take some time, during which the affected parts of the network may be unreachable. Rerouting traffic from a failed link can lead to congestion on alternative paths if the rerouted traffic exceeds the capacity of those paths. Mission-critical applications such as financial services or online games can experience downtime or performance degradation due to a link failure. TCP connections may experience transmission retries, which can increase latency, while UDP connections may experience data loss without retries.Point-to-point communication can come to a complete standstill until the network converges or the failed link is restored, which can lead to outages. Services that rely on high availability (HA) solutions can be affected if there is no backup path or if activating the backup mechanism takes too long.

[0044] A routing strategy is called ECMP. ECMP is a routing strategy that allows multiple forwarding paths for a packet to a destination if several paths have the same routing cost (or metrics). By using ECMP, networks can balance traffic across multiple paths, increase bandwidth utilization, improve redundancy, and provide fault tolerance. Due to the aforementioned impact of a link failure, it is important that a link is quickly restored when one occurs. Specifically, when a link fails, an ECMP group must be updated immediately to reflect that a particular link is no longer available. Similarly, when a link is restored, the ECMP group must be updated immediately with the restored link to enable better network utilization.

[0045] As described in more detail below, the NPAL can act as an accelerated network pipeline and offloading mechanism for the virtual switching hardware, periodically monitoring links. In at least one embodiment, a user can configure the NPAL to support fast link recovery, thereby enabling link monitoring by the virtual switch. For example, all ports in a given ECMP group can be monitored using IPC (inter-process communication) messages, such as Linux netlink messages from a Linux kernel.

[0046] When a link fails (i.e., a link failure occurs), the virtual switch identifies the link as failed and immediately updates the ECMP group by removing the link from the group. Specifically, the virtual switch updates the ECMP group in the tables of a bridge and / or router in the network pipeline to remove the failed link. Once the ECMP group is updated, traffic can be distributed to other links within the ECMP group.

[0047] When a link is restored (i.e., the link failure no longer occurs), the virtual switch identifies the link as restored and immediately updates the ECMP group by adding the link from the ECMP group. That is, the virtual switch updates the ECMP group in the tables on the bridge and / or router of the network pipeline to add the restored link (also referred to as the new link). Once the ECMP group is updated, traffic can be distributed to the new link along with the other links in the ECMP group. Hardware-accelerated PBR (Policy-Based Routing) via SFC

[0048] Aspects and embodiments of the present disclosure can provide hardware-accelerated policy-based routing (PBR) via the SFC architecture of a DPU. Using an SFC on the DPU, a user (or controller) can add various PBR policies, which are accelerated by DPU hardware as a single data layer on the DPU.

[0049] As described above, a DPU can provide accelerated network services (also known as HBN services or network services) to one or more host devices. The DPU network services can be used to accelerate Layer 2 protocols, Layer 3 protocols, tunneling protocols, and similar operations on the DPU hardware. The network service infrastructure is based on an SFC topology, where a first virtual bridge (e.g., an Open vSwitch (OVS) bridge) is controlled by the network service and provides all accelerated networking capabilities, while a second virtual bridge (e.g., an OVS bridge) can be programmed by a user or another controller. The network service can support various protocols and networking capabilities, such as ACLs, ECMP, tunneling, CT, QoS, STP, VLAN mapping, NATs, SDN, MPLS, and more.

[0050] Policy-Based Routing (PBR) is a technique that allows network administrators to make routing decisions based on policies they define, rather than relying on the standard routing table that uses destination IP addresses to determine the next hop. With traditional routing, a router decides how to forward packets based on the destination IP address and the routing table. PBR allows the router to make routing decisions based on other criteria, such as: source IP address or subnet; IP protocol type; port number; ingress interface; packet size; QoS parameters; and more. PBR is useful for controlling the path traffic takes through a network. It gives network administrators more flexibility in implementing routing rules that are not solely dependent on the destination IP address.

[0051] Common use cases for PBR include traffic engineering, load balancing, network preference, security and compliance, QoS, and similar applications. For example, a network administrator might want to route certain types of traffic over a preferred or more optimal path to improve performance. PBR can be used to distribute traffic across multiple network links, thus balancing the load on network resources. PBR can be used to route specific traffic for certain websites (such as YouTube or Netflix) over a less expensive internet connection, while routing critical business applications over a more reliable or faster connection (such as MPLS). PBR can also be used to enforce security policies by ensuring that traffic from specific users or networks is routed through security devices such as firewalls or IDS.PBR can be used to enforce QoS policies by routing traffic based on specific QoS markers.

[0052] PBR typically works by providing a policy definition. The policy definition is a set of rules or conditions used to classify traffic. These rules usually match criteria such as source address, destination address, protocol type, or port number. The defined policy is applied to incoming traffic on a specific interface to enforce the policy. When a packet arrives at that interface, the router checks if the packet meets the conditions defined in the policy. For data path traffic routing according to the policy: If the packet meets the policy, it is routed according to the policy's routing table or next-hop information, rather than the default routing table. Below are some PBR examples: • Example 1: Check source IP and define next jump ◯ Match: SRC IP = 1.1.1.1 ◯ Action: Next_Hop = 2.2.2.2 • Example 2: Matching protocol (HTTP) and route through a specific interface ◯ Match: PROTOCOL = TCP ◯ Action: OUTPUT PORT = PORT1 • Example 3: Aligning the Ingress interface and marking it for QoS ◯ Match: INGRESS INTERFACE = PORT1 ◯ Action: SET_QOS = VALUE1

[0053] In particular, the user (or controller) can program a PBR policy via SFC in parallel with the network service, resulting in a single accelerated data plane through the virtual switch and the DPU hardware. This means the PBR policy can be accelerated along with the existing network rules in the network service within this single accelerated data plane. As described above, the DPU's hardware-accelerated service can incorporate an OVS infrastructure (e.g., OVS DOCA technology) to configure and utilize hardware offload mechanisms and application techniques to generate a combined set of network rules. This set is then used by the acceleration hardware engine to process network traffic data within a single accelerated data plane.Using a defined SFC infrastructure in a configuration file, users and customers can utilize the DPU as a network accelerator on an edge device without the need for complex and intelligent switches in different network topologies in DC (Data Center) networks and SP (Service Provider) networks. NPAL emulation

[0054] Aspects and embodiments of the present disclosure can provide NPAL emulation. In general, emulation involves replicating the behavior of one system on another. The goal of emulation is to make the second system behave as if it were the original, often to replace or recreate the environment of the original system. NPAL emulation is used to provide a simulated network pipeline instead of a real hardware device running NPAL. In particular, NPAL emulation is used to simulate a DPU running a network service with NPAL, along with a complete DPU environment, including a virtual bridge, SFC, etc.To support an emulated NPAL with network services and a complete environment including a virtual switch and SFC, a software-based module can be used to support all the various components, such as a network service, NPAL (used by the network service), a virtual bridge, SFC, etc. Each of these components is implemented in software to emulate the exact same behavior as a real hardware device with a hardware-accelerated network pipeline, as described here. The emulated network pipeline can be similar to the hardware network pipeline described here.

[0055] Fig. Figure 1 is a block diagram of an integrated circuit 100 with SFC logic 102 for generating virtual bridges 104 and interface mappings 106 in an SFC architecture according to at least one embodiment. The integrated circuit 100 can be a DPU, a NIC, a smart NIC, a network interface device, or a network switch. The integrated circuit 100 comprises a memory 108, a processing unit 110, an acceleration hardware engine 112, a network connection 114, and a host connection 116. The processing unit 110 is coupled to the memory 108, the acceleration hardware engine 112, the network connection 114, and the host connection 116. The processing unit 110 hosts the virtual bridges 104 generated by the SFC logic 102.A virtual bridge (also known as a virtual switch) is software that operates within a computer network to connect different segments or devices, similar to a physical network bridge, but in a virtualized environment. It is a core component of network virtualization and enables the connection of virtual machines (VMs), containers, and other virtual network interfaces to each other and to the physical network, simulating traditional Ethernet network functions entirely in software. Virtual bridges allow the creation and management of isolated network segments within a single physical infrastructure, facilitate communication, enforce security policies, and provide bandwidth management, while offering the flexibility and scalability required in dynamic virtualized and cloud environments.Virtual bridges 104 can be Open vS (OVS) bridges. An OVS bridge acts as a virtual switch at the heart of the Open vSwitch architecture, enabling advanced network management and connectivity in virtualized environments. It works by aggregating multiple network interfaces into a single logical interface and managing traffic flow between VMs on the same physical host and the external network. Unlike traditional virtual bridges, the OVS bridge supports a wide range of networking features, such as VLAN tagging, traffic monitoring with sFlow and NetFlow, Quality of Service (QoS), and Access Control Lists (ACLs), providing network administrators with greater flexibility and control.The OVS bridge efficiently routes network traffic based on predefined policies and rules, making it an indispensable tool for building complex, multi-tenant cloud and data center networks.

[0056] Especially with regard to Fig. Virtual bridges can provide network connectivity between VMs running on the same integrated circuit or a separate host device, containers, and / or physical devices. In short, virtual bridges allow VMs on a single physical host to communicate with each other and with the external network. Virtual bridges can emulate the functionality of a physical network switch but operate at the software level within the integrated circuit. Virtual bridges can manage network traffic and route data packets between VMs on the same host or between VMs and the physical network via ports. These ports can be configured for various policies, such as security settings, QoS rules, and so on.Virtual Bridges 104 can segment network traffic to ensure isolation between different virtual networks. Virtual Bridges 104 can provide an interface between the virtualized environment and the physical network, allowing VMs to communicate outside their host. Virtual Bridges 104 can support standard network protocols and features, such as VLAN tagging, Layer 2 (L2) forwarding, Layer 3 (L3) capabilities, tunneling protocols (e.g., VXLAN (Virtual Extensive LAN), GRE (Generic Routing Encapsulation), and the Geneve protocol), flow-based forwarding, OpenFlow support, integration with virtualization platforms (e.g., VMware, KVM, Xen, and others that enable network connectivity for virtual machines and containers), extensibility, traffic monitoring and mirroring, security, multi-platform support (e.g., Linux, FreeBSD, Windows, etc.), and the like.For Layer 2 switching, one or more of the Virtual Bridges 104 function as Layer 2 Ethernet switches, enabling the forwarding of Ethernet frames between different network interfaces, including virtual and physical ports. For Layer 3 routing, one or more of the Virtual Bridges 104 support Layer 3 IP routing, allowing them to route traffic between different IP subnets and perform IP-based forwarding. The Virtual Bridges 104 can support VLAN tagging, enabling the segmentation of network traffic into different VLANs. The Virtual Bridges 104 can use flow-based forwarding, where network flows are classified based on their characteristics and packet forwarding decisions are made based on flow rules, as well as enforcing security policies and access controls.OVS is frequently used in data center and cloud environments to provide network agility, flexibility, and automation. It plays a key role in creating and managing virtual networks, enabling network administrators to adapt to the changing needs of modern, dynamic data centers.

[0057] In at least one embodiment, the virtual bridges 104 can utilize OVS and OF technologies. The virtual bridges 104 can be controlled by a network controller (also referred to as a network service) to make decisions about how to route traffic through the network. As described herein, a network controller (e.g., an SDN controller) is a centralized entity that manages flow control to the network devices. The OF protocol can be used to interact directly with the forwarding layer of network devices such as virtual or physical switches and routers. In at least one embodiment, the virtual bridges 104 can use flow tables that contain rules for handling packets. Each flow table contains a set of flow entries. The flow entry defines what to do with packets that meet certain criteria.An entry can have three parts: matching fields, actions, and counters. The matching fields define packet attributes to be compared, such as source / destination IP (Internet Protocol) addresses, MAC (Media Access Control) addresses, port numbers, VLAN tags, etc. The actions define what should happen to a matching packet, such as forwarding it to a specific port, modifying fields within the packet, or discarding it. The counters can be used to track the number of packets and bytes for each flow. Because the Virtual Bridges 104 are virtualized, they can generate rules at the software (SW), data path (DP), and hardware levels. A software-level rule is called an SW rule or OF rule. A DP-level rule is called a DP rule. A hardware-level rule is called an HW rule.When a software rule is created, corresponding DP and hardware rules are generated. A network controller can add, update, or delete expiration entries, thereby changing the configuration settings.

[0058] In another embodiment, the virtual bridges 104 are a standard virtual switch or a distributed virtual switch. In yet another embodiment, the virtual bridges 104 are an SDN-based switch integrated into an SDN controller. The integrated circuit 100 can be used in data centers, cloud computing environments, development and test environments, network function virtualization (NFV) environments, or the like. The virtual bridges 104 can be used in a data center where server virtualization is common to enable efficient communication within and between servers. In a cloud computing environment, the virtual bridges 104 can enable networking between multiple tenants, allowing different clients to have isolated network segments. The virtual bridges 104 can facilitate the connection and management of network function virtualizations (e.g.,Virtual Bridges 104 enable network connectivity (NFVs) within virtual infrastructures. Some advantages of Virtual Bridges 104 include their ease of configuration and reconfiguration without physical intervention, reducing the need for physical network hardware and its associated maintenance, and providing the ability to create isolated networks for different applications or tenants. In summary, Virtual Bridges 104 are a software-based device that performs the networking functions of a physical switch in a virtualized environment (such as data centers and cloud computing environments), offering flexibility, isolation, and efficient network management within the virtualized environment.

[0059] In at least one embodiment, the integrated circuit 100 can also host one or more hypervisors and one or more VMs (virtual machines). The network traffic data 120 can be routed from the virtual bridges 104 to the respective VM.

[0060] During operation, the SFC logic 102 can use a configuration file 124 to create the virtual bridges 104 and interface mappings 106 between the virtual bridges 104, the network connection 114, and the host connection 116. The configuration file 124 can define the virtual bridges 104, the interface mappings 106, and the configurations for each. According to the configuration file 124, the SFC logic 102 can create a first virtual bridge and a second virtual bridge, where the first virtual bridge is controlled by a first network service 130 hosted on the integrated circuit 100, and the second virtual bridge is controlled by user-defined logic 126. The SFC logic 102 can add one or more host interfaces and a first service interface to the second virtual bridge for operational coupling with the first network service 130.SFC logic 102 can add one or more virtual ports between the first virtual bridge and the second virtual bridge.

[0061] In at least one embodiment, the custom logic 126 is part of a custom service 132, for example, a custom network service hosted on 100. The SFC logic 102 can, according to the configuration file 124, add a second service interface to the second virtual bridge for operational coupling with the custom service 132. The custom service 132 can be a custom security service, a custom telemetry service, a custom storage service, or the like.

[0062] In at least one embodiment, the integrated circuit 100 stores an operating system 122 (OS 122) in main memory 108. The integrated circuit 100 can be executed on the processing device 110. In at least one embodiment, the SFC logic 102 generates the virtual bridges 104 and the interface mappings 106 as part of the installation of OS 122 on the integrated circuit 100. In another embodiment, the SFC logic 102 can generate the virtual bridges 104 and the interface mappings 106 during the runtime of the integrated circuit 100 without reinstalling OS 122 on the integrated circuit 100. In at least one embodiment, the SFC logic 102 can configure an OS property associated with OS 122 (e.g., page size) in one of the virtual bridges 104 according to the configuration file 124.

[0063] In at least one embodiment, the SFC logic 102 can perform and facilitate operations to identify a change in a configuration setting of the virtual bridges 104 in the configuration file 124 (or a new configuration file). The SFC logic 102 can accordingly configure the virtual bridges 104 and interface mappings 106 during installation or at runtime without reinstalling the operating system 122.

[0064] As in Fig. As illustrated in Figure 1, the SFC logic 102 is implemented in the integrated circuit 100 with memory 108, processing device 110, acceleration hardware engine 112, network connection 114, and host connection 116. In other embodiments, the SFC logic 102 can be implemented in processors, computing systems, CPUs, DPUs, smart NICs, IPUs, or the like. The underlying hardware can host the virtual bridges 104 and interface mappings 106.

[0065] In at least one embodiment, the integrated circuit 100 can be used in a data center (DC) network or a service provider (SP) network. A data center (DC) network is the fundamental infrastructure that enables communication, data exchange, and connectivity between various computing resources, storage systems, and network devices within a data center. It is designed to support high-speed data transfer, reliable access to distributed resources, and efficient management of data flows across various physical and virtual platforms. At its core, a DC network integrates a variety of switches, routers, firewalls, and load balancers, orchestrated by advanced network protocols and software-defined networking (SDN) technologies to ensure optimal performance, scalability, and security.The architecture of a data center (DC) network typically comprises both the physical backbone, with high-performance cables and switches that ensure bandwidth and redundancy, and the virtual overlay, which enables flexibility, rapid provisioning, and resource optimization through virtual networks. A well-designed DC network supports a range of applications, from enterprise services to cloud computing and big data analytics, by providing the infrastructure to handle the massive amounts of data, complex calculations, and application workloads typical of modern data centers. It plays a critical role in disaster recovery, data replication, and high-availability strategies, ensuring that data center services remain resilient and efficient under varying workloads.A service provider (SP) network refers to the extensive, high-capacity communications infrastructure operated by organizations that provide various telecommunications, internet, cloud computing, and digital services to businesses, consumers, and other entities. These networks are designed to provide wide-ranging coverage, connecting numerous geographic locations, including urban centers, remote areas, and international destinations, to facilitate global communication and data exchange. The architecture of an SP network is multi-layered, incorporating a mix of technologies such as fiber optics, wireless transmission, satellite linking, and broadband access to achieve widespread connectivity. Central to these networks are high-performance backbone networks, responsible for the high-speed transmission of large volumes of data over long distances.In addition to physical infrastructure, service provider (SP) networks utilize advanced network technologies such as MPLS, SDN (Software-Defined Networking), and NFV (Network Function Virtualization) to improve the efficiency, flexibility, and scalability of service delivery. Service provider networks are designed to support a wide range of services, from traditional voice and data services to modern cloud-based applications and streaming services, to meet the evolving needs of consumers and businesses. They are critical to the implementation of the internet, mobile communications, enterprise network solutions, and the emerging IoT (Internet of Things) ecosystem, as they ensure connectivity and accessibility to digital resources and services on a global scale.

[0066] In at least one embodiment, the virtual bridges 104 and interface mappings 106 are part of a service function chaining (SFC) architecture implemented in at least one DPU, NIC, smart NIC, network interface device, or network switch. In at least one embodiment, the SFC logic 102 can be implemented as part of a hardware-accelerated service on an agentless hardware product, such as a DPU, as described below with respect to Fig. Figure 2 illustrates and describes the integrated circuit 100. This means that the integrated circuit 100 can be a DPU. The DPU can be a programmable data center infrastructure on a single chip. The hardware-accelerated service can be part of NVIDIA OVS-DOCA, developed by NVIDIA Corporation in Santa Clara, California. OVS-DOCA, the new OVS infrastructure for DPUs, is based on the open-source OVS with additional features, new acceleration capabilities, and a purely DOCA-based OVS backend. Alternatively, the SFC logic 102 can be part of other services. SFC (Service Function Chaining) Infrastructure

[0067] SFC infrastructure refers to the network architecture and framework that enables the creation, deployment, and management of service chains within a network. Service Function Chaining (SFC) is a technique used to define an ordered list of network services (such as firewalls, load balancers, and intrusion detection systems) through which network traffic is systematically routed. This ordered list is known as a "chain," and each service in the chain is referred to as a "service function." SFC infrastructure is designed to ensure that network traffic flows through these services in a predefined sequence, thereby improving the efficiency, security, and flexibility of network service delivery. An SFC infrastructure can include Service Function Forwarders, Service Functions (SFs), Service Function Paths (SFPs), and other components.SFFs are the network devices responsible for routing traffic to the desired service functions according to defined service chains. SFFs ensure that packets are routed through the correct sequence of service functions. SFs are the actual network services that process the packets. These can be physical or virtual network functions, such as firewalls, WAN (Wide Area Network) optimizers, load balancers, intrusion detection / prevention systems, or similar. An SFP is the defined path that traffic takes through the network, including the specific sequence of service functions it passes through. SFPs are configured based on policy rules and can be dynamically adjusted to respond to changing network conditions or requirements.The SFC infrastructure can use one or more SFC descriptors, which are guidelines or templates that describe the service chain, including the sequence of service functions, performance requirements, and other relevant metadata. The SFC descriptor(s) can serve as a blueprint for instantiating and managing service chains within the network. The SFC infrastructure can include a classification function responsible for the initial inspection and classification of incoming packets to determine the appropriate service chain to which traffic should be routed. Classification can be based on various packet attributes, such as source and destination IP addresses, port numbers, and application identifiers. Often as part of a larger SDN (Software-Defined Networking) or NFV framework, one or more network controllers can manage the SFC infrastructure.They can be responsible for orchestrating and deploying service chains, configuring network elements, and ensuring real-time adjustment and optimization of data flows. SFC infrastructure offers numerous advantages, including improved network agility, optimized resource utilization, and enhanced overall security. By decoupling the network's control plane from the data plane and leveraging virtualization technologies, SFC infrastructures can dynamically adapt to changing network requirements, enabling more efficient and scalable service delivery models. As mentioned in [reference to...] Fig. As shown and described in Figure 2, the SFC infrastructure can be used as a DPU-based SFC infrastructure 200.

[0068] Fig. Figure 2 is a block diagram of an exemplary DPU-based SFC infrastructure 200 for providing an SFC architecture 220 according to at least one embodiment. The DPU-based SFC infrastructure 200 comprises a DPU 204 coupled between a host device 202 and a network 210. In at least one embodiment, the DPU 204 is a system-on-a-chip (SoC) considered to be a data center infrastructure on a single chip. The DPU 204 is a specialized processor designed to offload and accelerate networking, storage, and security tasks from the CPU (central processing unit) of the host device 202, thereby improving the overall efficiency and performance of the system. The DPU 204 can be deployed in data centers and cloud computing environments to manage data traffic more efficiently and securely.

[0069] The DPU 204 can include a network connection (e.g., one or more Ethernet ports) that is operationally coupled to the network 210. The network connection can consist of high-speed network interfaces that provide a direct connection to the data center's network infrastructure. These interfaces can support various speeds (e.g., 10 Gbps, 25 Gbps, 40 Gbps, or higher) depending on the model and deployment requirements. The network 118 can include a public network (e.g., the internet), a private network (e.g., a LAN (Local Area Network) or a WAN (Wide Area Network)), a wired network (e.g., an Ethernet network), a wireless network (e.g., an 802.11 network or a WiFi network), a cellular network (e.g., an LTE (Long Term Evolution) network), routers, hubs, switches, server computers, and / or a combination thereof.

[0070] The DPU 204 can be connected to a CPU of the Host Device 202 (or multiple host devices or servers) via one or more host connections (e.g., PCIe (Peripheral Component Interconnect Express)). PCIe provides a high-speed connection between the DPU 204 and the host device's CPU, enabling rapid data and instruction transfer. This connection is used to offload tasks from the CPU and ensure that the DPU 204 can efficiently access system memory and storage resources. To enable communication between the Host Device 202 and the DPU 204, special software drivers and firmware are installed on the Host Device 202. These software components allow the host's operating system and applications to interact with the DPU 204, offload specific tasks to it, and retrieve processed data.In virtualized environments, the DPU 204 can also communicate with hypervisors or container management systems. This allows the DPU to support multiple virtual machines (VMs) or containers by providing them with virtualized networking capabilities, network isolation, and security features without burdening the host device's CPU. The DPU 204 can utilize Direct Memory Access (DMA) to read from and write directly to the host device's memory, bypassing the CPU to reduce latency and free up CPU resources for other tasks. This enables efficient data movement between the host's memory, the DPU 204, and the Network 210. In at least one embodiment, the DPU 204 includes a Direct Memory Access (DMA) controller (in ). Fig. 2 (not illustrated), which is coupled to a host interface. The DMA controller can read data from the host's physical memory via a host interface. In at least one embodiment, the DMA controller reads data from the host's physical memory using PCIe technology. Alternatively, other technologies can be used to read data from the host's physical memory. In other embodiments, the DPU 204 can be any computing system or device capable of performing the techniques described herein.

[0071] After the physical connection is established, the DPU 204 is configured to communicate with network 210. This includes setting up IP addresses, VLAN tags (if using virtual networks), and routing information to ensure that the DPU 204 can send and receive data packets to and from other devices on network 210. As described herein, the DPU 204 performs network-related tasks such as packet forwarding, encryption / decryption, load balancing, and QoS (Quality of Service) enforcement. In this way, it effectively becomes an intelligent network interface controller with advanced capabilities, capable of performing sophisticated data processing and traffic management.

[0072] In at least one embodiment, the DPU 204 comprises DPU hardware 208 and DPU software 206 (e.g., a software framework with acceleration libraries). The DPU hardware 208 may include one or more CPUs (e.g., a single-core or multi-core CPU), an acceleration hardware engine 214 (or multiple hardware accelerators), memory 218, and the network and host connections. In at least one embodiment, the DPU 204 comprises DPU software 206, including a software framework and acceleration libraries. The software framework and acceleration libraries may include one or more hardware-accelerated services, including a hardware-accelerated service (e.g.,NVIDIA DOCA), hardware-accelerated virtualization services, hardware-accelerated networking services, hardware-accelerated storage services, hardware-accelerated AI / ML (Artificial Intelligence / Machine Learning) services, hardware-accelerated service, and hardware-accelerated management services.

[0073] In at least one embodiment, the memory 218 stores the configuration file 124. The 124 specifies the virtual bridges 104, the interface mappings 106 (host interfaces and network ports) between the virtual bridges 104, and the network functions 222 in the SFC architecture 220. For example, according to the configuration file 124, one of the CPUs 216 can create a first virtual bridge and a second virtual bridge, wherein the first virtual bridge is controlled by a first network service hosted on the DPU 204, and the second virtual bridge is controlled by user-defined logic.The CPU can add one or more host interfaces to the second virtual bridge, a first service interface to the first virtual bridge for operational coupling with the first network service, and one or more virtual ports between the first and second virtual bridges, according to the configuration file. SFC logic 102, as above, refers to this. Fig. As described in section 1, this can be implemented in the DPU software 206 to create and manage the SFC architecture 220. The SFC logic 102 can utilize the acceleration hardware engine 214 (e.g., DPU hardware 208) to offload and filter network traffic data 212 based on predefined filters using the hardware capabilities of the acceleration hardware engine 214. The DPU hardware 208 can receive network traffic data 212 via the network ports from a second device (or multiple devices) in the network 210.

[0074] In at least one embodiment, the DPU software 206 can perform several actions when creating the virtual bridges 104 and the corresponding interface mappings 106 to ensure proper configuration and integration within the virtualized environment. The DPU software 206 can initialize the creation of a virtual bridge by allocating resources and setting the initial configuration parameters. These configurations can be stored in the configuration file 124. The configuration parameters can define the bridge name, the network protocols to be supported, and any specific settings relating to performance or security. A virtual network interface is created to function as the virtual bridge. This interface serves as the anchor point for all virtual and physical interfaces connected to the virtual bridge.The DPU software 206 can identify the designated physical (e.g., Ethernet ports) and virtual interfaces (e.g., virtual machine network adapters) and link them to the newly created virtual bridge. This action involves configuring the settings of each interface to ensure compatibility and optimal communication within the virtual bridge. The DPU software 206 can configure network protocols. Network protocols and services, such as STP (Spanning Tree Protocol) to prevent loops, are configured on the virtual bridge. The DPU software 206 can also set up VLAN tagging for traffic segmentation, QoS policies for traffic prioritization, and security features such as ACLs (Access Control Lists). The DPU software 206 can assign IP addresses to the bridge interfaces.When the virtual bridge functions as an L3 (Layer 3) switch, the DPU software 206 assigns IP addresses to the bridge interface, enabling it to participate in IP routing between the various connected networks or devices. The DPU software 206 can provide a unified interface for centralized network control and monitoring. Network administrators can manage the virtual bridge, along with other virtual network components, through this unified interface. The DPU software 206 can enable monitoring and management capabilities for the virtual bridge, allowing network administrators to observe traffic flow, identify potential problems, and make adjustments as needed to optimize network performance and security.During these steps, the software ensures that the virtual bridge is seamlessly integrated into the existing network architecture, thus providing a flexible and efficient way to connect different network segments in virtualized environments.

[0075] In addition to creating virtual bridges 104, the DPU software 206 can create one or more virtual ports between the virtual bridges 104. A virtual port, often referred to as a patch port in the context of virtual networks, is a software-defined network component that facilitates connection and communication between different virtual devices or between virtual and physical devices within a network. Unlike physical ports on a network switch or router, virtual ports are not bound to a specific hardware interface but are created and managed by software, thus providing a flexible and efficient way to route traffic in virtualized environments. Virtual ports play a crucial role in creating complex network topologies within VMs, containers, and virtual networks.They can be used to configure virtual switches (vSwitches) or bridges, allowing virtual machines on the same or different hosts to communicate as if they were connected to the same physical network switch. Patch ports can also connect virtual networks to physical networks, enabling VMs to access external network resources. Virtual ports can be dynamically created, configured, and deleted based on network requirements, making them easier to adapt to changes in network topology or workload demands. By optimizing the use of the underlying physical network infrastructure, virtual ports can improve overall network efficiency and reduce the need for additional physical hardware.Virtual ports support advanced network features such as VLAN tagging, QoS settings, and ACL configurations, enabling precise management of network traffic. Virtual ports can also provide insight into virtual network traffic, facilitating detailed monitoring, logging, and troubleshooting.

[0076] In addition to creating virtual bridges 104, the DPU software 206 can configure the link state propagation of virtual bridges 104. Link propagation, in the context of virtual bridges or virtual switches such as OVS (Open vSwitch), refers to the process by which state changes in physical or virtual network interfaces are communicated across the network. This ensures that the entire network topology is aware of the link status and can adjust its routing and switching behavior accordingly. Link propagation is used to maintain the accuracy of the network's operational state, enable efficient data flow, and ensure high availability and reliability of network services. In OVS, the system monitors the state of the physical ports and virtual interfaces connected to it.This includes tracking when ports power up (become active) or power down (become inactive) due to changes in the physical link state or the virtual interface configuration. Upon detecting a change in a port's state, OVS propagates this information throughout the network. This is done by sending notifications to relevant components within the network infrastructure, such as other switch instances, network controllers, or virtual machines connected to the virtual switch. Based on the propagated link state information, network devices and protocols can adjust their operations. This may involve recalculating routes, redistributing network traffic, or initiating failover procedures to alternative paths or interfaces to maintain network connectivity and performance.Link propagation helps maintain topology consistency from the network's perspective. By ensuring all network elements have up-to-date information about link states, it enables coherent and coordinated network behavior, especially in dynamic environments with frequent changes. OVS can integrate link propagation with standard network protocols and mechanisms, such as the Spanning Tree Protocol (STP) for loop prevention and the Link Layer Discovery Protocol (LLDP) for network discovery. This integration enhances the switch's ability to participate in a broader network ecosystem by adapting to and leveraging established network management practices.Link propagation plays a fundamental role in the adaptive and elastic behavior of networks that use virtual bridges or switches like OVS, by ensuring that changes in the network infrastructure are reflected quickly and accurately throughout the network. This capability is particularly important in virtualized and cloud environments, where the topology can be highly dynamic and the efficiency and reliability of network connectivity are critical.

[0077] In at least one embodiment, the DPU software 206 can configure link state propagation in a virtual bridge by establishing mechanisms for monitoring and communicating the operational states of links (e.g., UP or DOWN) throughout the network. This allows the virtual bridge and the entities connected to it to dynamically adapt to changes in the network topology, such as when interfaces are added or removed, or experience failures. The DPU software 206 can enable monitoring capabilities on the virtual bridge for all connected interfaces, both physical and virtual. This typically includes enabling link state change detection so that the bridge can identify when a port becomes active or inactive.After enabling monitoring, the system must be configured to notify relevant network components of any changes. This might involve setting up event listeners or subscribers that can respond to notifications about link state changes. For virtual bridges managed by a controller (in SDN environments), this may also mean configuring communication between the bridge and the controller to ensure it is promptly informed of the network state. Configuring link propagation also involves specifying the actions to be triggered when the link state changes.This can include, for example, the automatic recalculation of routing tables, the redistribution of traffic to available paths, or even the triggering of alerts and event logging for network administrators. The virtual bridge's forwarding database (FDB) or MAC table may need to be dynamically updated based on link state changes to ensure efficient network routing. This prevents packets from being sent to failed interfaces.

[0078] In at least one embodiment, the DPU software 206 can configure the virtual bridge to filter the network traffic data 212. For example, the configuration file 124 can specify which data should be extracted from the network traffic data 212 by the virtual bridge. The configuration file 124 can specify one or more filters that extract or remove predefined data types from the network traffic data 212. The network traffic that meets the filter criteria can be structured and streamed to one of the network functions 222 for processing. For example, the configuration file 124 can specify that all HTTP (Hypertext Transport Protocol) traffic is extracted from the network traffic data 212 and routed to one of the network functions 222.The configuration file 124 can specify that all traffic on specific ports is extracted from the network traffic data 212 for processing by the network functions 222, which are described in more detail below.

[0079] As described herein, the SFC architecture 220 can provide support for various network protocols and capabilities in network functions 222. Various network protocols and capabilities form the backbone of modern networks, enabling a wide range of functions, from basic connectivity to advanced security and traffic optimization. The network functions 222 can include network functions, including a set of tables and logic for executing the corresponding network function, such as ACLs, ECMP routing, tunneling, CT (connection tracking), NAT, QoS, or the like. ACLs are a fundamental network security feature that allows or denies traffic based on a set of rules. These lists are applied to network interfaces and control the flow of packets at either the ingress or egress point.The rules can specify various parameters such as source and destination IP addresses, port numbers, and protocol type to fine-tune the traffic filtering process, thereby improving security and compliance. ECMP is a routing strategy used to distribute outbound network traffic across multiple paths at equal cost. By evenly distributing the load across these paths, ECMP can significantly increase network bandwidth and reliability. This protocol is particularly useful in data centers and cloud environments where high availability and scalability are critical. Tunneling encapsulates one protocol or session within another, allowing data to traverse networks with incompatible address spaces or architectures. It is commonly used in the implementation of VPNs (Virtual Private Networks), where secure tunnels over the internet enable private communication.Protocols like IPsec and GRE are common examples that enable tunneling for security and protocol encapsulation purposes. Transaction computation (CT) refers to the ability of a network device (such as a firewall or router) to store the state information of network connections passing through it. This capability allows the device to make more informed decisions about which packets to allow or block, based on the context of the session to which they belong. CT is crucial for implementing stateful firewalls and network address translation (NAT) capabilities. Quality of service (QoS) capabilities refer to mechanisms that prioritize certain types of traffic to ensure application performance, particularly in congested network scenarios.Network Functions 222 can include other types of network functions, such as SR (Segment Routing), MPLS (Multiprotocol Label Switching), network virtualization, SDN (Software-Defined Networking), and the like. SR allows the source of a packet to define the path the packet takes through the network using a list of segments, thereby improving routing efficiency and flexibility. MPLS is a method for accelerating and shaping network traffic flows by labeling data packets and routing them quickly along predetermined paths in the network. Network virtualization involves abstracting physical network devices and resources into a virtual network, enabling more flexible and efficient resource management.Software-defined networking (SDN) decouples network control and routing functions, enabling programmable network management and efficient orchestration of network services. These protocols and capabilities represent only a fraction of the vast array of technologies underlying modern networks, each playing a specific role in ensuring that data is transported efficiently, securely, and reliably across the digital infrastructure.

[0080] Integrating a DPU 204 into the network 210 and the host device 202 thus represents a powerful approach to optimizing data processing tasks, significantly improving the performance and security of data center and cloud computing environments. By handling a substantial portion of the network, storage, and security workload, the DPU 204 can free up CPUs to focus more on application processing, improving overall system efficiency and throughput. For example, the DPU 204 can handle network data path processing of network traffic data 212. The CPU can manage path initialization and exception handling. The DPU 204 can be part of a data center and may include one or more data stores, one or more server machines, and other data center infrastructure components.It is important to note that, unlike a CPU or GPU, the DPU 204 represents a new class of programmable processor that combines three key elements, including: 1) a high-performance, industry-standard software-controlled CPU (single-core or multi-core) tightly coupled with the other SoC components; 2) a high-performance network interface capable of analyzing, processing, and efficiently transferring data to GPUs and CPUs at line speed or the speed of the rest of the network; and 3) a rich set of flexible and programmable acceleration engines that offload and enhance application performance for AI and machine learning, security, telecommunications, and storage. These capabilities enable an isolated, cloud-native bare-metal computing platform for cloud computing.In at least one embodiment, the DPU 204 can be used as a standalone embedded processor. In at least one embodiment, the DPU 204 can be integrated into a network interface controller (also called a SmartNIC (Smart Network Interface Card)) used as a server system component. A DPU-based network interface card (network adapter) can offload processing tasks that are normally handled by the server system's CPU. With its processor, a DPU-based SmartNIC can perform any combination of encryption / decryption, firewall, TCP / IP (Transport Control Protocol / Internet Protocol), and HTTP (Hypertext Transport Protocol) processing. SmartNICs can be used, for example, for high-traffic web servers.

[0081] In at least one embodiment, the DPU 204 can be configured for modern cloud workloads and high-performance computing in traditional enterprises. In at least one embodiment, the DPU 204 can provide a suite of software-defined networking, storage, security, and management services at data center scale, with the ability to offload, accelerate, and isolate data center infrastructure. In at least one embodiment, the DPU 204 can use these software services to provide multi-tenant, cloud-native environments. In at least one embodiment, the DPU 204 can provide data center services with up to hundreds of CPU cores, freeing up valuable CPU cycles for running business-critical applications.In at least one embodiment, the DPU 204 can be considered a new type of processor designed to process data center infrastructure software in order to offload and accelerate the computational load of virtualization, networking, storage, security, cloud-native AI / ML services and other management services.

[0082] In at least one embodiment, the DPU 204 can include connectivity via packet-based connections (e.g., Ethernet), switched fabric connections (e.g., InfiniBand, Fibre Channel, Omni-Path), or the like. In at least one embodiment, the DPU 204 can provide a data center that is accelerated, fully programmable, and configured with security (e.g., zero-trust security) to prevent data breaches and cyberattacks. In at least one embodiment, the DPU 204 can include a network adapter, an array of processor cores, and infrastructure offload engines with full software programmability. In at least one embodiment, the DPU 204 can be located at the edge of a server to provide flexible, secure, and high-performance cloud and AI workloads. In at least one embodiment, the DPU 204 can reduce total cost of ownership and increase data center efficiency.In at least one embodiment, the DPU 204 can provide the software framework and acceleration libraries (e.g., NVIDIA DOCA™) that enable developers to quickly create applications and services for the DPU 204, such as security services, virtualization services, networking services, storage services, AI / ML services, and management services. In at least one embodiment, the software framework and acceleration libraries facilitate the use of the DPU 204's hardware accelerators to ensure data center performance, efficiency, and security. In at least one embodiment, the DPU 204 can be coupled with a GPU. The GPU can include one or more accelerated AI / ML pipelines.

[0083] In at least one embodiment, the DPU 204 can provide network services with a virtual switch (vSwitch), a virtual router (vRouter), NAT (Network Address Translation), load balancing, and NFV (Network Virtualization). In at least one embodiment, the DPU 204 can provide storage services, including NVMe-oF™ (NVMe™ over Fabrics) technology, elastic storage virtualization, HCI (Hyper-Converged Infrastructure) encryption, data integrity, compression, data deduplication, and the like. NVM Express™ is an open logical device interface specification for accessing non-volatile storage media connected via the PCIe (Peripheral Component Interconnect Express®) interface.NVMe-oF™ provides an efficient mapping of NVMe instructions to multiple network transport protocols, enabling a computer (an "initiator") to access block-level storage devices connected to another computer (a "destination") very efficiently and with minimal latency. The term "fabric" is a generalization of the more specific terms network and I / O (input / output) channel. It essentially refers to a many-to-many connection of elements, often in a peripheral context. NVMe-oF™ technology enables the transport of the NVMe instruction set across a variety of interconnect infrastructures, including networks (e.g., IP (Internet Protocol / Ethernet)) and I / O channels (e.g., Fibre Channel).In at least one embodiment, the DPU 204 can provide hardware-accelerated services using NGFW (Next-Generation Firewall), IDS (Intrusion Detection System), IPS (Intrusion Prevention System), a trust root, microsegmentation, DDoS (Distributed Denial of Service) prevention technologies, and ML detection. NGFW is a network security device that goes beyond the capabilities of a stateful firewall, offering features such as application detection and control, integrated intrusion prevention, and cloud-delivered threat intelligence. In at least one embodiment, one or more network interfaces can include an Ethernet interface (single or dual port) and an InfiniBand interface (single or dual port). In at least one embodiment, the one or more host interfaces can include a PCIe interface and a PCIe switch.In at least one embodiment, the one or more host interfaces can include other memory interfaces. In at least one embodiment, the CPU can include multiple cores (e.g., up to eight 64-bit core pipelines) with L2 cache per two single or dual cores and L3 cache with eviction policy support for DDR (Double Data Rate) DIMM (Dual Inline Memory Module) (e.g., DDR4 (Double Data Rate 4) DIMM support) and a DDR4 (Dynamic Random Access Memory) DRAM controller. The memory can be integrated DDR4 memory with ECC (Error Correction Code) error correction support. In at least one embodiment, the CPU can include a single core with L2 and L3 caches and a DRAM controller. In at least one embodiment, the one or more hardware accelerators can include a security accelerator, a memory accelerator, and a network accelerator.In at least one embodiment, the security accelerator can provide secure boot with hardware root of trust, secure firmware updates, Cerberus compliance, regular expression (RegEx) acceleration, IPsec / TLS encryption of data in transit, AES-GCM 512 / 256-bit keys for encryption of data at rest (e.g., AES with XTS (Ciphertext Stealing) (e.g., AES-XTS 256 / 512)), SHA 256-bit hardware acceleration, and hardware public key accelerators (e.g., RSA (Rivest-Shamir-Adleman), Diffie-Hellman, DSA (Digital Signal Algorithm), ECC, ECC-DSA (Elliptic Curve Cryptography Digital Signal)). include algorithms), EC-DH (Elliptic-curve Diffie-Hellman)) and TRNG (True Random Number Generator).In at least one embodiment, the storage accelerator BlueField SNAP - NVMe™ and VirtIO-blk, NVMe-oF™ acceleration, compression and decompression acceleration, as well as data hashing and deduplication. In at least one embodiment, the network accelerator can provide RoCE (RDMA (Remote Direct Memory Access) over Converged Ethernet), Zero Touch RoCE, stateless offloads for TCP, IP and UDP (User Datagram Protocol), LRO (Large Receive Offload), LSO (Large Segment Offload), checksum, TSS (Total Sum of Squares), RSS (Residual Sum of Squares), HDS (HTTP Dynamic Streaming) and VLAN (Virtual Local Area Network) insert / remove, SR-IOV (Single Root I / O Virtualization), virtual Ethernet card (e.g., VirtIO-net), multiple functions per port, VMware NetQueue support, virtualization hierarchies and QoS (Quality of Service) ingress and egress levels (e.g., 1K ingress and egress QoS levels).In at least one embodiment, the DPU 204 can also provide boot options, including secure booting (RSA-authenticated), remote booting via Ethernet, remote booting via iSCSI (Internet Small Computer System Interface), PXE (Preboot Execution Environment) and UEFI (Unified Extensible Firmware Interface).

[0084] In at least one embodiment, the DPU 204 can provide management services, including a 1-GbE out-of-band management port, an NC-SI (Network Controller Sideband Interface), an MCTP (Management Component Transport Protocol) over SMBus (System Management Bus) and MCT (Monitoring Control Table) over PCIe, PLDM (Platform Level Data Model) for monitoring and control, PLDM for firmware updates, an I2C (Inter-Integrated Circuit) interface for device control and configuration, an SPI (Serial Peripheral Interface) interface to flash, an eMMC (Embedded Multi-Media Card) memory controller, UART (Universal Asynchronous Receiver / Transmitter) and USB (Universal Serial Bus).

[0085] The host device 202 can be a desktop computer, a laptop computer, a smartphone, a tablet computer, a server, or any suitable computing device capable of performing the techniques described herein. In some embodiments, the host device 202 can be a computing device of a cloud computing platform. For example, the host device 202 can be a server machine of a cloud computing platform or a component of the server machine. In such embodiments, the host device 202 can be connected via the network 210 to one or more edge devices (not shown). An edge device refers to a computing device that enables communication between computing devices located at the boundary of two networks.For example, an edge device can be connected via network 210 to the host device 202, one or more data stores, and one or more server machines, and via another network to one or more endpoint devices (not shown). In such an example, the edge device can facilitate communication between the host device 202, one or more data stores, one or more server machines, and one or more client devices. In other or similar embodiments, the host device 202 can be an edge device or a component of an edge device.For example, the host device 202 can facilitate communication between one or more data storage devices, one or more server machines connected to the host device 202 via network 210, and one or more client devices connected to the host device 202 via another network.

[0086] In other or similar embodiments, the host device 202 can be an endpoint device or a component of an endpoint device. For example, the host device 202 can be a device or a component of devices such as televisions, smartphones, mobile phones, data center servers, data DPUs, PDAs (Personal Digital Assistants), portable media players, netbooks, laptops, e-book readers, tablet computers, desktop computers, set-top boxes, game consoles, a computing device for autonomous vehicles, a monitoring device, and the like. In such embodiments, the host device 202 can be connected to the DPU 204 via one or more network interfaces over the network 210.In other or similar embodiments, the host device 202 can be connected to an edge device (not shown) via a different network, and the edge device can be connected to the DPU 204 via the network 210.

[0087] In at least one embodiment, the host device 202 executes one or more computer programs. One or more computer programs can be any processes, routines, or code executed by the host device 202, such as a host operating system, an application, a guest operating system of a virtual machine, or a guest application, such as one running in a container. The host device 202 can include one or more CPUs with one or more cores, one or more multi-core CPUs, one or more GPUs, one or more hardware accelerators, or the like.

[0088] As described above, the DPU 204 can create and configure the SFC architecture 220 of network functions 222 with configurable and dynamic SFC interface mappings of multiple virtual bridges 104. Examples of the SFC architectures are related to Fig. 3, Fig. 5 and Fig. 4 illustrated and described.

[0089] Fig. Figure 3 is a block diagram of an SFC architecture 300 with a first virtual bridge 302 (labeled "BR-EXT" for external bridge), a second virtual bridge 304 (labeled "BR-INT" for internal bridge), a virtual port 306, and a network service 308 according to at least one embodiment. As described herein, the SFC logic 102 can create the first virtual bridge 302, the second virtual bridge 304, and the virtual port 306 in the SFC architecture 300. The SFC logic 102 can configure the first virtual bridge 302 to be controlled by the network service 308 hosted on the DPU 204, and the second virtual bridge 304 to be controlled by the user-defined logic 126. SFC logic 102 adds a service interface to the first virtual bridge 302 to operationally couple the network service 308 with the first virtual bridge 302.SFC logic 102 adds virtual port 306 between the first virtual bridge 302 and the second virtual bridge 304. Network service 308 can supply the first virtual bridge 302 with one or more network service rules 318. SFC logic 102 can add one or more host interfaces 310 to the second virtual bridge 304.

[0090] As illustrated, three separate host interfaces can be added to connect the second virtual bridge 304 to hosts, for example, three separate VMs hosted on host device 202. For instance, one VM might host a firewall application, another a load balancer application, and another an IDS application. SFC logic 102 can add one or more network interfaces 312 to the first virtual bridge 302. Specifically, SFC logic 102 can add a first network interface to the first virtual bridge 302 for operational coupling to a first network port 314 (labeled PORT1) of DPU 204, and a second network interface for operational coupling to a second network port 316 (labeled PORT2) of DPU 204. The first virtual bridge 302 can receive network traffic data from both the first network port 314 and the second network port 316.The first virtual bridge 302 can receive network traffic data from the first network port 314 and the second network port 316. 802.11 can forward the network traffic data via virtual port 806 to the second virtual bridge 304. The second virtual bridge 304 can then forward the network traffic data via host interface 310 to the corresponding host.

[0091] In at least one embodiment, the user-defined logic 126 is part of the second virtual bridge 304. In at least one embodiment, the user-defined logic 126 is part of a user-defined service hosted on the DPU 204, for example, a user-defined network service, a user-defined security service, a user-defined telemetry service, a user-defined storage service, or the like. The SFC logic 102 can add another service interface to the second virtual bridge 304 to operationally couple the user-defined service to the second virtual bridge 304.

[0092] In at least one embodiment, the SFC logic 102 in the second virtual bridge 304 can configure a first link state propagation between a first host interface and virtual port 306, and a second link state propagation between a second host interface and virtual port 306. Similarly, the SFC logic 102 in the second virtual bridge 304 can configure a third link state propagation between a third host interface and virtual port 306. Similar link state propagations can be configured in the first virtual bridge 302 for links between virtual port 306 and network interfaces 312.

[0093] In at least one embodiment, the SFC logic 102 can configure an OS (Operating System) property in the second virtual bridge 304. In at least one embodiment, the SFC logic 102 can configure an OS property for each of the host interfaces 310.

[0094] As described herein, the SFC 300 architecture can be created either as part of the OS installation on the DPU 204 or as part of the DPU 204 runtime. This can be done using a second configuration file or by modifying the original configuration file. Reconfiguring the DPU as part of the runtime can be done without reinstalling the OS on the DPU 204.

[0095] It should be noted that SFC logic 102 can generate different combinations of virtual bridges and interface mappings in different SFC architectures, as shown in Fig. 4 illustrated.

[0096] Fig. Figure 4 is a block diagram of an SFC architecture 400 with a first virtual bridge 302, a second virtual bridge 304, a virtual port 306, and a network service 308 according to at least one embodiment. The SFC architecture 400 is similar to the SFC architecture 300, as indicated by similar reference numerals, except that the SFC architecture 400 includes additional host interfaces 402, as described in more detail below.

[0097] As described above, SFC logic 102 can create the first virtual bridge 302, the second virtual bridge 304, and virtual port 306 in SFC architecture 400. SFC logic 102 can configure the first virtual bridge 302 to be controlled by network service 308 hosted on DPU 204, and the second virtual bridge 304 to be controlled by user-defined logic 126 (either on the second virtual bridge 304 or on a user-defined service, as described above). SFC logic 102 adds a service interface to the first virtual bridge 302 to operationally couple network service 308 with the first virtual bridge 302. SFC logic 102 adds virtual port 306 between the first virtual bridge 302 and the second virtual bridge 304. Network service 308 can supply the first virtual bridge 302 with one or more network service rules 318.SFC logic 102 can add one or more host interfaces 310 to the second virtual bridge 304 and one or more host interfaces 402 to the first virtual bridge 302.

[0098] As illustrated, two separate host interfaces can be added to connect the second virtual bridge 304 to one or more hosts (e.g., VMs or containers hosted on host device 202), and one host interface can be added to connect the first virtual bridge 302 to one host (e.g., a VM or container hosted on host device 202). In other embodiments, a different number of host interfaces can be added to multiple virtual bridges according to configuration file 124. SFC logic 102 can add one or more network interfaces 312 to the first virtual bridge 302.In particular, the SFC logic 102 of the first virtual bridge 302 can add a first network interface for operational coupling to a first network port 314 (designated PORT1) of the DPU 204 and a second network interface for operational coupling to a second network port 316 (designated PORT2) of the DPU 204. The first virtual bridge 302 can receive network traffic data from the first network port 314 and from the second network port 316.

[0099] In at least one embodiment, the SFC logic 102 in the second virtual bridge 304 can configure a first link state propagation between a first host interface and virtual port 306, and a second link state propagation between a second host interface and virtual port 306. Similarly, the SFC logic 102 in the first virtual bridge 302 can configure a third link state propagation between a third host interface and the network interfaces 312. Similar link state propagations can be configured in the first virtual bridge 302 for links between virtual port 306 and the network interfaces 312.

[0100] In at least one embodiment, the SFC logic 102 can configure an OS (Operating System) property in the second virtual bridge 304. In at least one embodiment, the SFC logic 102 can configure an OS property for each of the host interfaces 310 and an OS property for each of the host interfaces 402.

[0101] In at least one embodiment, the DPU 204 can support a configurable and dynamic interface mapping on the DPU 204 based on the SFC infrastructure. The configuration can be supported as part of the DPU OS installation and dynamically for the DPU in production. The interface configuration can support various network acceleration use cases on the DPU 204. As described above, the SFC architecture can consist of two main bridges: an external virtual bridge (BR-EXT) controlled by a network service running on the DPU 204, and an internal virtual bridge (BR-INT) controlled by a user controller (e.g., an OVN controller, as described below). Fig. (described in section 9). The interface configuration can support different requirements based on customer use cases. For example, the interface configuration can support uplink interfaces to an external virtual bridge (BR-EXT) or an internal virtual bridge (BR-INT), host interfaces to the external or internal virtual bridges, and additional services connected to the internal virtual bridge (BR-INT), such as security services, telemetry services, or the like. The interface configuration can support SFs (Scalable Functions) configurations. The interface configuration can support link propagation and various OS attributes (e.g., HUGEPAGE_SIZE, HUGEPAGE_COUNT, etc.).

[0102] The following example shows a configuration file.

[0103] As described herein, the SFC 400 architecture can be created either as part of the OS installation on the DPU 204 or as part of the DPU 204 runtime. This can be done using a second configuration file or by modifying the original configuration file. Reconfiguring the DPU as part of the runtime can be done without reinstalling the OS on the DPU 204.

[0104] It should be noted that SFC logic 102 can generate different combinations of virtual bridges and interface mappings in different SFC architectures, as shown in Fig. 3 and Fig. 4 illustrated. For comparison, illustrated. Fig. 5 a non-SFC architecture 500 that allows only one network service to control a single virtual bridge between the hosts and the network.

[0105] Fig. Figure 5 is a block diagram of a non-SFC architecture 500 with a single virtual bridge 502 and a single network service 504 according to at least one embodiment. The single virtual bridge 502 can include multiple host interfaces 506, a service interface operationally coupled to the single network service 504, and two network interfaces 508. The single virtual bridge 502 is controlled by the single network service 504 by means of one or more network service rules 510. The network service 508 can provide one or more network service rules 518 through the service interface to configure the single virtual bridge 502. The single virtual bridge 502 can route network traffic data between the host device 502 (e.g., multiple VMs) and the first network port 314 and the second network port 316 of the DPU 504.The single virtual bridge 502 and the single network service 504 are limited in providing additional networking capabilities beyond those provided by the single network service 504.

[0106] Fig. Figure 6 is a flowchart of an exemplary method 600 for configuring an SFC architecture with multiple virtual bridges and interface mappings according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled with a switch. In at least one embodiment, the method 600 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method.In at least one embodiment, the processing threads implementing Method 600 can be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing Method 600 can be executed asynchronously. Different operations of Method 600 can be performed differently than in the [reference to be added]. Fig. The procedures are performed in the sequence shown in section 6. Some operations of the procedures can be performed simultaneously with other operations. In at least one embodiment, one or more of the following are performed: Fig. The 6 operations shown may not always be performed.

[0107] With reference to Fig. 6. The processing logic begins by storing a configuration file that specifies multiple virtual bridges and interface mappings for those multiple virtual bridges (block 602). In block 604, according to the configuration file, the processing logic creates a first virtual bridge and a second virtual bridge of the multiple virtual bridges, where the first virtual bridge is controlled by a first network service hosted on the DPU, and the second virtual bridge is controlled by user-defined logic. In block 606, according to the configuration file, the processing logic adds one or more host interfaces to the second virtual bridge. In block 608, according to the configuration file, the processing logic adds a first service interface to the first virtual bridge to establish an operational coupling with the first network service.In block 610, the processing logic adds one or more virtual ports between the first virtual bridge and the second virtual bridge, according to the configuration file. In block 612, the processing logic adds one or more network ports (uplink ports) to the first virtual bridge and / or the second virtual bridge, according to the configuration file.

[0108] In a further embodiment, method 600 further comprises adding, by the processing logic, according to the configuration file, a first network interface to the first virtual bridge for operational coupling with a first network port of the DPU, a second network interface to the first virtual bridge for operational coupling with a second network port of the DPU, a first host interface of the one or more host interfaces to the second virtual bridge for operational coupling with a host device, and adding, according to the configuration file, a second host interface of the one or more host interfaces to the second virtual bridge for operational coupling with the host device.Procedure 600 further includes the configuration by the processing logic, according to the configuration file, of a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports, and a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.

[0109] In a further embodiment, method 600 further comprises adding, by the processing logic according to the configuration file, a first network interface to the first virtual bridge for operational coupling with a first network port of the DPU, a second network interface to the first virtual bridge for operational coupling with a second network port of the DPU, a first host interface of one or more host interfaces to the second virtual bridge for operational coupling with a first host device, and a second host interface of one or more host interfaces to the second virtual bridge for operational coupling with a second host device. The first host device is a virtual machine and / or a container, and the second host device is a virtual machine and / or a container.In a further embodiment, method 600 further comprises the configuration by the processing logic, according to the configuration file, of a first link state propagation in the second virtual bridge between the first host interface and the one or more virtual ports and a second link state propagation in the second virtual bridge between the second host interface and the one or more virtual ports.

[0110] In a further embodiment, method 600 further comprises installing, by means of the processing logic, an OS to be executed on the processing device of the DPU. The processing logic generates the multiple virtual bridges, and the interface mappings of the multiple virtual bridges are part of the installation of the OS on the DPU.

[0111] In a further embodiment, method 600 further comprises installing, by the processing logic, an operating system to be executed on the processing device of the DPU. The processing logic generates the multiple virtual bridges, and the interface mappings of the multiple virtual bridges are part of the DPU's runtime and do not require reinstallation of the operating system on the DPU. FLEXIBLE CONTROL RULES IN SFC ARCHITECTURES

[0112] Control rules are essential components in network and traffic management, defining how data packets are routed through a network based on specific rules. These rules can be applied in various contexts, including load balancing, security, compliance, and network resource optimization. Some common types of control rules are described below.

[0113] Source IP-based routing focuses on routing traffic based on the origin of the IP address. This can be crucial for managing traffic from specific regions or known addresses and is useful for localization, imposing geographic restrictions, or improving security. Destination IP-based routing, on the other hand, targets the intended endpoint of the traffic and allows networks to channel traffic to specific data centers or cloud regions based on the destination IP address.

[0114] Port-based control uses TCP or UDP port numbers to route specific traffic types, such as HTTP or FTP (File Transfer Protocol), to resources best suited to handle them, thereby optimizing both performance and security. Application-aware control goes even deeper, examining packets to identify the application generating the traffic and routing different types of application traffic over paths optimized for their specific requirements, such as low latency or high bandwidth.

[0115] Load-based control directs traffic based on the current load or capacity of network paths, often in conjunction with load balancers, to distribute the load evenly and prevent individual resources from becoming bottlenecks. Time-based control is effective for managing network loads at different times of day or week, routing traffic to alternative resources during peak times to maintain performance.

[0116] Protocol-based routing makes decisions based on the specific protocols used, such as HTTP or HTTPS, ensuring that traffic is handled according to its specific requirements. Content- or data-type-based routing examines the content of packets and directs types like video or text to processing services optimized for those data types, thereby improving content delivery.

[0117] User identity-based control directs network traffic based on the user's identity or role, enabling networks to offer differentiated services or enforce security policies tailored to specific user profiles.

[0118] Combinations of these control rules can form a comprehensive approach to managing data traffic in complex environments such as data centers, cloud networks, and large enterprises, ensuring efficient resource utilization and maintaining robust performance and security standards across the network.

[0119] Previous solutions could not provide flexible control rules in a single accelerated data plane on a DPU. Aspects and embodiments of the present disclosure can provide flexible control rules in a single accelerated data plane on a DPU. Aspects and embodiments of the present disclosure can provide hardware-accelerated flexible control rules via an SFC architecture, as described below with respect to Fig. 7 to Fig. 10 described.

[0120] Fig. Figure 7 is a block diagram of an exemplary DPU-based SFC infrastructure 700 for providing hardware-accelerated rules for an SFC architecture 220 according to at least one embodiment. The DPU-based SFC infrastructure 700 is similar to the DPU-based SFC infrastructure 200, as indicated by similar reference numbers, except that the DPU-based SFC infrastructure 700 includes hardware-accelerated rules 708 derived from network rules from various sources in 220 and accelerated on the single accelerated data plane 702 of the acceleration hardware engine 214, as described in more detail below.

[0121] The acceleration hardware engine 214 can provide a single accelerated data plane 702 for the SFC architecture 220. The memory 218 can store the configuration file 124, which specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first and second virtual bridges. The SFC logic 102 can create the first virtual bridge according to the configuration file 124. This first virtual bridge is controlled by a first network service hosted on the DPU 204 and has a first set of one or more network rules 704.The first set of one or more network rules 704 can include an L2 (Layer 2) protocol rule, an L3 (Layer 3) protocol rule, a tunneling protocol rule, an ACL (Access Control List) rule, an ECMP (Equal-Cost Multi-Path) rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT (Connection Tracking) rule, a VLAN (Virtual Local Area Network) rule, a NAT (Network Address Translation) rule, or the like.

[0122] The SFC logic 102 can, according to the configuration file 124, create the second virtual bridge with a second set of one or more user-defined network rules 706. In at least one embodiment, the user-defined network rules 706 are programmable by a user or a controller. The user-defined network rules 706 can include an L2 protocol rule, an L3 protocol rule, a tunneling protocol rule, an ACL rule, an ECMP rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT rule, a VLAN rule, a NAT rule, or the like. In at least one embodiment, the network rules 704 can include a first set of control rules for the first virtual bridge, and the user-defined network rules 706 can include a second set of control rules for the second virtual bridge.The control rules can be application-based control rules, policy-based control rules, geolocation-based control rules, load balancing rules, QoS rules, failover rules, redundancy rules, security-based control rules, cost-based routing rules, SD-WAN (Software-Defined Wide Area Network) path control rules, SDN (Software-Defined Networking) rules, or the like.

[0123] SFC logic 102 can add the virtual port between the first virtual bridge and the second virtual bridge, as described in section 124. SFC logic 102 can also generate a combined set of network rules based on the first set of one or more network rules 704 and the second set of one or more user-defined network rules 706. This combined set of rules can be added as hardware-accelerated rules 708 to the single accelerated data plane 702. The acceleration hardware engine 214 can process network traffic data 212 in the single accelerated data plane 702 using the hardware-accelerated rules 708 (i.e., the combined set of network rules).

[0124] In at least one embodiment, the virtual bridges 104, including the first and second virtual bridges described above, are OVS (Open vSwitch) bridges. The DPU 204 can run an OVS application with hardware offload mechanisms to provide the single accelerated data plane 702 in the acceleration hardware engine 214 to process the network traffic data 212 based on the hardware-accelerated rules 708 (i.e., the combined set of network rules).

[0125] In at least one embodiment, the SFC logic 102 can add one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU, and add one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU. The SFC logic 102 can add a first service interface to the first virtual bridge for operational coupling with the first network service and a second service interface to the second virtual bridge for operational coupling of a second network service. The first network service and the second network service can be part of the SFC architecture 220 of the DPU-based SFC infrastructure 700. The first network service and the second network service can utilize accelerated network capabilities in the single accelerated data plane 702 by means of the hardware-accelerated rules 708 (i.e.,provide the combined set of network rules.

[0126] As described above, the DPU 204 can create and configure the SFC architecture 220 of network functions 222 with hardware-accelerated rules in a single accelerated data plane of an SFC infrastructure. Examples of the SFC architectures are related to: Fig. 8 and Fig. 9 illustrated and described.

[0127] Fig. Figure 8 is a block diagram of an SFC Architecture 800 with flexible hardware-accelerated rules for a single accelerated data plane according to at least one embodiment. The SFC Architecture 800 is similar to the SFC Architecture 300, but uses different reference numbers. The SFC Architecture 800 includes a first virtual bridge 802 (labeled "OVS BR-1"), a second virtual bridge 804 (labeled "OVS BR-2"), a virtual port 806, and a network service 808. As described herein, the SFC Logic 102 can create the first virtual bridge 802, the second virtual bridge 804, and the virtual port 806 in the SFC Architecture 800.SFC logic 102 can configure the first virtual bridge 802 to be controlled by network service rules 814 provided by network service 808 hosted on DPU 204, and configure the second virtual bridge 804 to be controlled by user-defined network rules 816. SFC logic 102 adds a service interface to the first virtual bridge 802 for operational coupling of network service 808 to the first virtual bridge 802. SFC logic 102 adds virtual port 806 between the first virtual bridge 802 and the second virtual bridge 804. Network service 808 can provide the first virtual bridge 802 with one or more network service rules 814. User-defined logic 126 can provide the second virtual bridge 804 with one or more user-defined network rules 816.The SFC logic 102 can add one or more host interfaces 310 to the second virtual bridge 804.

[0128] As illustrated, three separate host interfaces can be added to connect the second virtual bridge 804 to hosts, for example, three separate VMs hosted on host device 202. For instance, one VM could host a firewall application, another a load balancer application, and another an IDS application. SFC logic 102 can add one or more network interfaces 812 to the first virtual bridge 802. Specifically, SFC logic 102 can add a first network interface to the first virtual bridge 802 for operational coupling to a first network port 314 (labeled PORT1) of DPU 204 and a second network interface for operational coupling to a second network port 316 (labeled PORT2) of DPU 204. The first virtual bridge 802 can receive network traffic data from both the first network port 314 and the second network port 316.The first virtual bridge 802 can route network traffic data via virtual port 806 to the second virtual bridge 804. The second virtual bridge 804 can route network traffic data via host interface 810 to the corresponding host.

[0129] In at least one embodiment, the user-defined network rules 816 can be provided by a user 818. The user 818 can provide the user-defined network rules 816 using the user-defined logic 126. The user 818 can program the second virtual bridge 804 with the user-defined network rules 816. Alternatively, the user-defined logic 126 can receive user input from 818, and the user-defined logic 126 can generate the user-defined network rules 816 and provide them to the second virtual bridge 804. In another embodiment, the user-defined network rules 816 can be provided by a user-defined service or another network service, separately from the network service 808.The other network service (or custom service) can be a custom network service, a custom security service, a custom telemetry service, a custom storage service, or the like, hosted on DPU 204 or as applications on host device 202. If the custom network rules 816 are provided by a second network service, SFC logic 102 can add another service interface to the second virtual bridge 804 to operationally couple the second network service to the second virtual bridge 804.

[0130] The DPU 204 can combine network rules according to the various network services to obtain a combined set of network rules that can be accelerated in a single accelerated data plane 702 of the DPU 204. This combined set of network rules becomes hardware-accelerated rules that are accelerated by the DPU 204 for the SFC 800 architecture.

[0131] In at least one embodiment, the DPU 204 provides a DPU service that supports HBN (Host Based Networking) as a network service 808 for accelerating L2 / L3 / tunneling protocols on the DPU 204. The HBN infrastructure is based on an SFC topology in which an OVS bridge is controlled by the HBN service, which provides all the accelerated networking capabilities. As described above, the second OVS bridge (second virtual bridge 804) can be programmed by the user 818 or another controller (as in Fig. (9 illustrated). The HBN service can support various protocols and network capabilities, such as ACLs, ECMP, tunneling, CT, and more. The user (818) can flexibly program various control rules in parallel with the HBN service via the SFC architecture (800), resulting in hardware-accelerated rules (708) for the single accelerated data plane (702) provided by OVS-DOCA and the DPU hardware. Using the SFC infrastructure, users and customers can utilize the DPU (204) as a network accelerator on an edge device without the need for complex and intelligent switches in various network topologies within a DC network or an SP network.

[0132] It should be noted that the SFC logic can generate 102 different combinations of hardware-accelerated rules in different SFC architectures, as shown in Fig. 9 illustrated.

[0133] Fig. Figure 9 is a block diagram of an SFC 900 architecture with flexible hardware-accelerated rules for a single accelerated data plane according to at least one embodiment. The SFC 900 architecture is similar to the SFC 800 architecture, as indicated by similar reference numbers, except that in the SFC 900 architecture, the user-defined network rules 816 are received by a controller 902, such as an OVN (Open Virtual Network) controller. OVN is an open-source project designed to provide network virtualization solutions, enabling the creation and management of a virtual network infrastructure in cloud and data center environments. It is an extension of the OVS project, leveraging its underlying technology to offer advanced network automation and scalability capabilities for virtualized networks.OVN aims to simplify the process of setting up and managing virtual network components such as virtual switches, routers, firewalls, and load balancers. It enables the dynamic creation of these components via software, eliminating the need for manual configuration of physical network hardware. This facilitates the deployment of highly flexible and scalable networks that can easily adapt to the changing requirements of applications and services running in virtualized environments. OVN abstracts the physical network, allowing users to define logical networks that are mapped to the underlying physical infrastructure. This abstraction layer simplifies network design and management by enabling the use of high-level constructs such as logical switches and routers. Through integration with orchestration systems (e.g.,OpenStack) supports OVN for the automated provisioning and configuration of network resources based on the requirements of deployed applications and services for automated network management. OVN offers a range of network services, including virtual L2 / L3 networks, access control policies, NAT, and more, providing the necessary functionality to support complex network topologies for advanced network services. With OVN, it is possible to create isolated virtual networks and apply security policies and rules at the logical level to ensure that only authorized traffic flows between different parts of the network. OVN is designed to efficiently scale with network size and the number of virtualized workloads to minimize the impact on performance as networks grow.OVN is a tool for organizations that want to leverage the benefits of network virtualization and are looking for an efficient and flexible approach to managing virtual network infrastructures in modern cloud and data center environments. In another implementation, the Controller 902 can be a different type of controller, for example, a controller for a specific network service provided in the SFC 900 architecture.

[0134] Fig. Figure 10 is a flowchart of an exemplary method 1000 for configuring an SFC architecture with flexible hardware-accelerated rules for acceleration on a single accelerated data plane of a DPU according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled with a switch. In at least one embodiment, the method 1000 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method.In at least one embodiment, the processing threads implementing Method 1000 can be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing Method 1000 can be executed asynchronously. Different operations of Method 1000 can be performed differently than described in [reference to relevant section]. Fig. The procedures are performed in the sequence shown in section 10. Some operations of the procedures can be performed simultaneously with other operations. In at least one embodiment, one or more of the following are performed: Fig. The 10 operations shown may not always be performed.

[0135] With reference to Fig. 10. The processing logic begins by storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and a virtual port between the first and second virtual bridges (block 1002). In block 1004, the processing logic creates the first and second virtual bridges according to the configuration file. The first virtual bridge is controlled by a first network service hosted on the DPU and has a first set of one or more network rules, and the second virtual bridge has a second set of one or more user-defined network rules. In block 1006, the processing logic adds the virtual port between the first and second virtual bridges, according to the configuration file.In block 1008, the processing logic adds one or more network ports (uplink ports) to the first virtual bridge and / or the second virtual bridge, according to the configuration file. In block 1010, the processing logic generates a combined set of network rules based on the first set of one or more network rules and the second set of one or more user-defined network rules, also according to the configuration file. In block 1012, the processing logic uses the acceleration hardware engine to process network traffic data in the single accelerated data layer based on this combined set of network rules.

[0136] In a further embodiment, the method 1000 can further include the processing logic adding, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU, as well as a first service interface to the first virtual bridge for operational coupling with the first network service. The first network service can provide accelerated networking capabilities based on the first set of one or more network rules, wherein the first set of one or more network rules comprises one or more L2 protocol rules, L3 protocol rules, tunneling protocol rules, ACL rules, ECMP rules, tunneling encapsulation rules, tunneling decapsulation rules, CT rules, VLAN rules, NAT rules, or the like.

[0137] In a further embodiment, the method 1000 can further include the processing logic adding one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices that are operationally coupled to the DPU, according to the configuration file, and receiving user input from a user or controller, wherein the user input specifies the second set of one or more user-defined network rules, the second set of one or more user-defined network rules comprising one or more control rules. The processing logic can add the second set of one or more user-defined network rules to the second virtual bridge, according to the configuration file.In at least one embodiment, the one or more control rules comprise one or more application-based control rules, policy-based control rules, geolocation-based control rules, load balancing rules, QoS rules, failover rules, redundancy rules, safety-based control rules, cost-based routing rules, SD-WAN path control rules, SDN (Software-Defined Networking) rules, or the like.

[0138] In a further embodiment, the method 1000 can also include the processing logic adding, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU and a first service interface to the first virtual bridge for operational coupling with the first network service, wherein the first network service provides accelerated network functions. The first set of one or more network rules includes at least one ACL rule, one ECMP rule, one tunneling rule, one CT rule, one QoS rule, one STP rule, one VLAN rule, one NAT rule, one SDN rule, one MPLS rule, or the like.

[0139] In a further embodiment, the method 1000 may also include the processing logic adding, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally connected to the DPU, as well as one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU. In a further embodiment, the method 1000 may also include the processing logic adding, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service.In a further embodiment, the method 1000 may also include the processing logic adding a second service interface to the second virtual bridge for operational coupling with a second network service, according to the configuration file, wherein the first network service and the second network service are part of an SFC infrastructure to provide accelerated network capabilities in the single accelerated data plane based on the combined set of network rules. Creating an optimized and accelerated network pipeline using NAPL (Network Pipeline Abstraction Layer)

[0140] A Database Abstraction Layer (DAL) is a software component that provides a unified interface for interacting with various types of database systems, enabling applications to perform database operations without using database-specific syntax. The DAL acts as an intermediary between the application and the database, translating the application's data access requests into the appropriate queries for the underlying database. By abstracting away the intricacies of the database system, the DAL allows developers to write database-agnostic code, thereby improving application portability and scalability.This layer can support various database operations, including creating, reading, updating, and deleting records, and can be implemented in various forms, such as ORM (Object-Relational Mapping) libraries, which further simplify data manipulation by allowing data to be handled in the form of objects.

[0141] As described herein, an integrated circuit (e.g., a DPU) can provide a Network Pipeline Abstraction Layer (NPAL) similar to a Data Access Layer (DAL). The NPAL is a software-programmable layer that provides an optimized and accelerated network pipeline supporting various accelerated network capabilities, such as L2 bridging, L3 routing, tunnel encapsulation, tunnel decapsulation, hash computations, ECMP operations, static and dynamic ACLs, CT, and more. The NPAL can include a set of APIs or classes that provide a unified interface for performing common network operations within a network pipeline optimized for hardware acceleration on an acceleration hardware engine.The network pipeline can include a set of tables and logic in a specific order, with the network pipeline being optimized for acceleration by an acceleration hardware engine of a DPU hardware, thereby providing customers and users with a rich set of capabilities and high performance.

[0142] Using an NPAL in the DPU can offer several advantages, including operational independence, logic encapsulation, performance, code reusability, platform independence, and more. For example, developers can write agnostic code, allowing applications (such as network services) with different underlying access logic and network functionality to operate. The NPAL can encapsulate the access or network-related logic, simplifying codebase management and maintenance. Changes to the schema or underlying technology can be isolated within the NPAL implementation. The NPAL can provide an optimized and high-performance pipeline to meet diverse networking requirements and functionalities.By separating access logic from application logic, developers can reuse NPAL components across multiple parts of the application (network service), promoting code reusability and maintainability. NPAL can abstract away platform-specific differences, data types, and other access- or network-function-related characteristics, allowing the application (network service) to run seamlessly across different platforms and environments. Overall, NPAL can be a powerful tool for developing flexible, scalable, and maintainable network-function-driven applications, providing a level of abstraction that simplifies interactions between network functions and promotes code efficiency and portability.

[0143] In at least one embodiment, the DPU comprises DPU hardware, including a processing device and an acceleration hardware engine. The DPU includes a memory that is operationally coupled to the DPU hardware. The memory can store DPU software, including an NPAL that supports multiple network protocols and network functions in a network pipeline. The network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine. The acceleration hardware engine can process network traffic data using the network pipeline. The network pipeline can be optimized for network services running on the DPU.

[0144] Fig. Figure 11 is a block diagram of an exemplary computing system 1100 comprising a DPU 1104 with an NPAL 1114 for providing an optimized and accelerated network pipeline, which is to be accelerated by an acceleration hardware engine 1116 according to at least one embodiment. The computing system 1100 includes the DPU 1104, which is coupled between a host device 1102 and a network 1110. The host device 1102 and the DPU 1104 can be similar to the host device 202 and the DPU 204 of the DPU-based SFC infrastructure 200 and the DPU-based SFC infrastructure 700 described above, unless expressly stated otherwise.

[0145] In at least one embodiment, the DPU 1104 comprises DPU hardware 1108 and DPU software 1106 (e.g., a software framework with acceleration libraries). The DPU hardware 208 can comprise one or more CPUs (e.g., a single-core or multi-core CPU), an acceleration hardware engine 1116 (or multiple hardware accelerators), memory, and network and host connections. In at least one embodiment, the DPU 1104 comprises DPU software 1106, including a software framework and acceleration libraries. The software framework and acceleration libraries can include one or more hardware-accelerated services, including a hardware-accelerated service (e.g., NVIDIA DOCA), hardware-accelerated virtualization services, hardware-accelerated networking services, hardware-accelerated storage services, hardware-accelerated AI / ML services, hardware-accelerated service, and hardware-accelerated management services.The DPU software 1106 also includes NPAL 1114. NPAL 1114 can comprise a set of APIs or classes that provide a unified interface for performing common network operations in a network pipeline optimized for hardware acceleration on an acceleration hardware engine 1116. This set of APIs or classes can provide a unified interface to one or more applications, network services, or other logic executed by the DPU 1104, the host device 1102, or both. The network pipeline can comprise a set of tables and logic in a specific order, optimized for acceleration by an acceleration hardware engine 1116 of the DPU hardware 1108.

[0146] During operation, the DPU hardware 1108 can receive network traffic data 1112 from the network 1110 and process the network traffic data 1112 using the optimized and accelerated network pipeline programmed by the NPAL 1114. As described herein, the NPAL 1114 supports multiple network protocols and network functions in a network pipeline. The network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine 1116. The acceleration hardware engine 1116 can process network traffic data 1112 using the network pipeline. In at least one embodiment, the network pipeline comprises an inbound port, a dynamic or static ingress ACL (access control list), a bridge, a router, a dynamic or static egress ACL, and an outbound port.Examples of the optimized and accelerated network pipelines are given below using . Fig. 12, Fig. 13 and Fig. 14 illustrated and described.

[0147] Fig. Figure 12 is a network diagram of an exemplary network pipeline 1200, which is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment. The network pipeline 1200 comprises an input port 1202, a filtering network function 1204, an ingress port 1206, a first network function 1208, a bridge 1210, SVI (Switched Virtual Interface) ACLs 1212, a router 1214, a second network function 1216, an egress port 1218, and an output port 1220. The input port 1202 can receive network traffic data and feed it to the filtering network function 1204, which is operationally coupled to the input port 1202. The filtering network function 1204 can filter the network traffic data. Ingress port 1206 is operationally coupled with filtering network function 1204, and ingress port 1206 is operationally coupled with first network function 1208.The first network function 1208 can process network traffic data using one or more ingress ACLs. Bridge 1210 is operationally coupled to the first network function 1208. Bridge 1210 can perform a Layer 2 bridging operation. One or more SVI ACLs are operationally coupled to Bridge 1210 and Router 1214. Router 1214 can perform a Layer 3 routing operation. The second network function 1216 is operationally coupled to Router 1214. The second network function 1216 can process network traffic data using one or more egress ACLs. Egress port 1218 is operationally coupled to the second network function 1216. Egress port 1218 is operationally coupled to the outbound port 1220. The output port 1220 can output network traffic data.

[0148] Fig. Figure 13 is a network diagram of an exemplary network pipeline optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment. The network pipeline 1300 comprises an input port 1302, a filtering network function 1304, an ingress port with a first network function 1306, a second network function 1308, a bridge 1310, SVI ACLs 1312, a router 1314, a third network function 1316, an egress port with a fourth network function 1318, and an output port 1320. The input port 1302 can receive network traffic data and feed it to the filtering network function 1304, which is operationally coupled to the input port 1302 via a first filtering network function 1304. The filtering network function 1304 can filter the network traffic data and feed the network traffic data to the ingress port with the first network function 1306.The first network function 1306 can perform an initial VLAN (Virtual Local Area Network) mapping for the network traffic data and forward the data to the second network function 1308 (or alternatively, to bridge 1310). The second network function can process the network traffic data using one or more ingress ACLs (Access Control Lists). The ingress ACLs can be dynamic or static. Bridge 1310 is operationally coupled to the first network function and the second network function 1308. Bridge 1310 can perform a Layer 2 bridging operation. The SVI ACLs are operationally coupled to bridge 1310 and router 1314. Router 1314 can perform a Layer 3 routing operation. The third network function 1316 is operationally coupled to router 1314. The third network function 1316 can process network traffic data using one or more egress ACLs.Egress ACLs can be dynamic or static. The egress port with the fourth network function 1318 is operationally coupled to the third network function 1316. The fourth network function can perform a second VLAN mapping on the network traffic data. The output port 1320 is operationally coupled to the egress port with the fourth network function 1318. The output port 1320 can output the network traffic data.

[0149] Fig. Figure 14 is a network diagram of an exemplary network pipeline 1400, optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL according to at least one embodiment. The network pipeline 1400 comprises an input port 1402, a first network function 1404, a second network function 1406, a third network function 1408, a fourth network function 1410, a fifth network function 1412, a sixth network function 1414, a seventh network function 1416, and an output port 1418. The network pipeline 1400 can include any combination of network functions in a specific order, with each network function comprising logic and / or tables to implement the respective network function and to forward the network traffic data to the subsequent network function.In at least one embodiment, the first network function 1404 can perform L2 (Layer 2) bridging, the second network function 1406 can perform L3 (Layer 3) routing, the third network function 1408 can perform tunnel encapsulation or tunnel decapsulation, the fourth network function 1410 can perform a hash calculation, the fifth network function 1412 can perform an ECMP operation, the sixth network function 1414 can perform a CT operation, and the seventh network function 1416 can perform a NAT operation. Alternatively, the network pipeline 1400 between the input port 1402 and the output port 1418 can include a different number and different types of network operations.

[0150] Fig. Figure 15 is a flowchart of an exemplary method 1500 for generating an optimized and accelerated network pipeline using a Network Pipeline Abstraction Layer (NPAL) according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled to a switch. In at least one embodiment, the method 1500 can be executed by multiple processing threads, each thread performing one or more individual functions, routines, subroutines, or operations of the method.In at least one embodiment, the processing threads implementing Method 1500 can be synchronized (e.g., using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, the processing threads implementing Method 1500 can be executed asynchronously. Different operations of Method 1500 can be performed differently than described in [reference to relevant document]. Fig. The sequence shown in section 15 is performed. Some operations of the methods can be performed simultaneously with other operations. In at least one embodiment, one or more of the following are performed: Fig. The 15 operations shown were not always performed.

[0151] With reference to Fig. 15. The processing logic begins by executing one or more instructions from a Network Pipeline Abstraction Layer (NPAL), which supports multiple network protocols and network functions in a network pipeline (Block 1502). The network pipeline comprises a set of tables and logic organized in a specific sequence to be accelerated by the DPU's acceleration hardware engine. In Block 1504, the processing logic receives network traffic data over a network. In Block 1506, the processing logic uses the DPU's acceleration hardware engine to process the network traffic data using the network pipeline.

[0152] In at least one embodiment, the network pipeline includes the ports and network functions described above in relation to Fig. 12, Fig. 13 and Fig. 14 are described. NPAL-supporting split interfaces

[0153] Fig. Figure 16 is a block diagram of a software stack 1600 of a DPU with an NPAL 1602 that supports shared interfaces according to at least one embodiment. As described above, the DPU must be designed to support port splitting in both hardware and software. From a hardware perspective, the DPU hardware includes a network connection, including one or more physical ports coupled to a network, a host connection connected to a host device, and an acceleration hardware engine. The network connection includes a physical port 1614 (or multiple physical ports) configured to couple to a breakout cable 1616, which is physically connected to a set of multiple devices. The breakout cable 1616 physically separates the data streams associated with each device.In high-speed network environments, particularly in data centers, it is common to use breakout cables to split a single high-speed port (e.g., 40 Gbps or 100 Gbps) into multiple lower-speed ports (e.g., 4 × 10 Gbps or 4 × 25 Gbps). These breakout cables physically separate the data streams, allowing multiple devices or ports to connect to a single high-speed interface. The DPU hardware may include additional hardware such as a processing device (e.g., one or more CPU cores), one or more GPUs, switches, memory, or similar components. It's also worth noting that the DPU hardware may have a second physical port, which is likewise split by a second breakout cable, physically connected to a second set of devices.

[0154] From a software perspective, the Software Stack 1600 can support logically partitioned ports via a single physical port 1614. The Software Stack 1600 can be stored in the DPU's memory. It comprises Firmware 1606, Driver 1608, Virtual Switch 1612, and NPAL 1602. Firmware 1606 can interact with the DPU hardware 1604 and Driver 1608. Driver 1608 can interact with Firmware 1606 and Virtual Switch 1612. NPAL 1602 can reside on Virtual Switch 1612. The software stack 1600 can consist of commands which, when executed by the DPU hardware, can provide the NPAL 1602, which supports multiple network protocols and network functions in a network pipeline for a set of logically split ports 1610. Each logically split port 1610 corresponds to a device in a set of devices.As described above, the network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine.

[0155] In at least one embodiment, the firmware 1606 can be configured to create multiple logically partitioned ports 1610 as physical functions (PFs) and map physical lanes of physical port 1614 to the various logically partitioned ports 1610. In at least one embodiment, the firmware 1606 and the driver 1608 can provide multiple logically partitioned ports 1610 as PFs for the virtual switch 1612 and NPAL 1602. The NPAL 1602 can be configured to manage each of the PFs as a separate physical port, although they are supported via the single physical port 1614.

[0156] The NPAL 1602 can configure different policies for the various logically split ports. In at least one embodiment, a first logically split port is configured with a first policy, and a second logically split port is configured with a second policy that differs from the first. As described herein, the NPAL 1602 includes a set of APIs or classes that provide a unified interface to one or more applications running on the processing device or a host device coupled to the DPU. The NPAL 1602 can be used to define the different policies for the different logically split ports.The NPAL 1602 can be used to configure the network pipeline to execute a first network function for a first logically split port (first PF) and a second network function for a second logically split port (second PF), where the second network function differs from the first. For example, the network pipeline can be configured with different policies per PF, such as different QoS requirements, different traffic management, or the like. In at least one embodiment, the different network functions can include L2 bridging, L3 routing, tunnel encapsulation, tunnel decapsulation, hash calculations, ECMP operations, static and dynamic ACLs, CT, etc. Similarly, different network functions can be executed for the other logically split ports (other PFs).Once configured, the DPU hardware can process network traffic data using the network pipeline.

[0157] As in Fig. As shown in Figure 16, firmware 1606 creates a first logically split port, a second logically split port, a third logically split port, and a fourth logically split port because breakout cable 1616 is coupled to four separate devices. For example, physical port 1614 can support 100 Gbps (or 40 Gbps) network traffic data, which is "split" into multiple lower-speed logical ports of 4 x 25 Gbps (or 4 x 10 Gbps). Once physical port 1614 is physically and logically split, the network pipeline can send network traffic data to each logically split port 1610 (i.e., to each PF) as part of the output port logic.

[0158] Creating and using multiple PFs for a single physical port 1614 can be used to isolate the networking between the PFs, achieve better resource utilization, support more than two PFs instead of just one or more, and so on. In at least one embodiment, the NPAL 1602 is configured to configure a first logically split port with a first policy and a second logically split port with a second policy that differs from the first policy. Similarly, the NPAL 1602 can configure a third logically split port with a third policy and a fourth logically split port with a fourth policy. The NPAL 1602 can configure multiple logically split ports with the same policy. In at least one embodiment, the NPAL 1602 is configured to isolate the networking between the multiple PFs.In at least one embodiment, the set of logically partitioned ports 1610 comprises two or more logical partitions (i.e., a number of logically partitioned ports greater than two). The NPAL 1602 can provide customers or users with a rich set of capabilities, high performance, and flexibility when breakout cables are connected to the physical ports of the DPU.

[0159] In at least one embodiment, the network pipeline comprises an inbound port, a dynamic or static ingress ACL, a bridge, a router and a dynamic or static egress ACL, and an outbound port with multiple logically partitioned ports 1610.

[0160] In at least one embodiment, the network pipeline comprises an input port for receiving network traffic data via physical port 1614. The network pipeline includes a filtering network function operationally coupled to the input port, wherein the filtering network function filters the network traffic data. The network pipeline includes an ingress port operationally coupled to the filtering network function and a first network function operationally coupled to the ingress port, wherein the first network function processes the network traffic data based on one or more ingress ACLs (Access Control Lists). The network pipeline includes a bridge operationally coupled to the first network function, wherein the bridge performs a Layer 2 bridging operation, and one or more SVI ACLs (e.g., static or dynamic) operationally coupled to the bridge.The network pipeline includes a router operationally coupled to the SVI ACLs (e.g., statically or dynamically), where the router performs a Layer 3 routing operation. The network pipeline includes a second network function operationally coupled to the router, where the second network function processes the network traffic data based on one or more egress ACLs. The network pipeline includes an egress port operationally coupled to the second network function and an output port with the set of logically split ports 1610 for outputting the network traffic data. As described above, once physical port 1614 is logically and physically split, the network traffic data can be sent to one of the logically split ports 1610.

[0161] In at least one embodiment, the network pipeline comprises an input port for receiving network traffic data via physical port 1614. The network pipeline includes a filtering network function operationally coupled to the input port, wherein the filtering network function filters the network traffic data. The network pipeline includes an ingress port operationally coupled to the filtering network function, wherein the ingress port has a first network function to perform a first VLAN mapping on the network traffic data. The network pipeline includes a second network function operationally coupled to the ingress port, wherein the second network function processes the network traffic data based on one or more ingress ACLs.The network pipeline includes a bridge operationally coupled to the second network function, where the bridge performs a Layer 2 bridging operation, and one or more SVI ACLs (e.g., static or dynamic) operationally coupled to the bridge. The network pipeline includes a router operationally coupled to the SVI ACLs (e.g., static or dynamic), where the router performs a Layer 3 routing operation. The network pipeline includes a third network function operationally coupled to the router, where the third network function processes the network traffic data based on one or more egress ACLs. The network pipeline includes an egress port operationally coupled to the third network function, where the egress port includes a fourth network function for performing a second VLAN mapping on the network traffic data.The network pipeline includes an output port with a set of logically split ports 1610 for outputting network traffic data. As described above, after the logical and physical splitting of physical port 1614, the network traffic data can be sent to any of the logically split ports 1610.

[0162] In at least one embodiment, the network pipeline comprises two or more of the following network functions: a first network function for performing L2 bridging; a second network function for performing L3 routing; a third network function for performing tunnel encapsulation or tunnel decapsulation; a fourth network function for performing hash computation; a fifth network function for performing an ECMP operation; a sixth network function for performing a CT operation; or a seventh network function for performing a NAT operation. An example of a network pipeline is described below with respect to Fig. 17 are shown and described.

[0163] Fig. Figure 17 is a network diagram of an exemplary network pipeline 1700, which is optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL that supports shared interfaces according to at least one embodiment. The network pipeline 1700 is the network pipeline 1200 from Fig. 12 is similar, except that the network pipeline 1700 can send network traffic data to each of the logically partitioned ports 1610 of the output port 1220. The NPAL 1602 can configure different policies for the various logical partitions. The network pipeline can process the network traffic data and send it to the correct logically partitioned port 1610.

[0164] As in Fig. As illustrated in Figure 17, the network pipeline 1700 includes an inbound port 1202, which can receive network traffic data and feed it to the filtering network function 1204, which is operationally coupled to the inbound port 1202. The filtering network function 1204 can filter the network traffic data. The ingress port 1206 is operationally coupled to the filtering network function 1204, and the ingress port 1206 is operationally coupled to the first network function 1208. The first network function 1208 can process the network traffic data based on one or more ingress ACLs. The bridge 1210 is operationally coupled to the first network function 1208. The bridge 1210 can perform a Layer 2 bridging operation. The one or more SVI ACLs are operationally coupled to the bridge 1210 and the router 1214. Router 1214 can perform a Layer 3 routing operation. The second network function, 1216, is operationally coupled to router 1214.The second network function 1216 can process network traffic data using one or more egress ACLs. Egress port 1218 is operationally coupled to the second network function 1216. Egress port 1218 is operationally coupled to output port 1220. Output port 1220 can output network traffic data to one of the logically split ports 1610.

[0165] Fig. Figure 18 is a flowchart of a method 1800 for operating a split-interface DPU according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled to a switch. In at least one embodiment, the method 1800 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads implementing the method 1800 can be synchronized (e.g.,(using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, processing threads implementing Procedure 1800 can be executed asynchronously. Various operations of Procedure 1800 can be performed in a different order than that shown in the diagram. Fig. The operations shown in 18 can be carried out. Some operations of the methods can be performed simultaneously with other operations. In at least one embodiment, one or more of the following are performed: Fig. The 18 operations shown may not always be performed.

[0166] With reference to Fig. 18. The processing logic begins by executing one or more instructions from an NPAL that supports multiple network protocols and network functions in a network pipeline for multiple logically partitioned ports (Block 1802). Each logically partitioned port corresponds to one of the multiple devices. The network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine. In Block 1804, the processing logic receives initial network data through a physical port from an initial device via a breakout cable. In Block 1806, the processing logic, using the DPU's acceleration hardware engine, processes the initial network traffic data using the network pipeline. In Block 1808, the processing logic sends the initial network data to the first logically partitioned port of the multiple logically partitioned ports.In block 1810, the processing logic receives the second network data via the physical port from a second device using the breakout cable. In block 1812, the processing logic uses the DPU's acceleration hardware engine to process the second network traffic data using the network pipeline. In block 1814, the processing logic sends the first network data to the first of several logically split ports.

[0167] In another embodiment, the processing logic configures the first logically split port with a first policy and configures the second logically split port with a second policy that differs from the first policy.

[0168] In another embodiment, the processing logic (e.g., firmware) maps physical lanes of the physical port to the multiple logically partitioned ports and presents these multiple logically partitioned ports as multiple PFs (Physical Functions) to a virtual switch and the NPAL. The processing logic (e.g., NPAL) manages each of the multiple PFs as if it were a separate physical port.

[0169] In at least one embodiment, the processing logic configures the network pipeline to execute a first network function for a first PF of several PFs, and configures the network pipeline to execute a second network function for a second PF of several PFs, wherein the second network function differs from the first network function. NPAL-Supporting Fast Link Restoration

[0170] As described above, a link failure in network topologies refers to a situation where a communication link between two network devices, such as routers, NICs, switches, or hosts, is no longer available due to various causes, including hardware failure, cable breakage, or network congestion. Link failures can significantly impact the performance, availability, and reliability of network services, especially in large or critical environments such as data centers or enterprise networks. Several factors can lead to link failures, including physical link failures (e.g., damage to or interruption of cables due to fiber optic breakage, faulty Ethernet cables, etc.), device failures (e.g., hardware failures leading to interface failures), bottlenecks, or congestion (i.e., insufficient bandwidth).Network links that are overloaded with too much traffic, resulting in timeouts or packet loss; software errors or misconfigurations that cause a network device to disconnect; power outages; maintenance work (e.g., planned outages for maintenance or upgrades can also lead to temporary link failures); or similar issues. The link failures described above can have varying impacts.

[0171] A routing strategy is referred to as ECMP. As described above, an NPAL can support rapid link recovery when a link failure occurs and an ECMP (Equal-Cost Multi-Path) group needs to be updated to reflect a new network topology. Due to the aforementioned impact of a link failure, it is important that a rapid recovery occurs when a link fails. Specifically, when a link fails, an ECMP group must be updated immediately to account for the fact that a particular link is no longer available. Similarly, when a link is restored, the ECMP group must be updated immediately with the restored link to enable better network utilization.

[0172] As described in more detail below, the NPAL can act as an accelerated network pipeline and a mechanism for offloading virtual switching hardware, periodically monitoring links. In at least one embodiment, a user can configure the NPAL to support rapid link recovery, enabling link monitoring by the virtual switch. For example, all ports in a given ECMP group can be monitored using IPC (Interprocess Communication) messages, such as Linux netlink messages from a Linux kernel. When a link fails (i.e., a link failure occurs), the virtual switch identifies the link as failed and immediately updates the ECMP group by removing the link from the group.This means the virtual switch updates the ECMP group in the tables on a bridge and / or router in the network pipeline to remove the failed link. Once the ECMP group is updated, traffic can be distributed to other links within the ECMP group. When a link is restored (i.e., the link failure no longer occurs), the virtual switch identifies the link as restored and immediately updates the ECMP group by adding the link from the ECMP group. That is, the virtual switch updates the ECMP group in the tables on the bridge and / or router in the network pipeline to add the restored link (also referred to as the new link). Once the ECMP group is updated, traffic, along with the other links in the ECMP group, can be distributed to the new link.

[0173] In at least one embodiment, a DPU comprises DPU hardware, including a processing device and an acceleration hardware engine, and a memory operationally coupled to the DPU hardware. The memory can store instructions which, when executed by the DPU hardware, provide a virtual switch and an NPAL that enable fast link recovery. An example of a DPU software stack is described below with respect to Fig. 19 illustrated and described.

[0174] Fig. Figure 19 is a block diagram of a software stack 1900 of a DPU with an NPAL 1902 that supports fast link recovery according to at least one embodiment. As described above, to support fast link recovery, the DPU must support it in both hardware and software. From a hardware perspective, the DPU hardware includes a network-connected network connection, a host connection, and an acceleration hardware engine. The DPU hardware may include additional hardware, such as a processing device (e.g., one or more CPU cores), one or more GPUs, switches, memory, or the like.

[0175] From a software perspective, the 1900 software stack can support fast link recovery. The 1900 software stack can be stored in the DPU's memory. It comprises firmware 1906, driver 1908, virtual switch 1910, and NPAL 1902. Firmware 1906 can interact with the 1904 DPU hardware and driver 1908. Driver 1908 can interact with firmware 1906 and virtual switch 1910. NPAL 1902 can reside on the virtual switch 1910. The 1900 software stack can consist of commands that, when executed by the DPU hardware, can deploy NPAL 1902, which supports multiple network protocols and network functions within a network pipeline. As described above, the network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine.

[0176] In at least one embodiment, the virtual switch 1910 can include link monitoring logic 1912 that monitors the link availability of each of several links to a destination. The several links can be part of, or specified in, an initial group of identifiers in a routing table 1918. That is, the link monitoring logic 1912 can monitor whether a link is available by monitoring all the ports associated with the initial group of link identifiers. The link monitoring logic 1912 can detect a link failure of the first link among the several links. The link monitoring logic 1912 can notify the ECMP logic 1914 in the NPAL 1902.ECMP logic 1914 can remove a first link identifier associated with the first link from the initial group of link identifiers to obtain a modified group of link identifiers in an ECMP group table 1916. ECMP logic 1914 can also cause a routing table 1918 in NPAL 1902 to be updated to remove the first link identifier. The acceleration hardware engine in DPU hardware 1904 can process network traffic data using the network pipeline and distribute the network traffic data only to the remaining links of the multiple links that correspond to the modified group of identifiers.

[0177] In at least one embodiment, the virtual switch is controlled by a network service hosted on the DPU. The virtual switch can send a notification to the network service about the failure of the initial link. The network service can update the routing table in the NPAL in response to the notification. The routing table stores configuration information associated with the initial set of identifiers. In at least one embodiment, the notification is a message from a kernel (e.g., a NetLink message from a Linux kernel).

[0178] In at least one embodiment, the ECMP logic 1914 can receive a first packet before the failure of the first link and perform an IP address lookup on the first packet to identify an ECMP group identifier associated with the multiple links. The ECMP logic 1914 can hash the ECMP group identifier to identify any one of the multiple links. After the failure of the first link, the ECMP logic 1914 can receive a second packet and perform an IP address lookup on the second packet to identify the ECMP group identifier. The ECMP logic 1914 can hash the ECMP group identifier to identify any one of the remaining links.

[0179] In at least one embodiment, the virtual switch 1910 can monitor the link availability of each of the multiple links to the destination and detect a link restoration of the first link. The ECMP logic 1914 can add the first link identifier to the modified group of link identifiers to maintain the original group of link identifiers in the ECMP group table 1916. The ECMP logic 1914 can cause the routing table 1918 in the NPAL 1902 to be updated to add the first link identifier. The acceleration hardware engine processes subsequent network traffic data using the network pipeline and distributes the subsequent network traffic data to the multiple links corresponding to the initial group of identifiers.In at least one embodiment, the ECMP logic 1914 can receive a first packet before the first link is re-established and perform an IP address lookup on the first packet to identify an ECMP group identifier associated with the multiple links. The ECMP logic 1914 can hash the ECMP group identifier to identify any one of the remaining links. After the first link is re-established, the ECMP logic 1914 can receive a second packet and perform an IP address lookup on the second packet to identify the ECMP group identifier. The ECMP logic 1914 can hash the ECMP group identifier to identify any one of the multiple links.

[0180] In at least one embodiment, the virtual switch 1910 is controlled by a network service hosted on the DPU. The virtual switch 1910 can send an initial notification of the first link failure to the network service, and in response to the initial notification, the network service updates the routing table in the NPAL, which stores configuration information associated with the initial group of identifiers. The virtual switch 1910 can send a second notification to the network service of the first link recovery, and in response to the second notification, the network service updates routing table 1918 in the NPAL 1902. In at least one embodiment, the virtual switch 1910 can remove the first link identifier from the ECMP group in the virtual switch 1612 and, concurrently, modify routing table 1918 in the NAPL.

[0181] In at least one embodiment, the network pipeline comprises an inbound port, a dynamic or static ingress ACL, a bridge, a router, a dynamic or static egress ACL, and an outbound port. Routing table 1918 can be stored in the bridge, the router, or both. An example of a network pipeline is described below with respect to Fig. 20 illustrated and described.

[0182] Fig. Figure 20 is a network diagram of an exemplary Network Pipeline 2000, optimized and accelerated on an acceleration hardware engine of a DPU with an NPAL that supports fast link recovery according to at least one embodiment. The Network Pipeline 2000 is similar to the network traffic data shown in Figure 120. Fig. 12, except that network pipeline 2000 contains a routing table 1918 stored in bridge 1210, router 1214, or both. As described above, the virtual switch can monitor the link availability of each of several links to a destination. Once the virtual switch detects a link failure of an initial link, it can remove the initial link identifier associated with that link from an initial group of link identifiers to obtain a modified group of link identifiers in the ECMP group table 1916. The virtual switch then updates routing table 1918 to remove the initial link identifier.Once routing table 1918 is updated, the acceleration hardware engine can process network traffic data using the network pipeline and distribute the network traffic data only to the remaining links of the multiple links that correspond to the modified group of identifiers. Similarly, the virtual switch can continue to monitor the link availability of each link. The virtual switch can detect a link recovery of the first link. The virtual switch can add the first link identifier to the modified group of link identifiers to maintain the initial group of link identifiers and cause routing table 1918 to be updated to include the first link identifier.Once routing table 1918 is updated, the acceleration hardware engine can process subsequent network traffic data using the network pipeline and distribute the subsequent network traffic data to the multiple links corresponding to the initial group of identifiers.

[0183] As in Fig. As shown in Figure 20, the network pipeline 2000 comprises an inbound port 1202, a filtering network function 1204, an ingress port 1206, a first network function 1208, a bridge 1210 that stores the routing table 1918, SVI ACLs 1212, a router 1214 that stores the routing table 1918, a second network function 1216, an egress port 1218, and an outbound port 1220. The inbound port 1202 can receive network traffic data and feed it to the filtering network function 1204, which is operationally coupled to the inbound port 1202. The filtering network function 1204 can filter the network traffic data. Ingress port 1206 is operationally coupled to filtering network function 1204, and ingress port 1206 is operationally coupled to the first network function 1208. The first network function 1208 can process network traffic data based on one or more ingress ACLs.Bridge 1210 is operationally coupled to the first network function 1208. Bridge 1210 can perform an ECMP bridge operation based on a current routing table 1918, excluding all broken links as described above. One or more SVI ACLs are operationally coupled to bridge 1210 and router 1214. Router 1214 can perform an ECMP routing operation based on the current routing table 1918, excluding all broken links as described above. The second network function 1216 is operationally coupled to router 1214. The second network function 1216 can process network traffic data using one or more egress ACLs. Egress port 1218 is operationally coupled to the second network function 1216. Egress port 1218 is operationally coupled to the outbound port 1220. The output port 1220 can output network traffic data.

[0184] As described above, the NPAL ECMP logic can include 1914, which performs ECMP operations on incoming packets before a link failure, after a link failure, and after a link recovery, as shown below in relation to Fig. 21 shown and described.

[0185] Fig. Figure 21 represents flowcharts of ECMP operations before a link failure, after a link failure, and after a link restoration according to at least one embodiment. In a first flow 2102, the ECMP logic receives a first packet 2108 and performs an IP lookup operation 2110, which returns an ECMP group 2112. The ECMP group 2112 can be a 5-tuple hash that identifies a first link 2114 (Link0) and a second link 2116 (Link1) as part of the ECMP group 2112. The first flow 2102 takes place before a link failure is detected.

[0186] In a second process 2104, if a link failure is detected for the first link 2114, the ECMP logic receives a second packet 2118 and performs the IP lookup operation 2110, which returns the ECMP group 2112. The 5-tuple hash of the ECMP group 2112 identifies only the second link 2116 in this case, because the first link 2114 has a link failure. As a result, in this case, all traffic is routed only through the second link 2116 (Link1). The second process 2104 occurs after a link failure has been detected.

[0187] In a third process (2106), when a link recovery is detected for the first link (2114), the ECMP logic receives a third packet (2120) and performs the IP lookup operation (2110), which returns the ECMP group (2112). In this case, the ECMP group (2112) can be a 5-tuple hash that identifies the first link (2114, Link0) and the second link (2116, Link1) as part of the ECMP group (2112). As a result, all traffic in this case goes to both the first link (2114, Link0) and the second link (2116, Link1). The third process (2106) occurs after a link recovery is detected.

[0188] Fig. Figure 22 is a flowchart of a method 2200 for operating a DPU with fast link recovery according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled to a switch. In at least one embodiment, the method 2200 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In at least one embodiment, processing threads implementing the method 2200 can be synchronized (e.g.,(using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, processing threads implementing Procedure 2200 can be executed asynchronously. Various operations of Procedure 2200 can be performed in a different order than that shown in the diagram. Fig. The procedures shown in section 22 can be carried out. Some operations of the procedures can be performed simultaneously with other operations. In at least one embodiment, one or more of the operations shown in Fig. The 22 operations shown may not always be performed.

[0189] With reference to Fig. 22. The processing logic begins by executing one or more commands from a virtual switch and an NPAL that supports multiple network protocols and network functions in a network pipeline (Block 2202). The network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the acceleration hardware engine. In Block 2204, the processing logic, using the virtual switch, monitors the link availability of each of several links to a destination, where the multiple links are specified in an initial set of identifiers. In Block 2206, the processing logic, using the virtual switch, detects a link failure of the first link among the multiple links.In block 2208, the processing logic via the virtual switch removes a first link identifier associated with the first link from the initial group of link identifiers to obtain a modified group of link identifiers. In block 2210, the processing logic via the virtual switch causes a routing table in the NPAL to be updated to remove the first link identifier. In block 2212, the processing logic, using the DPU's acceleration hardware engine, processes network traffic data using the network pipeline. In block 2214, the processing logic, again using the DPU's acceleration hardware engine, distributes the network traffic data only to the remaining links corresponding to the multiple links in the modified group of identifiers.

[0190] In another embodiment, the initial group of link identifiers is an ECMP (Equal-Cost Multi-Path) group. The processing logic removes the first link identifier from the initial group by removing it from the ECMP. The processing logic also updates the routing table in the NPAL in parallel with the removal of the first link identifier from the ECMP.

[0191] In another embodiment, the processing logic receives a first packet before the first link fails. The processing logic performs an IP address lookup on the first packet to identify an ECMP group identifier associated with the multiple links. The processing logic hashes the ECMP group identifier to identify any one of the multiple links. The processing logic receives a second packet after the first link fails. The processing logic performs an IP address lookup on the second packet to identify the ECMP group identifier. The processing logic hashes the ECMP group identifier to identify any one of the remaining links.

[0192] In another embodiment, the processing logic monitors the link availability of each of the multiple links to the destination. The processing logic detects a link recovery of the first link. It adds the first link identifier to the modified group of link identifiers to preserve the initial group. The processing logic then updates the routing table in the NPAL to include the first link identifier. The acceleration hardware engine can process subsequent network traffic data using the network pipeline and distribute this traffic data to the multiple links corresponding to the initial group of identifiers.

[0193] In another embodiment, the processing logic receives a first packet before the first link is re-established. The processing logic performs an IP (Internet Protocol) address lookup on the first packet to identify an ECMP group identifier associated with the multiple links. The processing logic hashes the ECMP group identifier to identify any one of the remaining links. The processing logic receives a second packet after the first link is re-established. The processing logic performs an IP address lookup on the second packet to identify the ECMP group identifier. The processing logic hashes the ECMP group identifier to identify any one of the multiple links. NPAL support from PBR via SFC architecture

[0194] In at least one embodiment, the NPAL can provide hardware-accelerated policy-based routing (PBR) over the SFC architecture of a DPU. Using SFC on the DPU, a user (or controller) can add various PBR policies, which are accelerated by the DPU hardware as a single data layer on the DPU. As described above, PBR is a technique that allows network administrators to make routing decisions based on policies defined by the network administrator, rather than relying on the standard routing table, which uses destination IP addresses to determine the next hop. In traditional routing, a router decides how to forward packets based on the destination IP address and the routing table. PBR allows the router to make routing decisions based on other criteria, such as...Source IP address or subnet; IP protocol type; port number; ingress interface; packet size, QoS parameters, etc. PBR is useful for controlling the path that traffic takes through a network. It gives network administrators more flexibility in implementing routing rules that don't depend solely on the destination IP address, as shown below. Fig. 23 and Fig. 24 described.

[0195] Fig. Figure 23 is a block diagram of an SFC architecture 2300 with a PBR guideline 2302 according to at least one embodiment. The SFC architecture 2300 is similar to the SFC architecture 800 from Fig. 8 and the SFC architecture 300 from Fig. 3, except that the PBR policy 2302 is used instead of the user-defined network rule 816 in the SFC architecture 800. The SFC architecture 2300 includes a first virtual bridge 802 (named "OVS BR-1"), a second virtual bridge 804 (named "OVS BR-2"), a virtual port 806, and a network service 808. As described herein, SFC logic 102 can create the first virtual bridge 802, the second virtual bridge 804, and the virtual port 806 in the SFC architecture 800. SFC logic 102 can configure the first virtual bridge 802 to be controlled by network service rules 814 provided by the network service 808 hosted on the DPU 204, and the second virtual bridge 804 to be controlled by the PBR policy 2302.SFC logic 102 adds a service interface to the first virtual bridge 802 to operationally couple the network service 808 to the first virtual bridge 802. SFC logic 102 adds virtual port 806 between the first virtual bridge 802 and the second virtual bridge 804. The network service 808 can provide one or more network service rules 814 to the first virtual bridge 802. Custom logic 126 can provide one or more PBR policies 2302 to the second virtual bridge 804. Custom logic 126 can be a user or a controller, as described herein. SFC logic 102 can add one or more host interfaces 310 to the second virtual bridge 804.

[0196] In at least one embodiment, the first virtual bridge 802 and the second virtual bridge 804 are OVS bridges. The processing device can run an OVS application with hardware offload mechanisms to provide the single accelerated data plane 702 in the acceleration hardware engine to route the network traffic data according to the PBR policy 2302 and to process the network traffic data according to the set of one or more network rules.

[0197] As illustrated, three separate host interfaces can be added to connect the second virtual bridge 804 to hosts, for example, three separate VMs hosted on host device 202. For instance, one VM might host a firewall application, another a load balancing application, and another an IDS application. SFC logic 102 can add one or more network interfaces 812 to the first virtual bridge 802. Specifically, SFC logic 102 can add a first network interface to the first virtual bridge 802 for operational coupling to a first network port 314 (labeled PORT1) of DPU 204, and a second network interface for operational coupling to a second network port 316 (labeled PORT2) of DPU 204. The first virtual bridge 802 can receive network traffic data from both the first network port 314 and the second network port 316.The first virtual bridge 802 can route network traffic data via virtual port 806 to the second virtual bridge 804. The second virtual bridge 804 can route network traffic data via host interface 810 to the corresponding host.

[0198] In at least one embodiment, the PBR policy 2302 can be provided by a user 2304. The user 2304 can provide the PBR policy 2302 using the user-defined logic 126. The user 2304 can program the second virtual bridge 804 with the PBR policy 2302. Alternatively, the user-defined logic 126 can receive user input from the user 2304, and the user-defined logic 126 can generate the PBR policy 2302 and provide it to the second virtual bridge 804. In another embodiment, the PBR policy 2302 can be provided by a user-defined service or another network service that is separate from the network service 808.The other network service (or custom service) can be a custom network service, a custom security service, a custom telemetry service, a custom storage service, or the like, hosted on DPU 204 or as applications on host device 202. If PBR policy 2302 is provided by a second network service, SFC logic 102 can add another service interface to the second virtual bridge 804 to operationally couple the second network service to the second virtual bridge 804. In another embodiment, a controller can provide PBR policy 2302 to the second virtual bridge 804.

[0199] The DPU 204 can combine network rules according to the various network services to obtain a combined set of network rules that can be accelerated in a single accelerated data plane 702 of the DPU 204. This combined set of network rules becomes hardware-accelerated rules that are accelerated by the DPU 204 for the SFC 800 architecture.

[0200] In at least one embodiment, the DPU 204 provides a DPU service that supports HBN (Host Based Networking) as a network service 808 for accelerating L2 / L3 / tunneling protocols on the DPU 204. The HBN infrastructure is based on an SFC topology, where one OVS bridge is controlled by the HBN service, which provides all the accelerated networking capabilities. As described above, the second OVS bridge (second virtual bridge 804) can be programmed by the user 2304 or another controller (as in Fig. (9 illustrated). The HBN service can support various protocols and network capabilities, such as ACLs, ECMP, tunneling, CT, and more. The user can flexibly program different routing rules per one or more PBR policies via the SFC architecture in parallel with the HBN service, resulting in hardware-accelerated rules for the single accelerated data plane provided by OVS-DOCA and the DPU hardware. Using the SFC infrastructure, users and customers can utilize the DPU as a network accelerator on an edge device without the need for complex and intelligent switches in various network topologies within a DC or SP network.

[0201] It should be noted that the SFC logic can generate 102 different combinations of hardware-accelerated rules in different SFC architectures, as shown and described herein.

[0202] In at least one embodiment, an acceleration hardware engine of the DPU 204 provides the single accelerated data plane 702. The DPU 204 may include memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and a virtual port between the first and second virtual bridges. A processing device of the DPU may create the first and second virtual bridges, wherein the first virtual bridge is controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has the PBR policy 2302. The processing device may add the PBR policy to the second virtual bridge. The processing device may add the virtual port between the first and second virtual bridges.The acceleration hardware engine in the single accelerated data layer 702 can forward network traffic data using the PBR policy and process the network traffic data based on the set of one or more network rules.

[0203] In at least one embodiment, the processing device can receive user input from the user 2304 (or a controller). The user input can specify the PBR policy 2302. The SFC architecture 2300 can include one or more routing rules, each containing a compliance condition (also called a compliance criterion or criteria) and a corresponding action. Note that the compliance condition can be a condition that does not include the destination address as used in conventional routing. In at least one embodiment, the compliance condition specifies at least one of: a source IP address; a source or destination port; a protocol identifier; a VLAN (Virtual Local Area Network) tag; a DSCP (Differentiated Service Code Point) value or a ToS (Type of Service) value; an application or service type; a time of day; or similar conditions.The action may include at least one of the following: a rerouting action, a rejection action, a diversion action, a mirroring action, a load balancing action, a rate limiting action, a QoS (Quality of Service) marking action, a traffic management action, an encapsulation action, a rerouting action, or other similar actions.

[0204] In at least one embodiment, the processing device can add one or more host interfaces 810 to the second virtual bridge 804 for operational coupling with one or more host devices 202 operationally coupled to the DPU 204, according to the configuration file. The processing device can add one or more network interfaces 812 to the first virtual bridge 802 for operational coupling with one or more network ports 314 and 316 of the DPU 204. The processing device can add a first service interface to the first virtual bridge for operational coupling with the first network service, wherein the first network service provides accelerated network capabilities using the set of one or more network service rules 814 (e.g.,Network Service Rule 814 provides an L2 protocol rule, an L3 protocol rule, a tunneling protocol rule, an ACL rule, an ECMP rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT rule, a VLAN rule, or a NAT rule. Network Service Rule 814 can include one or more control rules (for example, an application-based control rule, a policy-based control rule, a geolocation-based control rule, a load balancing rule, a QoS rule, a backup rule, a redundancy rule, a security-based control rule, a cost-based routing rule, an SD-WAN path control rule, or an SDN rule).

[0205] In at least one embodiment, the processing device can add one or more host interfaces 810 to the second virtual bridge 804 for operational coupling with one or more host devices 202 operationally coupled to the DPU 204, according to the configuration file. The processing device can add one or more network interfaces 812 to the first virtual bridge 802 for operational coupling with one or more network ports of the DPU 204. The processing device can add a first service interface to the first virtual bridge 802 for operational coupling with the first network service.The processing device can add a second service interface to the second virtual bridge 804 for the operational coupling of a second network service, where the first and second network services are part of an SFC infrastructure to provide accelerated network capabilities in the single accelerated data plane 702 by means of a combined set of network rules. The combined set of rules comprises the set of one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service.

[0206] In at least one embodiment, an operating system (OS) can be installed and run on a processing device of the DPU 204. The creation of the multiple virtual bridges and the interface mappings of the multiple virtual bridges can be part of the OS installation on the DPU 204. In at least one embodiment, the creation of the multiple virtual bridges and the interface mappings of the multiple virtual bridges can be part of the runtime of the DPU 204 without requiring the OS to be reinstalled on the DPU 204.

[0207] Fig. Figure 24 is a flowchart of a method 2400 for operating a DPU that supports PBR via an SFC architecture according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled with a switch. In at least one embodiment, the method 2400 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In at least one embodiment, the processing threads implementing the method 2400 can be synchronized (e.g.,(using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, processing threads implementing Procedure 2400 can be executed asynchronously. Various operations of Procedure 2400 can be performed in a different order than in the standard. Fig. 24. Some operations of the methods can be performed simultaneously with other operations. In at least one embodiment, one or more of the operations shown in Fig. The 24 operations shown may not always be performed.

[0208] With reference to Fig. 24. The processing logic begins by storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and a virtual port between the first and second virtual bridges (block 2402). In block 2404, the processing logic creates the first and second virtual bridges according to the configuration file. The first virtual bridge is controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has a PBR policy. In block 2406, the processing logic adds the virtual port between the first and second virtual bridges according to the configuration file.In block 2408, the processing logic, using the acceleration hardware engine in the individual accelerated data layer, routes network traffic data according to the PBR policy. In block 2410, the processing logic, using the acceleration hardware engine in the individual accelerated data layer, processes the network traffic data according to the set of network rules.

[0209] In another embodiment, the processing logic receives user input from a user or a controller, where the user input specifies the PBR policy. The PBR policy comprises one or more routing rules, each containing a compliance condition and a corresponding action. The processing logic adds the PBR policy to the second virtual bridge. The compliance condition can be one of the examples described above. Likewise, the action can be one of the examples described above.

[0210] In another embodiment, the processing logic, according to the configuration file, adds one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU. The processing logic, according to the configuration file, adds one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU. The processing logic, according to the configuration file, adds a first service interface to the first virtual bridge for operational coupling with the first network service, wherein the first network service provides accelerated networking capabilities based on a set of one or more network rules.

[0211] In another embodiment, the processing logic adds one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU, according to the configuration file. The processing logic adds one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU, according to the configuration file. The processing logic adds a first service interface to the first virtual bridge for operational coupling with the first network service, according to the configuration file. The first network service provides accelerated network capabilities based on the set of one or more network rules (e.g.,Network Service Rule 814 is intended to provide an L2 protocol rule, an L3 protocol rule, a tunneling protocol rule, an ACL rule, an ECMP rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT rule, a VLAN rule, or a NAT rule. Network Service Rule 814 can include one or more control rules (for example, an application-based control rule, a policy-based control rule, a geolocation-based control rule, a load balancing rule, a QoS rule, a backup rule, a redundancy rule, a security-based control rule, a cost-based routing rule, an SD-WAN path control rule, or an SDN rule).

[0212] In another embodiment, the processing logic adds one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU, according to the configuration file. The processing logic adds one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU, according to the configuration file. The processing logic adds a first service interface to the first virtual bridge for operational coupling with the first network service, according to the configuration file.The processing logic, as defined in the configuration file, adds a second service interface to the second virtual bridge for operational coupling with a second network service. Both the first and second network services are part of an SFC infrastructure to provide accelerated network capabilities in the single accelerated data plane using a combined set of network rules. This combined set of rules comprises one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service. NPAL EMULATION

[0213] As described herein, an emulated NPAL can be used to emulate a hardware DPU with an NPAL as an emulated network pipeline. An emulated network pipeline refers to a software-based framework that mimics or emulates the behavior of a hardware-based network pipeline typically found in physical network devices such as switches, routers, NICs, DPUs, and so on. The emulated pipeline is implemented in software, often in environments such as virtual machines (VMs) or containerized environments, to simulate the same packet processing, forwarding, and routing decisions as hardware pipelines without relying on physical network hardware. An emulated network pipeline performs the functions of traditional network hardware (such as packet switching, traffic management, firewalling, etc.) but runs entirely in software.This is useful in scenarios where no physical network hardware is available or when test, development, or virtualized environments require network functionality. In at least one embodiment, a computing system comprises one or more processors and one or more memory units that store instructions which, when executed by the one or more processors, perform operations of an emulated NPAL (Network Pipeline Abstraction Layer) of an emulated DPU (Data Processing Unit). The DPU includes an emulated processing device and an emulated acceleration hardware engine. The emulated NPAL supports multiple network protocols and network functions in an emulated network pipeline. The emulated network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the emulated acceleration hardware engine.The emulated acceleration hardware engine is used to process network traffic data using the emulated network pipeline. An example of an emulated network pipeline is described below. Fig. 25 illustrated and described.

[0214] Fig. Figure 25 is a block diagram of an emulated network pipeline 2500 on an emulated acceleration hardware engine of an emulated DPU with an emulated NPAL according to at least one embodiment. The emulated network pipeline 2500 comprises a set of tables and logic organized in a specific order to be accelerated by an emulated acceleration hardware engine. The emulated acceleration hardware engine can process network traffic data using the emulated network pipeline 2500. As illustrated, the emulated network pipeline 2500 includes an inbound port 2502, a filtering network function 2504, an ingress port 2506, a first network function 2508, a bridge 2510, an SVI-ACL 2512, a router 2514, a second network function 2516, an egress port 2518, and an egress port 2520.Ingress port 2502 can receive network traffic data and feed it to filtering network function 2504, which is operationally coupled to ingress port 2502. Filtering network function 2504 can filter the network traffic data. Ingress port 2506 is operationally coupled to filtering network function 2504, and ingress port 2506 is operationally coupled to first network function 2508. First network function 2508 can process the network traffic data using one or more ingress ACLs. Bridge 2510 is operationally coupled to first network function 2508. Bridge 2510 can perform a Layer 2 bridging operation. One or more SVI ACLs are operationally coupled to bridge 2510 and router 2514. Router 2514 can perform a Layer 3 routing operation. The second network function 2516 is operationally coupled with the router 2514.The second network function 2516 can process network traffic data using one or more egress ACLs. Egress port 2518 is operationally coupled to the second network function 2516. Egress port 2518 is operationally coupled to output port 2520. Output port 2520 can output the network traffic data.

[0215] In contrast to the network pipeline 1200 from Fig. 12, which are part of DPU 204 Fig. 2, the emulated network pipeline 2500 is implemented in an emulated DPU, as in Fig. Figure 27 illustrates the emulated network pipeline 2500, which can be used in conjunction with the various embodiments described herein, including configurable and dynamic SFC interfaces in a DPU, hardware-accelerated flexible control rules of the SFC architecture in a DPU, an NPAL of a DPU, OVS bridges, split NPAL interfaces, fast NPAL link recovery, PBR over SFC, or the like.

[0216] In at least one embodiment, the one or more processors can further emulate an emulated physical port of the emulated DPU, configured to couple to an emulated breakout cable that is physically coupled to a set of multiple emulated devices. The one or more processors can further emulate an emulated NPAL that supports the multiple network protocols and network functions in the network pipeline for multiple logically split ports, each logically split port corresponding to one of the multiple devices. The emulated network pipeline 2500 can send the network traffic data to any of the multiple logically split ports.In at least one embodiment, a first logically split port among the multiple logically split ports is configured with a first policy, and a second logically split port among the multiple logically split ports is configured with a second policy that differs from the first policy. The emulated acceleration hardware engine can process the network traffic data using the emulated network pipeline 2500. In at least one embodiment, the emulated DPU includes firmware configured to map physical lanes of the physical port to the multiple logically split ports. The firmware can represent the multiple logically split ports as a set of PFs for the emulated NPAL.The emulated NPAL can configure the emulated network pipeline 2500 to execute a first network function for a first PF of the multiple PFs and a second network function for a second PF of the multiple PFs, where the second network function differs from the first network function.

[0217] In at least one embodiment, the one or more processors can further emulate a virtual switch of the emulated DPU. The virtual switch can monitor the link availability of each of several links to a destination, the multiple links being specified in an initial set of identifiers. The virtual switch can detect a link failure of the first link among the multiple links. The emulated NPAL can remove a first link identifier associated with the first link from the initial set of link identifiers to obtain a modified set of link identifiers. The emulated NPAL can cause a routing table in the emulated NPAL to be updated to remove the first link identifier.The emulated acceleration hardware engine can process network traffic data using the emulated network pipeline 2500 and distribute the network traffic data only to the remaining links of the multiple links that correspond to the modified set of identifiers. In at least one embodiment, the virtual switch can be controlled by a network service hosted on the emulated DPU. The virtual switch can send a notification of the first link failure to the network service. The network service can update the routing table in the emulated DPU in response to the notification. The routing table can store configuration information associated with the initial set of identifiers.

[0218] In at least one embodiment, the emulated processing device can create the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is controlled by a first network service hosted on the emulated DPU and has a set of one or more network rules, and the second virtual bridge has a policy-based routing (PBR) policy. The emulated processing device can add the virtual port between the first and second virtual bridges. The emulated acceleration hardware engine, in the single accelerated data plane, can route network traffic data according to the PBR policy and process the network traffic data according to the set of one or more network rules.In at least one embodiment, the emulated processing device can receive user input from a user or a controller, wherein the user input specifies the PBR policy. The PBR policy can include one or more routing rules, each comprising a compliance condition and a corresponding action. The emulated processing device can add the PBR policy to the second virtual bridge.

[0219] The Emulated Network Pipeline 2500 can be used in various scenarios. In at least one implementation, the Emulated Network Pipeline 2500 can be used for network testing and simulation. Before network policies, rules, or configurations are deployed on physical hardware, network engineers often use an emulated network pipeline to simulate how these changes will affect the network. This can be used for debugging, testing new protocols, or troubleshooting network behavior in a virtual environment. The Emulated Network Pipeline 2500 can eliminate the need for investment in physical hardware in early stages of deployment or testing, thereby reducing costs for network labs, developers, or organizations that rely heavily on virtualized infrastructure.

[0220] The emulated Network Pipeline 2500 can be quickly adapted or reconfigured compared to hardware-based pipelines, which require physical changes. This allows developers to experiment with different configurations, test various topologies, or simulate outages without touching physical infrastructure. The emulated Network Pipeline 2500 is particularly useful for small businesses, startups, or development environments where deploying expensive switches and routers is not feasible. In cloud environments, scalability is crucial. The emulated Network Pipeline 2500 enables dynamically scaling of network behavior up or down as needed, something that can be difficult for physical hardware due to its limited capacity.

[0221] As described above, the emulated Network Pipeline 2500 can be emulated in an emulated environment that includes other virtualized components, such as one or more network services, an NPAL used by one or more network services, a virtual bridge, an SFC, or the like. Each of the emulated components is implemented in software to emulate the exact same behavior as a real hardware device. The emulated Network Pipeline 2500 functions just like the hardware network pipeline. An example of an emulated environment is described below with respect to... Fig. 26 illustrated and described.

[0222] Fig. Figure 26 is a block diagram of an emulated SFC architecture 2600 with an emulated host device 2602 and an emulated DPU 2604 according to at least one embodiment. The emulated SFC architecture 2600 is similar to the SFC architecture 300 of Fig. 3, except that the hardware and software components are emulated hardware and emulated software. In this embodiment, the physical ports of the emulated DPU 2604 are emulated as the first emulated network port 2618 and the second emulated network port 2620. As described above, the emulated DPU 2604 can create and configure the emulated SFC architecture 2600 with emulated software components, such as a first emulated virtual switch 2606, a second emulated virtual switch 2608, a virtual emulated port 2610, and an emulated network service 2612, according to at least one embodiment.

[0223] The emulated DPU 2604 can include SFC logic that can create the first emulated virtual switch 2606, the second emulated virtual switch 2608, and the virtual emulated port 2610 in the emulated SFC architecture 2600. The SFC logic can configure the first emulated virtual switch 2606 to be controlled by the emulated network service 2612 and the second emulated virtual switch 2608, both hosted on the emulated DPU 2604. The SFC logic can add a service interface to the first emulated virtual switch 2606 to operationally couple the emulated network service 2612 with the first emulated virtual switch 2606. The SFC logic can add the virtual emulated port 2610 between the first emulated virtual switch 2606 and the second emulated virtual switch 2608.The emulated network service 2612 can provide one or more emulated network service rules 2622 to the first emulated virtual switch 2606. The SFC logic can add one or more emulated host interfaces 2614 to the second emulated virtual switch 2608.

[0224] As illustrated, three separate host interfaces can be added to connect the second emulated virtual switch 2608 to hosts, for example, three separate VMs hosted on host device 202. For example, one VM could host a firewall application, another a load balancing application, and another an IDS application. The SFC logic can add one or more emulated network interfaces 2616 to the first emulated virtual switch 2606. Specifically, SFC logic 102 can add a first network interface to the first emulated virtual switch 2606 for operational coupling with a first emulated network port 2618 (labeled PORT1) of the emulated DPU 2604, and a second network interface for operational coupling with a second emulated network port 2620 (labeled PORT2) of the emulated DPU 2604.The first emulated virtual switch 2606 can receive network traffic data from the first emulated network port 2618 and the second emulated network port 2620. The first emulated virtual switch 2606 can forward the network traffic data via virtual port 806 to the second emulated virtual switch 2608. The second emulated virtual switch 2608 can forward the network traffic data via emulated host interface 2614 to the corresponding host.

[0225] In at least one embodiment, the emulated DPU 2604 can contain user-defined logic as part of the second emulated virtual switch 2608. In at least one embodiment, the user-defined logic can be part of a user-defined service hosted on the emulated DPU 2604, such as a user-defined networking service, a user-defined security service, a user-defined telemetry service, a user-defined storage service, or the like. The SFC logic can add another service interface to the second emulated virtual switch 2608 for operational coupling of the user-defined service to the second emulated virtual switch 2608.

[0226] In at least one embodiment, the SFC logic in the second emulated virtual switch 2608 can configure a first link state propagation between a first host interface and the virtual emulated port 2610, and a second link state propagation between a second host interface and the virtual emulated port 2610. Similarly, the SFC logic in the second emulated virtual switch 2608 can configure a third link state propagation between a third host interface and the virtual emulated port 2610. Similar link state propagations can be configured in the first emulated virtual switch 2606 for links between the virtual emulated port 2610 and the emulated network interfaces 2616.

[0227] In at least one embodiment, the SFC logic can configure an OS property in the second emulated virtual switch 2608. In at least one embodiment, the SFC logic 102 can configure an OS property for each of the emulated host interfaces 2614.

[0228] As described herein, the emulated SFC architecture 2600 can be created either as part of the OS installation on the emulated DPU 2604 or as part of the runtime of the emulated DPU 2604. This can be done using a second configuration file or by modifying the original configuration file. Reconfiguring the emulated DPU 2604 as part of the runtime can be done without reinstalling the OS on the emulated DPU 2604.

[0229] In at least one embodiment, the emulated SFC architecture 2600 is a set of instructions executed by a computing system with a processing device and a working memory operationally coupled to the processing device. When executed by the processing device, the instructions cause the processing device to perform first operations of the emulated host device 2602 and second operations of an NPAL of the emulated DPU 2604, including an emulated processing device and an emulated acceleration hardware engine. The emulated NPAL supports multiple network protocols and network functions in an emulated network pipeline. The emulated network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the emulated acceleration hardware engine, as shown in Fig. Figure 25 illustrates the emulated acceleration hardware engine, which can process network traffic data using the emulated network pipeline 2500.

[0230] In at least one embodiment, the processing device can emulate the emulated physical virtual emulated port 2610 of the emulated DPU 2604. The emulated DPU 2604 is configured to couple with an emulated breakout cable, which is physically coupled to a set of multiple emulated devices. The emulated NPAL supports the multiple network protocols and network functions in the emulated network pipeline 2500 for multiple logically split ports, each logically split port corresponding to one of the multiple devices. The emulated network pipeline can send network traffic data to any of the multiple logically split ports.The first logically split port among several logically split ports can be configured with a first policy, and the second logically split port among several logically split ports can be configured with a second policy that differs from the first. The emulated acceleration hardware engine can process the network traffic data using the emulated network pipeline 2500.

[0231] In at least one embodiment, the emulated DPU 2604 comprises firmware configured to map physical lanes of the physical port to the multiple logically partitioned ports. In at least one embodiment, the firmware can represent the multiple logically partitioned ports as multiple PFs for the emulated NPAL. The emulated NPAL can configure the emulated network pipeline to execute a first network function for a first PF of the multiple PFs and a second network function for a second PF of the multiple PFs, the second network function being different from the first network function.

[0232] In at least one embodiment, the processing device can emulate a virtual switch, for example, the first emulated virtual switch 2606 or the second emulated virtual switch 2608 of the emulated DPU 2604. The second emulated virtual switch 2608 can monitor the link availability of each of several links to a destination, the several links being specified in an initial set of identifiers. The second emulated virtual switch 2608 can detect a link failure of the first link of the several links. The emulated NPAL can remove a first link identifier associated with the first link from the initial set of link identifiers to obtain a modified set of link identifiers. The emulated NPAL can cause a routing table in the emulated NPAL to be updated to remove the first link identifier.The emulated acceleration hardware engine can process network traffic data using the emulated network pipeline and distribute the network traffic data only to the remaining links of the multiple links that correspond to the modified group of identifiers. In at least one embodiment, the second emulated virtual switch 2608 is controlled by the emulated network service 2612, which is hosted on the emulated DPU 2604. The second emulated virtual switch 2608 can send a notification of the first link failure to the emulated network service 2612, and in response to the notification, the emulated network service 2612 updates the routing table in the emulated DPU 2604, the routing table storing configuration information associated with the initial group of identifiers.

[0233] In at least one embodiment, the processing device can emulate a physical processing device. The emulated processing device can create the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is controlled by the emulated network service 2612, which is hosted on the emulated DPU 2604 and has a set of one or more network rules, and the second virtual bridge has a policy-based routing (PBR) policy. The emulated processing device can add the virtual port between the first virtual bridge and the second virtual bridge. The emulated acceleration hardware engine can route network traffic data in each accelerated data plane according to the PBR policy and process the network traffic data according to the set of one or more network rules.

[0234] In at least one embodiment, the emulated processing device can receive user input from a user or a controller, wherein the user input specifies the PBR policy. The PBR policy comprises one or more routing rules, each including a compliance condition and a corresponding action. The emulated processing device can add the PBR policy to the second virtual bridge.

[0235] It should be noted that the SFC logic can generate different combinations of virtual bridges and interface mappings in different SFC architectures, as illustrated and described herein.

[0236] Fig. Figure 27 is a flowchart of a method 2700 for operating an emulated DPU according to at least one embodiment. The processing logic can be a combination of hardware, firmware, software, or any combination thereof. In at least one embodiment, the processing logic is implemented in a DPU, a switch, a network device, a GPU, a NIC, a CPU, or the like. In at least one embodiment, the processing logic is implemented in an acceleration hardware engine coupled with a switch. In at least one embodiment, the method 2700 can be executed by multiple processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In at least one embodiment, processing threads implementing the method 2700 can be synchronized (e.g.,(using semaphores, critical sections, and / or other thread synchronization logic). Alternatively, processing threads implementing Procedure 2700 can be executed asynchronously. Various operations of Procedure 2700 can be performed in a different order than that shown in the diagram. Fig. The operations shown in 27 can be carried out. Some operations of the methods can be performed simultaneously with other operations. In at least one embodiment, one or more of the operations shown in Fig. The 27 operations shown may not always be performed.

[0237] With reference to Fig. 27. The processing logic begins by executing one or more instructions from an emulated NPAL of an emulated DPU, which supports multiple network protocols and network functions in an emulated network pipeline. The emulated DPU includes an emulated processing device and an emulated acceleration hardware engine. The emulated network pipeline comprises a set of tables and logic organized in a specific order to be accelerated by the emulated acceleration hardware engine. In block 2704, the processing logic receives emulated network traffic data over a network. In block 2706, the processing logic processes the emulated network traffic data using the emulated network pipeline and the emulated acceleration hardware engine of the emulated DPU.

[0238] In another embodiment, the processing logic emulates an emulated physical port of the emulated DPU, configured to couple to an emulated breakout cable that is physically coupled to a set of multiple emulated devices. The emulated NPAL supports the multiple network protocols and network functions in the emulated network pipeline for multiple logically split ports, each logically split port corresponding to one of the multiple devices. The emulated network pipeline can send network traffic data to any of the multiple logically split ports. A first logically split port among the multiple logically split ports is configured with a first policy, and a second logically split port among the multiple logically split ports is configured with a second policy that differs from the first policy.

[0239] In another embodiment, the processing logic maps physical lanes of the physical port to the multiple logically partitioned ports and represents the multiple logically partitioned ports as multiple PFs for the emulated NPAL. The processing logic configures the emulated network pipeline to execute a first network function for a first PF of the multiple PFs and a second network function for a second PF of the multiple PFs, where the second network function differs from the first network function.

[0240] In at least one embodiment, the processing logic emulates a virtual switch of the emulated DPU by monitoring the link availability of each of several links to a destination, wherein the several links are specified in an initial group of identifiers, and detecting a link failure of the first link among the several links. The processing logic removes a first link identifier associated with the first link from the initial group of link identifiers to obtain a modified group of link identifiers. The processing logic causes a routing table in the emulated NPAL to be updated to remove the first link identifier.The emulated acceleration hardware engine can process network traffic data using the emulated network pipeline and distribute the network traffic data only to the remaining links of the multiple links that correspond to the modified group of identifiers.

[0241] In at least one embodiment, the virtual switch is controlled by an emulated network service hosted on the emulated DPU, and the emulation of the virtual switch includes sending a notification of the initial link failure to the emulated network service, wherein the emulated network service updates the routing table in the emulated DPU in response to the notification and stores the routing table with configuration information associated with the initial set of identifiers.

[0242] In at least one embodiment, the processing logic emulates the processing device by: creating a first virtual switch and a second virtual switch, wherein the first virtual switch is controlled by an emulated network service hosted on the emulated DPU and has a set of one or more network rules, and the second virtual switch has a PBR policy; adding the virtual port between the first virtual switch and the second virtual switch; routing network traffic data according to the PBR policy; and processing the network traffic data according to the set of one or more network rules.

[0243] Fig. Figure 28 is a block diagram of a 2800 computing system with two interconnected processing units and multiple networks according to at least one embodiment. The 2800 computing system is equipped with multiple integrated circuits (referred to as processing units), each comprising a CPU and two GPUs, thus forming a powerful and flexible architecture. These processing units are interconnected via an NVLink (or other high-speed connection), enabling high-speed communication between the processing units, and are further interconnected via a NIC (Network Interface Card) or a DPU (Data Processing Unit) to ensure efficient data transmission throughout the 2800 computing system.The coupling of processing units via NVLink enables seamless data exchange and parallel processing, thereby improving overall computing performance. Furthermore, these processing units are connected to multiple networks via one or more NICs (Network Interface Cards) or DPUs, allowing the system to handle complex tasks across multiple networks with high bandwidth and low latency. This configuration makes the Computing System 2800 highly suitable for demanding applications requiring significant computing power, such as AI (Artificial Intelligence), ML (Machine Learning), and data-intensive computations, while ensuring robust connectivity and scalability in diverse network environments. The Computing System 2800's integrated circuits can include one or more CPUs and one or more GPUs. An example of a multi-GPU architecture is shown in [reference missing]. Fig. 28 illustrated.

[0244] As in Fig. As illustrated in Figure 28, the computing system 2800 comprises a processing device 2802 with a multi-GPU architecture. Specifically, the processing device 2802 comprises a CPU 2806, a GPU 2808, and a GPU 2810. The CPU 2806 can be coupled to the GPU 2808 via a D2D (die-to-die) or C2C (chip-to-chip) connection 2812, for example, a GRS (ground-referenced signaling) connection. The CPU 2806 can be coupled to the GPU 2810 via a D2D or C2C connection 2814. The CPU 2806 can also be coupled to the GPU 2808 and the GPU 2810 via PCIe connections. The CPU 2806 can be coupled with one or more NICs (Network Interface Cards) or DPUs (Data Processing Units), which are coupled to one or more networks. As shown in Fig. As illustrated in Figure 28, the CPU 2806 is, for example, coupled with a first NIC / DPU 2826, which is coupled to a network 2830. The CPU 2806 is also coupled with a second NIC / DPU 2828, which is coupled to the network 2830. The NIC / DPU 2826 and the NIC / DPU 2828 can be coupled to the network 2830 via ETH (Ethernet) or IB (InfiniBand) connections.

[0245] The Computing System 2800 also includes a Processing Device 2804 with a multi-GPU architecture. Specifically, the Processing Device 2804 includes a CPU 2816, a GPU 2818, and a GPU 2820. The CPU 2816 can be coupled to the GPU 2818 via a D2D or C2C connection 2822. The CPU 2816 can be coupled to the GPU 2820 via a D2D or C2C connection 2824. The CPU 2816 can also be coupled to the GPU 2818 and the GPU 2820 via PCIe connections. The CPU 2816 can be coupled to one or more NICs or DPUs, which are coupled to one or more networks. As described in Fig. As illustrated in Figure 28, the CPU 2816 is, for example, coupled with a first NIC / DPU 2832, which is coupled to a network 2836. The CPU 2816 is also coupled with a second NIC / DPU 2834, which is coupled to the network 2836. The NIC / DPU 2832 and the NIC / DPU 2834 can be coupled to the network 2836 via ETH (Ethernet) or IB (InfiniBand) connections.

[0246] In at least one embodiment, the processing device 2802 and the processing device 2804 can communicate with each other via a NIC / DPU 2838, for example via PCIe connections. The processing device 2802 and the processing device 2804 can also communicate with each other via a high-bandwidth communication link 2840, for example via an NVLink connection or other high-speed connections.

[0247] The NICs / DPUs of Fig. 28 can be the different embodiments of the DPUs discussed here in relation to Fig. 1 to Fig. 26 are described.

[0248] In at least one embodiment, the 2800 computing system is used for high-speed network communication and comprises a processing unit (e.g., CPU 2806, GPU 2808, GPU 2810, CPU 2816, GPU 2818, GPU 2820, NIC / DPU 2826, NIC / DPU 2828, NIC / DPU 2832, NIC / DPU 2834, or NIC / DPU 2838) and a network interface coupled to the processing unit. The network interface may include the operations and functions of the DPUs described herein.

[0249] In at least one embodiment, the 2800 computing system comprises a host device and an auxiliary device. The auxiliary device comprises a device memory and a processor that is communicatively coupled to the device memory. The auxiliary device performs the functions described here with regard to Fig. 1 to Fig. The 26 operations described. The additional device can include a GPU. The additional device can include a DPU. The additional device can include a DPU. The additional device can include accelerator hardware.

[0250] Fig. Figure 29 is a block diagram of a computing system 2900 comprising a CPU 2902 and a GPU 2904 in a single integrated circuit according to at least one embodiment. The computing system 2900 can be a highly integrated design in which a CPU 2902 and a GPU 2904 are connected on a single integrated circuit, using an NVLink C2C (chip-to-chip) link 2906 to enable fast, low-latency communication between the two processing units. This tight integration enables efficient data transfer and parallel processing between the CPU 2902 and the GPU 2904, thereby optimizing performance for complex computing tasks.The GPU elements within the Computing System 2900 can be interconnected via an NVLink network, enabling scalability to up to 256 GPU elements and creating a powerful, unified processing environment ideal for large-scale AI, ML, and high-performance computing applications. The NVLink network can be a GPU fabric comprised of high-bandwidth Communication Links 2910. Furthermore, the Computing System 2900 can be configured to connect to a high-speed I / O interface via PCIe Links 2908, ensuring rapid data transfer to and from external devices. This further enhances the system's ability to handle data-intensive tasks and provides robust connectivity to peripheral components.It should be noted that the C2C links 2906 can be considered D2D links, since the CPU 2902 and the GPU 2904 are located on the same integrated circuit. This integrated circuit can include CPU memory (also referred to as main memory) and GPU memory, which the CPU 2902 and GPU 2904, respectively, can access via high-speed links. The Computing System 2900 can combine the power of the GPU 2904 with the versatility of the CPU 2902. The CPU 2902 can be connected to a C2C link 2906 with high bandwidth and memory coherence on a single integrated circuit. The Computing System 2900 can support a link-switching system.

[0251] The 2900 computing system can be used for the various embodiments described herein with respect to Fig. 1 to Fig. 26 can be used.

[0252] In at least one embodiment, the 2900 computing system is used for high-speed network communication and comprises a processing unit and a network interface coupled to the processing unit. The network interface can include the operations and functions of the DPUs described herein.

[0253] In at least one embodiment, the computing system 2900 comprises a host device and an auxiliary device. The auxiliary device comprises a device memory and a processor communicatively coupled to the device memory. The auxiliary device performs the functions described herein with respect to Fig. 1 to Fig. The 26 operations described. The additional device can include a GPU. The additional device can include a DPU. The additional device can include a DPU. The additional device can include accelerator hardware.

[0254] Fig. Figure 30 is a block diagram of a Computing System 3000 with Tensor Core GPUs 3008 according to at least one embodiment. The Computing System 3000 can be a DGX H100 system, which is a high-performance computing platform designed for the requirements of AI, ML, and DL (Deep Learning) workloads. The Computing System 3000 can include multiple Tensor Core GPUs 3008 (e.g., NVIDIA H100 Tensor Core GPUs). Each Tensor Core GPU 3008 can perform one of the above-mentioned functions. Fig. The 29 integrated circuits described are Tensor Core GPUs 3008, which can be optimized for AI / ML / DL applications and offer exceptional performance for deep learning training, inference, and high-performance computing tasks. Within the Computing System 3000, the Tensor Core GPUs 3008 are interconnected via high-speed communication interfaces such as NVLinks, enabling rapid data transfer between them, which is crucial for processing large AI models and low-latency datasets. Designed for scalability, the Computing System 3000 allows for the integration of additional GPUs as needed, making it versatile enough for research, development, and data center deployments for production AI workloads. Each GPU is equipped with Tensor Cores, specialized processing units that accelerate matrix operations, a fundamental component of AI and deep learning algorithms.These Tensor Cores enable the system to efficiently perform mixed-precision computations, balancing speed and accuracy. Given the power consumption and heat generation of multiple Tensor Core GPUs 3008, the Computing System 3000 can be equipped with advanced cooling solutions and power management features to ensure safe operation at consistent peak performance. It is supported by a comprehensive software ecosystem, including NVIDIA's CUDA programming model, AI frameworks such as TensorFlow and PyTorch, and other HPC and AI software tools, allowing developers and researchers to leverage the full power of the Tensor Core GPUs 3008 for their specific applications.The Computing System 3000 is ideally suited for training large-scale AI models, real-time inference, scientific simulations, data analysis and other computationally intensive tasks that require enormous parallel computing power.

[0255] The Tensor Core GPUs 3008 can be coupled with multiple CPUs, such as CPUs 3002 and 3004, via switches 3006 (e.g., CX7 HCA / NIC with PCIe switch). The Tensor Core GPUs 3008 can be coupled with each other via switches 3010 (e.g., NVSwitches). Both switches 3006 and 3010 can be coupled with high-speed transceiver modules 3012. These high-speed transceiver modules can be OSFP (Octal Small Form-factor Pluggable) modules. OSFP modules are high-speed transceiver modules designed for high-speed data communication, particularly in bandwidth-intensive environments such as data centers and high-performance computing systems. These modules support extremely high data rates, typically up to 400 Gbit / s per module, with future capacities that can be expanded to 800 Gbit / s or more.OSFP modules connect to the system via the PCIe interface, enabling fast and efficient data transfer between the integrated CPU / GPU components and external networks or other connected systems. Their hot-plug capability allows them to be easily inserted or removed without shutting down the system, providing flexibility and ease of maintenance, which is crucial in mission-critical environments. Furthermore, OSFP modules are designed for high density, maximizing the number of high-speed connections in limited spaces, such as densely packed server racks.By adhering to the latest network standards, OSFP modules ensure that the Computing System 3000 continues to meet increasing data demands and can be upgraded to support future advances in network speeds, contributing to the overall performance and scalability of the system.

[0256] In at least one embodiment, the 3000 computing system can be considered a data network configuration with full-bandwidth, server-internal NVLinks. In this example, all eight 3008 Tensor Core GPUs can simultaneously utilize eighteen NVLinks to other GPUs within the server. Bandwidth is limited by over-utilization by multiple other GPUs. In another embodiment, the data network configuration can consist of half-bandwidth, server-internal NVLinks. In this example, all eight 3008 Tensor Core GPUs can utilize half of the eighteen NVLinks to GPUs in other servers. Four 3008 Tensor Core GPUs can utilize eighteen NVLinks to GPUs in other servers. This corresponds to full bandwidth with AllReduce using the SHARP (Scalable Hierarchical Aggregation and Reduction Protocol). Reducing the All-to-All (All-to-All) bandwidth is a trade-off between server complexity and cost.In at least one embodiment, all eight Tensor Core GPUs can independently transfer 3008 data using the RDMA (Remote Direct Memory Access) protocol over their own dedicated switch (e.g., 400 Gb / s HCA / NIC) in a multi-rail InfiniBand / Ethernet configuration. In this example, 800 GBps total full-duplex to non-NVLink network devices.

[0257] The NICs / switches of the Computing System 3000 can perform the various functions described herein with regard to Fig. 1 to Fig. 26 described embodiments are included.

[0258] In at least one embodiment, the 3000 computing system is used for high-speed network communication and comprises a processing unit (e.g., CPU 3002, CPU 3004, switches 3006, Tensor Core GPUs 3008, switches 3010, high-speed transceiver modules 3012) and a network interface coupled to the processing unit. The network interface may include the operations and functions of the DPUs described herein.

[0259] In at least one embodiment, the computing system 3000 comprises a host device and an auxiliary device. The auxiliary device comprises a device memory and a processor communicatively coupled to the device memory. The auxiliary device performs the functions described herein with respect to Fig. 1 to Fig.The 26 described operations are included. The additional device can include a GPU. The additional device can include a DPU. The additional device can include a DPU. The additional device can include accelerator hardware.

[0260] Other variations are within the meaning of the present disclosure. While various modifications and alternative constructions of the disclosed techniques are possible, certain illustrated embodiments are shown in the drawings and have been described in detail above. However, it is to be understood that the disclosure is not intended to be limited to any particular form(s), but rather that, on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the nature and scope of the disclosure, as defined in the attached claims.

[0261] The use of the terms "a" and "the" and similar designations in the context of describing disclosed embodiments (particularly in the context of the following claims) is to be interpreted as encompassing both the singular and the plural, unless otherwise specified herein or clearly contradicted by the context, and not as defining a term. The terms "comprising," "with," "including," and "containing" are to be understood as open terms (i.e., "including but not limited to"), unless otherwise specified. The term "connected," when unchanged and referring to physical connections, is to be understood as partially or wholly contained therein, attached to it, or joined together, even if something is in between.Specifications of value ranges are intended solely as a shorthand method for individually referencing each value falling within the range, unless otherwise stated herein, and each individual value is included in the specification as if it were listed therein individually. The use of the terms "set" (e.g., "a set of objects") or "subset," unless otherwise stated or contradicted by the context, is to be understood as a non-empty collection comprising one or more elements. Furthermore, the term "subset" of a corresponding set, unless otherwise noted or contradicted by the context, does not necessarily denote a true subset of the corresponding set; rather, subset and corresponding set may be the same.

[0262] Connectives, such as clauses of the form "at least one of A, B, and C" or "at least one of A, B, and C," are, unless expressly stated otherwise or clearly contradicted by the context, understood in the context as they are generally used to indicate that an object, concept, etc., can be either A, B, or C, or any non-empty subset of the set of A, B, and C. For example, in an illustrative example of a three-element sentence, the connectives "at least one of A, B, and C" and "at least one of A, B, and C" refer to one of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Such connectives are therefore not intended to generally imply that in certain embodiments, at least one of A, at least one of B, and at least one of C must be present.Furthermore, unless otherwise stated or contradicted by the context, the term "plural" indicates a state of plurality (e.g., "a plurality of items" refers to multiple items). A plurality is at least two items, but can also be greater if this is either explicitly stated or indicated by the context. Additionally, unless otherwise stated or evident from the context, the phrase "based on" means "at least partly based on" and not "exclusively based on".

[0263] Operations of the processes described herein may be performed in any suitable order unless otherwise specified herein or clearly contradicted by the context. In at least one embodiment, a process such as the processes described herein (or variations and / or combinations thereof) is performed under the control of one or more computer systems configured with executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that are executed collectively on one or more processors, by hardware, or combinations thereof. In at least one embodiment, code is stored on a computer-readable storage medium, e.g., in the form of a computer program comprising multiple instructions that can be executed by one or more processors.In at least one embodiment, a computer-readable storage medium is a non-volatile computer-readable storage medium that excludes transitory signals (e.g., a propagating transient electrical or electromagnetic transmission) but includes non-volatile data storage circuitry (e.g., buffers, caches, and queues) within transceivers for transitory signals. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-volatile, computer-readable storage media on which executable instructions (or other working memory for storing executable instructions) are stored. When executed (i.e., as a result of execution) by one or more processors of a computer system, these instructions cause the computer system to perform the operations described herein.In at least one embodiment, a set of non-volatile, machine-readable storage media comprises multiple non-volatile, machine-readable storage media, and one or more individual non-volatile storage media within a set of multiple non-volatile, machine-readable storage media lack all the code, while multiple non-volatile, machine-readable storage media collectively store all the code. In at least one embodiment, executable instructions are executed such that different instructions are executed by different processors—for example, a non-volatile, machine-readable storage medium stores instructions, and a main CPU executes some of the instructions, while a GPU executes other instructions. In at least one embodiment, different components of a computer system have separate processors, and different processors execute different subsets of instructions.

[0264] Accordingly, in at least one embodiment, computer systems are configured to implement one or more services that individually or collectively perform the process operations described herein, and such computer systems are configured with suitable hardware and / or software that enables the execution of the operations. Furthermore, a computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment, it is a distributed computer system comprising several devices that operate differently, such that the distributed computer system performs the operations described herein, and a single device does not perform all of the operations.

[0265] The use of any and all examples or illustrative expressions given herein (e.g., "such as") serves only to better illustrate embodiments of the disclosure and does not constitute a limitation of the scope of the disclosure unless otherwise claimed. No wording in the specification shall be construed as designating any unclaimed element as essential to the practice of the disclosure.

[0266] All references cited herein, including publications, patent applications and patents, are hereby incorporated by reference to the same extent as if each reference were individually and expressly stated as being incorporated by reference and set forth herein in its entirety.

[0267] The terms "coupled" and "connected," as well as their derivatives, may be used in the description and claims. It should be understood that these terms are not intended to be synonymous. Rather, in certain examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" may also mean that two or more elements are not in direct contact with each other but nevertheless cooperate or interact with one another.

[0268] It will be understood that, unless expressly stated otherwise, terms such as "processing", "calculating", "calculating", "determining" and the like throughout this specification refer to actions and / or processes of a computer or computing system or similar electronic computing device which manipulate and / or convert data represented as physical, e.g. electronic, quantities in the registers and / or working memories of the computing system into other data represented in a similar manner as physical quantities in the working memories, registers or other information storage, transmission or display devices of the computing system.

[0269] Similarly, the term "processor" can refer to any device or part of a device that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As a non-restrictive example, a "processor" can be a CPU or a GPU. A "computing platform" can include one or more processors. The term "software" processes, as used here, can include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Each process can also refer to multiple processes to execute instructions sequentially or in parallel, continuously or intermittently.The terms “system” and “method” are used interchangeably here, insofar as the system may comprise one or more methods and the methods may be considered as a system.

[0270] This document may contain references to obtaining, capturing, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. Obtaining, capturing, receiving, or inputting analog and digital data can occur in various ways, such as receiving data as parameters of a function call or an application programming interface (API) call. In some implementations, the process of obtaining, capturing, receiving, or inputting analog or digital data may be performed by transferring data over a serial or parallel interface. In another implementation, the process of obtaining, capturing, receiving, or inputting analog or digital data may be performed by transferring data over a computer network from the providing entity to the receiving entity.It can also refer to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be accomplished by transmitting data as an input or output parameter of a function call, a parameter of an application programming interface, or an interprocess communication mechanism.

[0271] While the descriptions contained herein represent exemplary embodiments of the described techniques, other architectures may also be used to implement the described functionality, provided they fall within the scope of this disclosure. Furthermore, although specific distributions of responsibilities may be defined above for descriptive purposes, various functions and responsibilities may be distributed and divided in different ways depending on the circumstances.

[0272] Furthermore, although the subject matter was described in a language specific to structural features and / or methodological actions, it should be understood that the subject matter claimed in the attached claims is not necessarily limited to the specific features or actions described. Rather, the specific features and actions are disclosed as exemplary forms of implementation of the claims.

[0273] It will be understood that the aspects and embodiments described herein are only exemplary and that changes may be made in detail within the scope of the claims.

[0274] Each device, method and feature disclosed in the description and (if applicable) in the claims and drawings can be provided independently or in any suitable combination.

[0275] The reference figures contained in the claims serve only for illustration and do not have a limiting effect on the scope of the claims.

[0276] The disclosure of this application also includes the following numbered clauses: Clause 1. A DPU (Data Processing Unit) comprising the following: an acceleration hardware engine to provide a single accelerated data layer; a memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; and a processing device that is operationally coupled with the main memory and the acceleration hardware engine, wherein the processing device serves, according to the configuration file, to: Creating the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is to be controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has a PBR (policy-based routing) policy; and Adding the virtual port between the first virtual bridge and the second virtual bridge; and where the acceleration hardware engine, in the single accelerated data layer, is intended to route network traffic data according to the PBR policy and process the network traffic data according to the set of one or more network rules. Clause 2. The DPU of Clause 1, wherein the processing device serves to: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge. Clause 3. The DPU of Clause 2, wherein the conformity condition is at least one specified by: a source IP (Internet Protocol) address a source or destination port; a protocol identifier; a VLAN (Virtual Local Area Network) tag; a DSCP (Differentiated Service Code Point) or ToS (Type of Service) value; an application or service type; and a time of day. Clause 4. The DPU of Clause 2, wherein the action comprises at least one of: a forwarding action; a rejection action; a diversion operation; a mirroring action; a load balancing action; a rate-limiting campaign; a QoS (Quality of Service) marking campaign; a traffic management action; an encapsulation action; and a diversion operation. Clause 5. The DPU of Clause 1, wherein the processing device according to the configuration file serves to: Adding one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Adding one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding an initial service interface to the initial virtual bridge for operational coupling with the initial network service, where the initial network service provides accelerated networking capabilities based on the set of one or more network rules. Clause 6. The DPU of Clause 5, wherein the set of one or more network rules includes at least one of an L2 (Layer 2) protocol rule, an L3 (Layer 3) protocol rule, a tunneling protocol rule, an ACL (Access Control List) rule, an ECMP (Equal-Cost Multi-Path) rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT (Connection Tracking) rule, a VLAN (Virtual Local Area Network) rule, and a NAT (Network Address Translation) rule. Clause 7. The DPU of Clause 5, wherein the set of one or more network rules comprises one or more steering rules, wherein the one or more steering rules include at least one of an application-based steering rule, a policy-based steering rule, a geolocation-based steering rule, a load balancing rule, a QoS (Quality of Service) rule, a backup rule, a redundancy rule, a safety-based steering rule, a cost-based routing rule, an SD-WAN (Software-defined Wide Area Network) path steering rule, and an SDN (Software-defined Networking) rule. Clause 8. The DPU of Clause 1, wherein the PBR policy is programmable by a user or a controller. Clause 9. The DPU of Clause 1, wherein the first virtual bridge and the second virtual bridge are OVS (Open vSwitch) bridges, wherein the processing device is to run an OVS application with hardware offload mechanisms to provide the single accelerated data plane in the acceleration hardware engine to route the network traffic data according to the PBR policy and to process the network traffic data according to the set of one or more network rules. Clause 10. The DPU of Clause 1, wherein the processing device according to the configuration file serves to: Adding one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; and Adding one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding an initial service interface to the initial virtual bridge for operational coupling with the initial network service; and Adding a second service interface to the second virtual bridge for the operational coupling of a second network service, the second network service, wherein the first network service and the second network service are part of an SFC (Service Function Chaining) infrastructure to provide accelerated network capabilities in the single accelerated data plane by means of a combined set of network rules, wherein the combined set of rules includes the set of one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service. Clause 11. Method for operating a DPU (Data Processing Unit) with an acceleration hardware engine to provide a single accelerated data plane, wherein the method comprises: Saving a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; Create, according to the configuration file, the first virtual bridge and the second virtual bridge, where the first virtual bridge is to be controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has a PBR (Policy-based Routing) policy; Add, according to the configuration file, the virtual port between the first virtual bridge and the second virtual bridge; Routing of network traffic data according to the PBR policy using the acceleration hardware engine in the individual accelerated data layer; and Processing network traffic data based on the set of network rules using the acceleration hardware engine in the individual accelerated data layer. Clause 12. The procedure of Clause 11, which further includes the following: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge. Clause 13. The procedure of Clause 12, wherein the conformity condition is specified by at least one of: a source IP (Internet Protocol) address a source or destination port; a protocol identifier; a VLAN (Virtual Local Area Network) tag; a DSCP (Differentiated Service Code Point) or ToS (Type of Service) value; an application or service type; and a time of day. Clause 14. The procedure of Clause 12, wherein the action comprises at least one of: a forwarding action; a rejection action; a diversion operation; a mirroring action; a load balancing action; a rate-limiting campaign; a QoS (Quality of Service) marking campaign; a traffic management action; an encapsulation action; and a diversion operation. Clause 15. The procedure of Clause 11, which further includes the following: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Add, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service, where the first network service is to provide accelerated network functions based on the set of one or more network rules. Clause 16. The procedure of Clause 12, which further includes the following: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service, wherein the first network service provides accelerated networking capabilities based on the set of one or more network rules, wherein the set of one or more network rules includes at least one of an L2 (Layer 2) protocol rule, an L3 (Layer 3) protocol rule, a tunneling protocol rule, an ACL (Access Control List) rule, an ECMP (Equal-Cost Multi-Path) rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT (Connection Tracking) rule, a VLAN (Virtual Local Area Network) rule, a NAT (Network Address Translation) rule, or one or more steering rules, wherein the one or more steering rules include at least one of an application-based steering rule, a policy-based steering rule, or a geolocation-based steering rule.a load balancing rule, a QoS (Quality of Service) rule, a backup rule, a redundancy rule, a safety-based routing rule, a cost-based routing rule, an SD-WAN (Software-defined Wide Area Network) path routing rule, and an SDN (Software-defined Networking) rule. Clause 17. The procedure under Clause 11, which further includes the following: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; and Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Add, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service; and Adding, according to the configuration file, a second service interface to the second virtual bridge for the operational coupling of a second network service, the second network service, wherein the second network service and the first network service are part of an SFC (Service Function Chaining) infrastructure to provide accelerated network capabilities in the single accelerated data plane by means of a combined set of network rules, wherein the combined set of rules includes the set of one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service. Clause 18. A computing system comprising the following: a host device; and an integrated circuit coupled to the host device and a network, wherein the integrated circuit comprises the following: a network connection coupled to the network; a host connection coupled to the host device; a memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; an acceleration hardware engine to provide a single accelerated data layer; and A CPU (Central Processing Unit) coupled with the network connection, the host connection, and the acceleration hardware engine, where the CPU is used for: Creating the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is to be controlled by a first network service hosted on the integrated circuit and has a set of one or more network rules, and wherein the second virtual bridge has a policy-based routing (PBR) policy; and Adding the virtual port between the first virtual bridge and the second virtual bridge; and where the acceleration hardware engine, in the single accelerated data layer, serves to: Routing of network traffic data based on the PBR policy; and Processing network traffic data based on a set of one or more network rules. Clause 19. The computing system of Clause 18, wherein the integrated circuit is at least one of a DPU (Data Processing Unit), a NIC (Network Interface Card), a network interface device and a switch, wherein the DPU is a programmable data center infrastructure on a chip. Clause 20. The computing system of Clause 18, where the CPU is used for: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 18 / 649.295

[0001] US 18 / 649,334

[0001] US 18 / 928,778

[0001] US 18 / 928,772

[0001]

Claims

[1] DPU (Data Processing Unit), which includes the following: an acceleration hardware engine to provide a single accelerated data layer; a memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; and a processing device that is operationally coupled with the main memory and the acceleration hardware engine, wherein the processing device serves, according to the configuration file, to: Creating the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is to be controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has a PBR (policy-based routing) policy; and Adding the virtual port between the first virtual bridge and the second virtual bridge; and where the acceleration hardware engine, in the single accelerated data layer, is intended to route network traffic data according to the PBR policy and process the network traffic data according to the set of one or more network rules. [2] DPU according to claim 1, wherein the processing device serves to: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge. [3] DPU according to claim 2, wherein the conformity condition of at least one is specified by: a source IP (Internet Protocol) address a source or destination port; a protocol identifier; a VLAN (Virtual Local Area Network) tag; a DSCP (Differentiated Service Code Point) or ToS (Type of Service) value; an application or service type; and a time of day. [4] DPU according to claim 2 or 3, wherein the action comprises at least one of: a forwarding action; a rejection action; a diversion operation; a mirroring action; a load balancing action; a rate-limiting campaign; a QoS (Quality of Service) marking campaign; a traffic management action; an encapsulation action; and a diversion operation. [5] DPU according to a previous claim, wherein the processing device according to the configuration file serves to: Adding one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Adding one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding an initial service interface to the initial virtual bridge for operational coupling with the initial network service, where the initial network service provides accelerated networking capabilities based on the set of one or more network rules. [6] DPU according to claim 5, wherein the set of one or more network rules comprises at least one of an L2 (Layer 2) protocol rule, an L3 (Layer 3) protocol rule, a tunneling protocol rule, an ACL (Access Control List) rule, an ECMP (Equal-Cost Multi-Path) rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT (Connection Tracking) rule, a VLAN (Virtual Local Area Network) rule and a NAT (Network Address Translation) rule. [7] DPU according to claim 5 or 6, wherein the set of one or more network rules comprises one or more steering rules, wherein the one or more steering rules include at least one of an application-based steering rule, a policy-based steering rule, a geolocation-based steering rule, a load balancing rule, a QoS (Quality of Service) rule, a backup rule, a redundancy rule, a safety-based steering rule, a cost-based routing rule, an SD-WAN (Software-defined Wide Area Network) path steering rule and an SDN (Software-defined Networking) rule. [8] DPU according to a previous claim, wherein the PBR policy is programmable by a user or a controller. [9] DPU according to a previous claim, wherein the first virtual bridge and the second virtual bridge are OVS (Open vSwitch) bridges, wherein the processing device is to run an OVS application with hardware offload mechanisms to provide the single accelerated data plane in the acceleration hardware engine to route the network traffic data according to the PBR policy and to process the network traffic data according to the set of one or more network rules. [10] DPU according to a previous claim, wherein the processing device according to the configuration file serves to: Adding one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; and Adding one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding an initial service interface to the initial virtual bridge for operational coupling with the initial network service; and Adding a second service interface to the second virtual bridge for the operational coupling of a second network service, the second network service, wherein the first network service and the second network service are part of an SFC (Service Function Chaining) infrastructure to provide accelerated network capabilities in the single accelerated data plane by means of a combined set of network rules, wherein the combined set of rules includes the set of one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service. [11] Method for operating a DPU (Data Processing Unit) with an acceleration hardware engine to provide a single accelerated data plane, the method comprising: Saving a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; Create, according to the configuration file, the first virtual bridge and the second virtual bridge, where the first virtual bridge is to be controlled by a first network service hosted on the DPU and has a set of one or more network rules, and the second virtual bridge has a PBR (Policy-based Routing) policy; Add, according to the configuration file, the virtual port between the first virtual bridge and the second virtual bridge; Routing of network traffic data according to the PBR policy using the acceleration hardware engine in the individual accelerated data layer; and Processing network traffic data based on the set of network rules using the acceleration hardware engine in the individual accelerated data layer. [12] The method of claim 11, further comprising: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge. [13] Method according to claim 12, wherein the conformity condition is specified by at least one of: a source IP (Internet Protocol) address a source or destination port; a protocol identifier; a VLAN (Virtual Local Area Network) tag; a DSCP (Differentiated Service Code Point) or ToS (Type of Service) value; an application or service type; and a time of day. [14] Method according to claim 12 or 13, wherein the action comprises at least one of: a forwarding action; a rejection action; a diversion operation; a mirroring action; a load balancing action; a rate-limiting campaign; a QoS (Quality of Service) marking campaign; a traffic management action; an encapsulation action; and a diversion operation. [15] A method according to any one of claims 11-14, further comprising: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Add, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service, where the first network service is to provide accelerated network functions based on the set of one or more network rules. [16] A method according to any one of claims 12-15, further comprising: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Adding, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service, wherein the first network service provides accelerated networking capabilities based on the set of one or more network rules, wherein the set of one or more network rules includes at least one of an L2 (Layer 2) protocol rule, an L3 (Layer 3) protocol rule, a tunneling protocol rule, an ACL (Access Control List) rule, an ECMP (Equal-Cost Multi-Path) rule, a tunneling encapsulation rule, a tunneling decapsulation rule, a CT (Connection Tracking) rule, a VLAN (Virtual Local Area Network) rule, a NAT (Network Address Translation) rule, or one or more steering rules, wherein the one or more steering rules include at least one of an application-based steering rule, a policy-based steering rule, or a geolocation-based steering rule.a load balancing rule, a QoS (Quality of Service) rule, a backup rule, a redundancy rule, a safety-based routing rule, a cost-based routing rule, an SD-WAN (Software-defined Wide Area Network) path routing rule, and an SDN (Software-defined Networking) rule. [17] A method according to any one of claims 11-16, further comprising: Add, according to the configuration file, one or more host interfaces to the second virtual bridge for operational coupling with one or more host devices operationally coupled to the DPU; and Add, according to the configuration file, one or more network interfaces to the first virtual bridge for operational coupling with one or more network ports of the DPU; and Add, according to the configuration file, a first service interface to the first virtual bridge for operational coupling with the first network service; and Adding, according to the configuration file, a second service interface to the second virtual bridge for the operational coupling of a second network service, the second network service, wherein the second network service and the first network service are part of an SFC (Service Function Chaining) infrastructure to provide accelerated network capabilities in the single accelerated data plane by means of a combined set of network rules, wherein the combined set of rules includes the set of one or more network rules associated with the first network service and a second set of one or more network rules associated with the second network service. [18] Computing system comprising the following: a host device; and an integrated circuit coupled to the host device and a network, wherein the integrated circuit comprises the following: a network connection coupled to the network; a host connection coupled to the host device; a memory for storing a configuration file that specifies at least one first virtual bridge, one second virtual bridge, and one virtual port between the first virtual bridge and the second virtual bridge; an acceleration hardware engine to provide a single accelerated data layer; and A CPU (Central Processing Unit) coupled with the network connection, the host connection, and the acceleration hardware engine, where the CPU is used for: Creating the first virtual bridge and the second virtual bridge, wherein the first virtual bridge is to be controlled by a first network service hosted on the integrated circuit and has a set of one or more network rules, and wherein the second virtual bridge has a policy-based routing (PBR) policy; and Adding the virtual port between the first virtual bridge and the second virtual bridge; and where the acceleration hardware engine, in the single accelerated data layer, serves to: Routing of network traffic data based on the PBR policy; and Processing network traffic data based on a set of one or more network rules. [19] Computing system according to claim 18, wherein the integrated circuit is at least one of a DPU (Data Processing Unit), a NIC (Network Interface Card), a network interface device and a switch, wherein the DPU is a programmable data center infrastructure on a chip. [20] Computing system according to claim 18 or 19, wherein the CPU serves to: Receiving user input from a user or a controller, wherein the user input specifies the PBR policy, the PBR policy comprising one or more routing rules, each comprising a compliance condition and a corresponding action; and Adding the PBR policy to the second virtual bridge.

Images