Data processing unit, communication method and system, medium, computer program product
By creating virtual devices inside the DPU and using hardware flow table rules to achieve direct hardware-level forwarding between the host and the DPU-side processor, the latency and complexity issues caused by indirect communication paths in existing technologies are resolved, achieving low-latency and high-reliability communication.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN JAGUAR MICROSYSTEMS CO LTD
- Filing Date
- 2026-05-09
- Publication Date
- 2026-06-05
Smart Images
Figure CN122160347A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of data processing and communication technology, specifically to a data processing unit, a communication method and system, a computer-readable storage medium, and a computer program product. Background Technology
[0002] In current data center server architectures employing Data Processing Units (DPUs), communication between the host and the DPU's built-in processor is a fundamental requirement for device management and status monitoring. This communication typically relies on network protocol stacks and virtual switching logic. For example, a typical implementation utilizes Single Root Input / Output Virtualization (SR-IOV) technology to directly pass the DPU's Virtual Function (VF) to the host. Simultaneously, a virtual network interface card (NIC) is simulated within the DPU for the built-in processor, and the host's VF is connected to the built-in processor's NIC via a virtual switch within the DPU or SR-IOV hardware switching logic. In this approach, data packets sent by the host must undergo parsing and forwarding processing by the internal virtual switching logic after entering the DPU before reaching the DPU's built-in processor.
[0003] Because data packets still need to undergo processing by virtual switching logic within the DPU, the communication path is not a direct hardware-level interconnection. This indirect forwarding mechanism not only introduces unnecessary processing delays, leading to bottlenecks in communication performance, but also increases the complexity and potential for failure of the system due to the involvement of virtual switching logic, making it impossible to meet the requirements for extremely low latency and high reliability communication between the host and the DPU's built-in processor. Summary of the Invention
[0004] The purpose of this application is to provide a data processing unit, a communication method and system, a computer-readable storage medium, and a computer program product to achieve efficient communication between the data processing unit and the host.
[0005] To achieve the above objectives, according to the first aspect of this application, a data processing unit (DPU) is proposed, including a DPU-side processor, a firmware processing module, a first virtual port module, a second virtual port module, and a data forwarding module;
[0006] The firmware processing module is used to run firmware when the data processing unit starts up, create and initialize a first virtual device in the first virtual port module, and create and initialize a second virtual device in the second virtual port module; wherein, the first virtual device is used to be presented to the host, and the second virtual device is used for internal use by the data processing unit; The DPU-side processor is used to run the DPU operating system and the device management process. The DPU operating system is used to load the driver for the second virtual device. The device management process is used to send hardware flow table rules to the data forwarding module after detecting that the host has loaded the driver for the first virtual device. The data forwarding module is used to store the hardware flow table rules; wherein the hardware flow table rules indicate that data packets from the first virtual device should be forwarded to the second virtual device; The first virtual port module is used to receive data packets sent by the host and store the data packets in the sending queue of the first virtual device; The data forwarding module is further configured to obtain the data packet from the sending queue of the first virtual device and forward the data packet to the receiving queue of the second virtual device according to the hardware flow table rules; The DPU-side processor is also used to obtain the data packet from the receive queue of the second virtual device.
[0007] In one implementation, the hardware flow table rule includes key information and action information, wherein the key information is the device identifier of the first virtual device, and the action information is the device identifier of the second virtual device; The data forwarding module is specifically used to obtain the data packet from the sending queue of the first virtual device, extract the source device identifier of the data packet, and if the source device identifier is consistent with the key information, forward the data packet to the receiving queue of the second virtual device according to the action information.
[0008] In one embodiment, the second virtual port module is further configured to send a notification to the DPU-side processor via a doorbell mechanism after the data packet is stored in the receiving queue of the second virtual device. The DPU-side processor is specifically used to respond to the notification and obtain the data packet from the receive queue of the second virtual device.
[0009] In one implementation, both the first virtual device and the second virtual device are virtual network devices that conform to the standard virtio-net device specification; The DPU operating system loads a standard virtio-net driver for the second virtual device to recognize the second virtual device as a local standard network device on the DPU side. The host loads a standard virtio-net driver for the first virtual device to identify the first virtual device as a local standard network device on the host side.
[0010] In one implementation, the first virtual device is configured with a first IP address, and the second virtual device is configured with a second IP address that is in the same network segment as the first IP address; The data packets received by the first virtual port module from the host are data packets sent to the first virtual device by the network application on the host after determining that the target IP address is the second IP address, through the system network protocol stack of the host.
[0011] In one implementation, the first virtual port module includes a plurality of first virtual devices, each of which corresponds to a host. The firmware processing module is specifically used to create and initialize a plurality of first virtual devices in the first virtual port module, and to create and initialize a plurality of second virtual devices that are paired with the plurality of first virtual devices in the second virtual port module. The data forwarding module is specifically used to store multiple hardware flow table rules; wherein, the multiple hardware flow table rules correspond to the pairing relationships of the multiple first virtual devices and the multiple second virtual devices, and are used to respectively instruct data packets from different first virtual devices to be forwarded to the corresponding second virtual devices.
[0012] In one embodiment, the firmware processing module is specifically used to create and initialize a plurality of first virtual devices and a plurality of second virtual devices according to pre-configuration information. The pre-configuration information includes: the number of first virtual devices to be created, the mapping relationship between each first virtual device and its corresponding host, the pairing relationship between each first virtual device and its corresponding second virtual device, and the hardware resource allocation parameters of each virtual device.
[0013] According to a second aspect of this application, a communication method is proposed, applied to a data processing unit as described in the first aspect, the method comprising: When the data processing unit starts, a first virtual device is created and initialized in the first virtual port module through firmware, and a second virtual device is created and initialized in the second virtual port module; wherein, the first virtual device is used to be presented to the host, and the second virtual device is used for internal use by the data processing unit; The DPU operating system, running on the DPU-side processor, loads the driver for the second virtual device; After the device management process running on the DPU side processor detects that the host has loaded the driver for the first virtual device, it issues a hardware flow table rule to the data forwarding module; wherein, the hardware flow table rule instructs that data packets from the first virtual device be forwarded to the second virtual device; The first virtual port module receives data packets sent by the host and stores the data packets in the sending queue of the first virtual device. The data forwarding module obtains the data packet from the sending queue of the first virtual device and forwards the data packet to the receiving queue of the second virtual device according to the hardware flow table rules. The data packet is obtained from the receive queue of the second virtual device by the DPU-side processor.
[0014] According to a third aspect of this application, a communication system is proposed, including a host and a data processing unit as proposed in the first aspect of this application, wherein the host and the data processing unit are connected via a bus. The host is used to load a driver for the first virtual device to identify it as a local network device and send the data packet to the first virtual port module.
[0015] According to a fourth aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in the first aspect.
[0016] According to a fifth aspect of this application, a computer program product is proposed, comprising a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.
[0017] This application discloses a data processing unit, a communication method and system, a computer-readable storage medium, and a computer program product, which have the following beneficial effects: The DPU of this application creates a pair of virtual devices (a first virtual device and a second virtual device) internally via firmware during startup. The first virtual device acts as a network device on the host side, and the second virtual device acts as a network device on the DPU side. Corresponding hardware flow table rules are configured in the data forwarding module. Through these hardware flow table rules, a one-to-one hardware-level direct forwarding path is established between the first and second virtual devices. After the data packets sent by the host enter the DPU, they completely bypass the parsing of the internal virtual switching logic and the intervention of the software kernel. The hardware forwarding plane directly completes the precise cross-queue transport and directly reaches the DPU-side processor, completely eliminating the processing latency and system overhead caused by software switching. This can meet the requirements of extremely low latency and high reliability communication between the host and the DPU-side processor.
[0018] Other features and advantages of this application will be set forth in the following description. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a schematic diagram of the structure of a data processing unit (DPU) in one embodiment of this application; Figure 2 This is a schematic diagram of the data flow interaction between the host and the DPU-side processor in one embodiment of this application; Figure 3 This is a schematic diagram of a virtual device pairing architecture in a multi-host scenario according to one embodiment of this application; Figure 4 This is a flowchart of a communication method in one embodiment of this application.
[0021] Marked in the image: 1-Data Processing Unit (DPU); 11-DPU-side Processor; 111-DPU-side Operating System; 112-Device Management Process; 12-Firmware Processing Module; 121-Firmware; 13-First Virtual Port Module; 131-First Virtual Device; 14-Second Virtual Port Module; 141-Second Virtual Device; 15-Data Forwarding Module; 151-Hardware Flow Table Rules; 2-Host. Detailed Implementation
[0022] The detailed description of the accompanying drawings is intended to illustrate the present preferred embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functions may be performed by different embodiments intended to be included within the scope of this application.
[0023] refer to Figures 1 to 2 One embodiment of this application proposes a data processing unit (DPU), including a DPU-side processor 11, a firmware processing module 12, a first virtual port module 13, a second virtual port module 14, and a data forwarding module 15.
[0024] Specifically, in the architecture design of this application embodiment, the first virtual port module 13 corresponds to the host 2 side as a hardware interface entity facing the host, and the second virtual port module 14 corresponds to the DPU side as a hardware interface entity facing the internal processing core of the DPU. By logically decoupling the port modules on the host side and the DPU side, a hardware foundation is laid for subsequent hardware flow table pass-through forwarding.
[0025] The firmware processing module 12 is used to run firmware 121 when the data processing unit 1 starts, create and initialize a first virtual device 131 in the first virtual port module 13, and create and initialize a second virtual device 141 in the second virtual port module 14; wherein, the first virtual device 131 is used to be presented to the host 2, and the second virtual device 141 is used for internal use of the data processing unit 1. Specifically, during the power-on startup phase of the data processing unit, the firmware processing module 12 runs the underlying firmware 121 code to initialize a pair of virtual network devices in the hardware virtualization engines corresponding to the first virtual port module 13 and the second virtual port module 14. The first virtual device 131 is manifested on the hardware bus as an independent device entity configured to be transparently transmitted to the external host 2, while the second virtual device 141 is created inside the DPU and is invisible to the host, exclusively for use by the DPU's built-in processing core. The two form a potential binding relationship at the hardware queue level.
[0026] The DPU-side processor 11 is used to run the DPU-side operating system 111 and the device management process 112. The DPU-side operating system 111 is used to load the driver for the second virtual device 141. The device management process 112 is used to send hardware flow table rules 151 to the data forwarding module 15 after detecting that the host 2 has loaded the driver for the first virtual device 131. Specifically, after the DPU-side processor 11 starts the DPU-side operating system 111, it performs bus enumeration to discover the second virtual device 141 and automatically loads the corresponding standard network driver to complete its enumeration and initialization. At the same time, the device management process 112 running in user mode non-intrusively perceives the host-side driver loading status by reading the status identifier of the first virtual device 131 in the hardware configuration space. In computer architecture, the configuration space refers to a standardized area of memory or registers exposed by a hardware device (or virtual hardware device) to the operating system or firmware for reading and writing by the system, thereby realizing plug-and-play functionality, status reporting, and parameter management of the device. Configuration, etc.; The configuration space of a virtual device can be structurally divided into a standard header area and a device-specific area, including vendor and device identifiers for system identification, a device status register reflecting the current operating status of the device, a command register controlling device I / O and memory access behaviors, a list of capability registers declaring advanced device features, and a base address register (BAR). The base address register is used to map and store the starting addresses of key operating parameters allocated by the operating system to the virtual device, such as the data transmission and reception queues, available buffers, and interrupt notifications, in the host's physical memory, thereby providing the underlying addressing basis for data interaction between software and hardware. Since the first virtual device 131 conforms to the standard virtualization device specification, the host-side standard driver writes a specific status flag indicating driver readiness to the configuration space of the first virtual device 131 upon initialization. The device management process 112 can determine whether the host-side driver has loaded and is ready by polling and reading this specific status flag or receiving a hardware interrupt. Once the driver is detected as ready, the configured hardware flow table rules 151 are immediately sent to the data forwarding module 15.
[0027] The data forwarding module 15 is used to store the hardware flow table rule 151; wherein, the hardware flow table rule 151 indicates that data packets from the first virtual device 131 are forwarded to the second virtual device 141; Specifically, the data forwarding module 15, as a dedicated hardware forwarding surface within the data processing unit, opens a dedicated channel in the hardware that spans the host side and the DPU side according to the issued hardware flow table rule 151. This allows data packets coming from the first virtual device 131 to no longer be sent to the default software virtual switch for complex routing table lookups, but instead be directly redirected to the paired second virtual device 141 according to the rules.
[0028] The first virtual port module 13 is used to receive data packets sent by the host 2 and store the data packets in the sending queue of the first virtual device 131; Specifically, after the application on host 2 generates data, it submits it downwards. The data packets are encapsulated and processed by the kernel network protocol stack of the host operating system. Since the first virtual device 131 is recognized as a local standard network device on the host side, the host's protocol stack will eventually call the driver corresponding to the standard network device to write the data packets into the hardware transmission queue mapped by the first virtual device 131 in the host memory. The first virtual port module 13, as the underlying backend of the hardware transmission queue, directly obtains these data packets from the shared memory.
[0029] The data forwarding module 15 is further configured to obtain the data packet from the sending queue of the first virtual device 131 and forward the data packet to the receiving queue of the second virtual device 141 according to the hardware flow table rule 151. The DPU-side processor 11 is also configured to obtain the data packet from the receive queue of the second virtual device 141; Specifically, in this embodiment, after the host-side driver writes the data packet into the hardware transmission queue mapped by the first virtual device 131, the data forwarding module 15, as a dedicated hardware forwarding plane, directly listens to and reads the data packet from the transmission queue. It then extracts the information carried by the data packet and matches it against the pre-stored hardware flow table rules 151. Upon a match, the data packet is directly moved to the corresponding receiving queue of the second virtual device 141. This entire process completely bypasses the interrupt response of the DPU-side processor 11 and the parsing of the software kernel protocol stack, achieving extremely low-latency cross-queue transport without CPU intervention. Subsequently, the DPU-side processor 11 can read the data packet from the receiving queue into local memory for processing by the application process within the DPU.
[0030] In some embodiments, the hardware flow table rule 151 includes key information and action information, wherein the key information is the device identifier of the first virtual device 131, and the action information is the device identifier of the second virtual device 141; Specifically, the device identifier can be a unique queue number or port index assigned by the hardware. If the identifier of the data packet source extracted by the data forwarding module 15 is consistent with the key information in the hardware flow table rule, then the action is executed to directly deliver the data packet to the receiving queue corresponding to the target identifier specified in the action information.
[0031] The data forwarding module 15 is specifically used to obtain the data packet from the sending queue of the first virtual device 131, extract the source device identifier of the data packet, and if the source device identifier is consistent with the key information, forward the data packet to the receiving queue of the second virtual device 141 according to the action information.
[0032] Specifically, the matching and forwarding process based on hardware flow table rules is entirely implemented by the hardware logic of the data forwarding module 15 without involving the interrupt response and software code execution of the DPU-side processor 11. Therefore, the forwarding latency is extremely low, thus completely solving the performance bottleneck caused by software switching.
[0033] In some embodiments, the second virtual port module 14 is further configured to send a notification to the DPU-side processor 11 via a doorbell mechanism after the data packet is stored in the receiving queue of the second virtual device 141. Specifically, the doorbell mechanism is a hardware mechanism in the virtualization device standard used to notify the device that new data has arrived. After the data packet is written into the receive queue by the hardware, the second virtual port module 14 sends the notification by writing to a specific memory address or triggering a hardware interrupt.
[0034] The DPU-side processor 11 is specifically used to respond to the notification and obtain the data packet from the receive queue of the second virtual device 141.
[0035] Specifically, after the operating system of the DPU-side processor 11 receives the doorbell notification, it wakes up the corresponding driver context and retrieves data packets from the receiving queue in batches and submits them to the upper-layer protocol stack to complete the efficient packet receiving process.
[0036] In some embodiments, the first virtual device 131 and the second virtual device 141 are both virtual network devices that conform to the standard virtio-net device specification; The DPU-side operating system 111 loads a standard virtio-net driver for the second virtual device 141 to recognize the second virtual device 141 as a local standard network device on the DPU side. Specifically, the DPU can recognize and use the second virtual device 141 by using the standard network driver that comes with its DPU-side operating system 111, without the need to write specific firmware code.
[0037] The host 2 loads a standard virtio-net driver for the first virtual device 131 to identify the first virtual device 131 as a local standard network device on the host side. Specifically, after the host system discovers the first virtual device 131, it only needs to load the native standard driver and use the regular network configuration commands to enable the network card. For users, the experience is exactly the same as inserting a regular physical network card.
[0038] It should be noted that in this embodiment, the first virtual device and the second virtual device are identical to the general physical network card standards (such as virtio-net or PCIe specifications) in terms of underlying hardware interaction logic and status register definition. This makes it impossible for the host operating system to detect its virtual nature when enumerating the bus. As a result, it can directly call the system's native, unmodified general network card driver to complete the identification and binding of the device. This completely eliminates the tedious process of developing, installing and maintaining specific private drivers on the host side, and truly achieves zero intrusion and transparent connection to the host system software stack.
[0039] In some embodiments, the first virtual device 131 is configured with a first IP address, and the second virtual device 141 is configured with a second IP address that is in the same network segment as the first IP address; Specifically, for example, the first virtual device 131 is configured with an Internet Protocol address of 192.168.1.1 / 24, and the second virtual device 141 is configured with an Internet Protocol address of 192.168.1.2 / 24.
[0040] The data packets received by the first virtual port module 13 from the host 2 are data packets sent to the first virtual device 131 by the network application on the host 2 after determining that the target IP address is the second IP address, through the system network protocol stack of the host 2. Specifically, when the network application on host 2 determines that the target IP address is the second IP address, it will send the data packet to the first virtual device, i.e., the first virtual port module 13, based on the second IP address. After receiving the data packet, the first virtual port module 13 will store the data packet in the corresponding sending queue of the first virtual device, indicating that the host sent a data packet through the first virtual device.
[0041] In some embodiments, reference Figure 3 The data processing unit 1 is connected to multiple hosts 2; Specifically, in a multi-node server scenario, for example, a data processing unit can connect to multiple computing nodes simultaneously through a bus switching architecture and needs to achieve the reuse of physical resources. In the underlying chip architecture, the data processing unit contains a unified first virtual port module 13 and a second virtual port module 14. The first virtual port module 13 instantiates multiple first virtual devices 131 logical entities corresponding to multiple hosts 2, and the second virtual port module 14 instantiates multiple second virtual devices 141 logical entities.
[0042] The firmware processing module 12 is specifically used to create and initialize a plurality of first virtual devices 131 corresponding to the plurality of hosts 2 in the first virtual port module 13, and to create and initialize a plurality of second virtual devices 141 paired with the plurality of first virtual devices 131 in the second virtual port module 14. Specifically, the firmware processing module 12 allocates resources in the first virtual port module 13 to create a first virtual device cluster containing multiple first virtual devices 131, and creates a corresponding second virtual device cluster 141 in the second virtual port module 14. The multiple first virtual devices 131 and multiple second virtual devices 141 in the cluster are logically bound one-to-one, forming multiple non-interfering communication paths to correspond to the communication needs of different hosts.
[0043] The data forwarding module 15 is specifically used to store multiple hardware flow table rules 151; wherein, the multiple hardware flow table rules 151 correspond to the pairing relationships of the multiple first virtual devices 131 and the multiple second virtual devices 141, and are used to respectively indicate that data packets from different first virtual devices 131 are forwarded to the corresponding second virtual devices 141. Specifically, the data forwarding module 15 maintains a multi-row flow table internally. Different rules accurately direct data from different first virtual devices 131 to their respective paired second virtual devices 141, thereby realizing high-concurrency isolated communication from multiple hosts to the internal system.
[0044] In some embodiments, the firmware processing module 12 is specifically used to create and initialize a plurality of first virtual devices 131 and a plurality of second virtual devices 141 according to pre-configuration information. The pre-configuration information includes, but is not limited to: the number of first virtual devices 131 to be created, the mapping relationship between each first virtual device 131 and the corresponding host 2, the pairing relationship between each first virtual device 131 and the corresponding second virtual device 141, and the hardware resource allocation parameters of each virtual device. Specifically, the number of the first virtual devices 131 to be created determines how many host-facing front-end windows the DPU needs to virtualize, which directly corresponds to the scale in the physical deployment scenario. For example, if a DPU card is configured with 8, it means that the DPU has the hardware capability to connect to and serve 8 physical hosts (or 8 virtual machines) at the same time.
[0045] The mapping relationship between each first virtual device 131 and the corresponding host 2 is used to establish the ownership binding between the virtual device and the physical bus. At the hardware level (such as in the PCIe bus topology), it is clear that which first virtual device belongs to which host's bus. This is the basis for achieving physical isolation and ensuring that host A can never see the virtual devices of host B, thus preventing unauthorized access or bus conflicts.
[0046] The pairing relationship between each of the first virtual devices 131 and the corresponding second virtual devices 141 establishes a one-to-one correspondence between the front-end entry and the back-end exit, indicating that after the traffic of host A enters the DPU, it can only and must be directed to a specific internal second virtual device, ensuring that the management data flow between different hosts is completely isolated at the hardware queue level and does not interfere with each other.
[0047] The hardware resource allocation parameters for each virtual device allocate specific underlying hardware resource quotas to each pair of paired virtual devices, including but not limited to the starting address and capacity of the direct memory access (DMA) memory pool, the depth of the send / receive queue, the size of the descriptor ring, and the interrupt vector number. These parameters ensure that each communication channel has exclusive cache space and queue resources at the hardware level, avoiding resource contention in multi-host high-concurrency scenarios and ensuring the absolute determinism of the hardware topology after system restart.
[0048] refer to Figure 4 Another embodiment of this application proposes a communication method applied to a data processing unit as described in the above embodiments of this application, the method comprising: Step S101: When the data processing unit starts, a first virtual device is created and initialized in the first virtual port module through firmware, and a second virtual device is created and initialized in the second virtual port module; wherein, the first virtual device is used to be presented to the host, and the second virtual device is used for internal use by the data processing unit; Step S102: The DPU operating system running on the DPU side processor loads the driver for the second virtual device; Step S103: After the device management process running on the DPU side processor detects that the host has loaded the driver for the first virtual device, it issues a hardware flow table rule to the data forwarding module; wherein, the hardware flow table rule indicates that the data packets from the first virtual device should be forwarded to the second virtual device; Step S104: Receive data packets sent by the host through the first virtual port module and store the data packets in the sending queue of the first virtual device; Step S105: Obtain the data packet from the sending queue of the first virtual device through the data forwarding module, and forward the data packet to the receiving queue of the second virtual device according to the hardware flow table rules; Step S106: Obtain the data packet from the receive queue of the second virtual device through the DPU-side processor.
[0049] It should be noted that the method in this embodiment corresponds to the data processing unit described in the above embodiments. Therefore, any content not detailed in this embodiment can be obtained by referring to the content of the data processing unit in the above embodiments, and will not be repeated in this embodiment.
[0050] Another embodiment of this application provides a communication system including a host and a data processing unit as described in the above embodiments of this application, wherein the host and the data processing unit are connected via a PCIe bus; Specifically, in a typical physical deployment, the communication system can be a server node equipped with an intelligent data processing unit, with the host acting as the central processing unit and physically interconnected with the data processing unit via a high-speed serial bus.
[0051] The host is used to load a driver for the first virtual device to identify it as a local network device and send the data packet to the first virtual port module.
[0052] Specifically, the host, as a standard computing platform, is only responsible for running services and interacts with the data processing unit for management plane data through a standard native network protocol stack, so as to completely offload the burden of underlying hardware control.
[0053] Another embodiment of this application provides a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in the above embodiments.
[0054] Specifically, the computer-readable storage medium can be any medium that can contain, store, transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. For example, a computer-readable storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. Specific examples include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, or any suitable combination of the foregoing. When the computer program is loaded onto a computer or other programmable data processing device, it causes the computer or other programmable data processing device to perform a series of operational steps to produce a computer-implemented process, thereby providing instructions executable on the computer or other programmable device to implement the steps of the methods of the above embodiments or the functionality of the data processing unit of the above embodiments.
[0055] According to another embodiment of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.
[0056] Specifically, the computer program product may be embodied as program code for causing a computer system to perform some or all of the steps of the method described in the embodiments of this application. The computer program product may be one or more computer-readable media storing computer-readable program code, which may be accessed, retrieved, loaded, and executed by one or more processors. Various components of the computer program product may be implemented according to various programming languages and / or technologies. The program code may be written in any combination of one or more programming languages, including assembly language, C / C++, Perl, Python, etc. The program code may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer.
[0057] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many updates and modifications will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A data processing unit, characterized in that, It includes a DPU-side processor, a firmware processing module, a first virtual port module, a second virtual port module, and a data forwarding module; The firmware processing module is used to run firmware when the data processing unit starts up, create and initialize a first virtual device in the first virtual port module, and create and initialize a second virtual device in the second virtual port module; wherein, the first virtual device is used to be presented to the host, and the second virtual device is used for internal use by the data processing unit; The DPU-side processor is used to run the DPU operating system and the device management process. The DPU operating system is used to load the driver for the second virtual device. The device management process is used to send hardware flow table rules to the data forwarding module after detecting that the host has loaded the driver for the first virtual device. The data forwarding module is used to store the hardware flow table rules; wherein the hardware flow table rules indicate that data packets from the first virtual device should be forwarded to the second virtual device; The first virtual port module is used to receive data packets sent by the host and store the data packets in the sending queue of the first virtual device; The data forwarding module is further configured to obtain the data packet from the sending queue of the first virtual device and forward the data packet to the receiving queue of the second virtual device according to the hardware flow table rules; The DPU-side processor is also used to obtain the data packet from the receive queue of the second virtual device.
2. The data processing unit according to claim 1, characterized in that, The hardware flow table rules include key information and action information, wherein the key information is the device identifier of the first virtual device, and the action information is the device identifier of the second virtual device; The data forwarding module is specifically used to obtain the data packet from the sending queue of the first virtual device, extract the source device identifier of the data packet, and if the source device identifier is consistent with the key information, forward the data packet to the receiving queue of the second virtual device according to the action information.
3. The data processing unit according to claim 1, characterized in that, Both the first virtual device and the second virtual device are virtual network devices that conform to the standard virtio-net device specification; The DPU operating system loads a standard virtio-net driver for the second virtual device to recognize the second virtual device as a local standard network device on the DPU side. The host loads a standard virtio-net driver for the first virtual device to identify the first virtual device as a local standard network device on the host side.
4. The data processing unit according to claim 1, characterized in that, The first virtual device is configured with a first IP address, and the second virtual device is configured with a second IP address that is in the same network segment as the first IP address; The data packets received by the first virtual port module from the host are data packets sent to the first virtual device by the network application on the host after determining that the target IP address is the second IP address, through the system network protocol stack of the host.
5. The data processing unit according to claim 1, characterized in that, The first virtual port module includes multiple first virtual devices, each of which corresponds to a host; the second virtual port module includes multiple second virtual devices. The firmware processing module is specifically used to create and initialize a plurality of first virtual devices in the first virtual port module, and to create and initialize a plurality of second virtual devices that are paired with the plurality of first virtual devices in the second virtual port module. The data forwarding module is specifically used to store multiple hardware flow table rules; wherein, the multiple hardware flow table rules correspond to the pairing relationships of the multiple first virtual devices and the multiple second virtual devices, and are used to respectively instruct data packets from different first virtual devices to be forwarded to the corresponding second virtual devices.
6. The data processing unit according to any one of claims 1 to 5, characterized in that, The firmware processing module is specifically used to create and initialize multiple first virtual devices and multiple second virtual devices according to pre-configuration information. The pre-configuration information includes: the number of first virtual devices to be created, the mapping relationship between each first virtual device and its corresponding host, the pairing relationship between each first virtual device and its corresponding second virtual device, and the hardware resource allocation parameters of each virtual device.
7. A communication method, characterized in that, Applied to the data processing unit as described in any one of claims 1 to 6, the method comprises: When the data processing unit starts, a first virtual device is created and initialized in the first virtual port module through firmware, and a second virtual device is created and initialized in the second virtual port module; wherein, the first virtual device is used to be presented to the host, and the second virtual device is used for internal use by the data processing unit; The DPU operating system, running on the DPU-side processor, loads the driver for the second virtual device; After the device management process running on the DPU side processor detects that the host has loaded the driver for the first virtual device, it issues a hardware flow table rule to the data forwarding module; wherein, the hardware flow table rule instructs that data packets from the first virtual device be forwarded to the second virtual device; The first virtual port module receives data packets sent by the host and stores the data packets in the sending queue of the first virtual device. The data forwarding module obtains the data packet from the sending queue of the first virtual device and forwards the data packet to the receiving queue of the second virtual device according to the hardware flow table rules. The data packet is obtained from the receive queue of the second virtual device by the DPU-side processor.
8. A communication system, characterized in that, Includes a host computer and a data processing unit as described in any one of claims 1 to 6, wherein the host computer and the data processing unit are connected via a bus; The host is used to load a driver for the first virtual device to identify it as a local network device and send the data packet to the first virtual port module.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in claim 7.
10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the method as described in claim 7.