A method for processing bidirectional messages based on a unified user mode channel

Abstract

The application relates to a bidirectional message processing method based on a unified user state channel and belongs to the technical field of virtualized communication, which solves the problems of CPU idle rate, high memory occupation and aggravated message processing delay caused by large-scale virtual function representative port polling. The method comprises the following steps: creating a virtual interface in a user state virtual switch and associating the virtual interface with a hardware virtual function instance identifier; establishing a user state channel as a shared bidirectional message transmission path between a plurality of hardware virtual function instances and the user state virtual switch; constructing extended metadata containing the hardware virtual function instance identifier, obtaining transmission data according to the extended metadata and a to-be-processed message; receiving and analyzing the transmission data through the user state channel to obtain the to-be-processed message and the extended metadata, and then determining a forwarding rule of the to-be-processed message and executing the forwarding of the to-be-processed message. The method realizes accelerated processing of the bidirectional message without polling and significantly reduces the memory resource occupation.

Description

Technical Field

[0001] This invention relates to the field of virtualized communication technology, and in particular to a bidirectional message processing method based on a unified user-space channel. Background Technology

[0002] In cloud computing and data center virtualization networks, Single Root I / O Virtualization (SR-IOV) is a standardized PCIe hardware virtualization technology. It achieves logical partitioning and pass-through of hardware resources through an architecture of Physical Functions (PF) and Virtual Functions (VF). The PF acts as the main control unit, responsible for global network interface card (NIC) resource management and hardware configuration. The VF is a lightweight hardware instance virtualized from the PF, possessing independent PCIe resources (such as independent MAC addresses, queues, and interrupts). It can be pass-through and allocated to virtual machines, enabling them to achieve I / O performance close to that of a physical NIC.

[0003] In existing large-scale deployment schemes, each Virtual Function (VF) is mapped to a standard network device interface on the host side, called a VF representative port. The host manages these VF representative ports through software solutions such as kernel-based Open vSwitch (OVS), Traffic Control (TC), or user-space data plane-based Open vSwitch with Data Plane Development Kit (OVS-DPDK), thereby enabling monitoring, policy enforcement, and network function offloading of pass-through virtual machine traffic. Especially in hyperconverged and high-performance cloud scenarios, OVS-DPDK has become the mainstream choice for pursuing ultimate throughput and low latency. OVS-DPDK uses its Poll Mode Driver threads (PMD threads) to continuously poll the receive queues of all bound VF representative ports to receive packets in a non-interrupted manner and configure flow table rules through the VF representative port interface.

[0004] However, as the number of virtual machines hosted on a single host increases, the number of VF representative ports also surges. The existing processing mechanism described above exposes the following significant technical problems and performance defects: First, the CPU idle rate of the PMD thread is too high. The PMD thread needs to poll all bound VF representative ports. When there are too many VF representative ports, even under typical load with no traffic on the ports, the ineffective polling overhead of the PMD thread can occupy a large portion of its total CPU time, leading to an increase in the overall CPU utilization of the host machine, causing serious waste of CPU resources and significantly increasing CPU power consumption. Second, memory resources are not reclaimable. Each VF representative port needs to be pre-allocated with an independent DPDK memory pool (mempool), typically reserving several MB to tens of MB of large page memory for each port. In a system with 512 VFs, this memory overhead alone can exceed 20GB. Because large page memory is difficult to release dynamically after allocation, it severely squeezes the memory resources available for virtual machines, reducing virtual machine deployment density. Third, packet processing latency and jitter are exacerbated. The existence of a large number of VF representative ports increases the scheduling and processing burden on the PMD thread. Under peak traffic conditions, the extended time window for polling all ports leads to increased packet dwell time in the queue. This severely impacts latency-sensitive services running within virtual machines, such as financial transactions and real-time video encoding. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a bidirectional message processing method based on a unified user-space channel to solve the problems of high CPU idle rate, high memory consumption, and increased message processing latency caused by large-scale virtual function representative port polling.

[0006] This invention provides a bidirectional message processing method based on a unified user-space channel, comprising the following steps: Create virtual interfaces in the user-space virtual switch and establish their association with hardware virtual function instance identifiers; Establish a user-mode channel as a bidirectional message transmission path shared between multiple hardware virtual function instances and the user-mode virtual switch; Based on the message transmission direction, construct extended metadata containing hardware virtual function instance identifiers, and obtain the transmission data based on the extended metadata and the message to be processed; Data is transmitted and received through the user-space channel. The transmitted data is parsed to obtain the message to be processed and extended metadata. Based on the extended metadata and the association between the virtual interface and the hardware virtual function instance identifier, the forwarding rules for the message to be processed are determined, and the forwarding of the message to be processed is executed according to the forwarding rules.

[0007] Based on the above method, a virtual interface is created, and its association with the hardware virtual function instance identifier is established, including: Receive management commands, which include the name of the virtual interface to be created and the identifier of the hardware virtual function instance to be associated; Register virtual interfaces with the user-space virtual switch and assign logical port identifiers to the virtual interfaces for flow table rule references; Record the mapping relationship between virtual interface names, logical port identifiers, and hardware virtual function instance identifiers.

[0008] Based on a further improvement to the above method, extended metadata containing hardware virtual function instance identifiers is constructed according to the message transmission direction, including: In the uplink direction, if it is in a non-tunnel encapsulation scenario, the hardware virtual function instance identifier is assigned the virtual function instance identifier that sends the pending message; if it is in a tunnel encapsulation scenario, the hardware virtual function instance identifier is assigned the identifier of the physical port that receives the virtual Scalable LAN tunnel encapsulation message. In the downlink direction, if the target port is a local virtual interface, the hardware virtual function instance identifier is assigned the virtual function instance identifier that receives the message to be processed; if the target port is a tunnel logical port, the hardware virtual function instance identifier is assigned the identifier of the physical port that sends the tunnel-encapsulated message.

[0009] Further improvements to the above method, extending metadata into structured data blocks of fixed length, also include: Queue identifier, used to indicate the target transmit / receive subqueue number in the user-mode channel; The tunnel network identifier is used to indicate the virtual network index in tunnel-encapsulated scenarios and is assigned a value of zero in non-tunnel-encapsulated scenarios. The Internet Protocol address of the tunnel endpoint is used to indicate the Internet Protocol address of the peer tunnel endpoint in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. The tunnel endpoint media access control address is used to indicate the media access control address of the peer tunnel endpoint or the next-hop gateway in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. The padding alignment identifier is used to ensure that the total length of the extended metadata is the preset number of bytes.

[0010] Based on further improvements to the above method, the user-mode channel can adopt any one of the following: virtual host user protocol channel, data plane development kit ring queue, or custom shared memory channel.

[0011] Based on the further improvement of the above method, the user-space channel contains multiple parallel transceiver sub-queues, and each parallel transceiver sub-queue is bound to a different polling mode driver thread in the user-space virtual switch.

[0012] Based on the above method, further improvements are made to the uplink approach, prior to constructing the extended metadata, including: Query the cached hardware flow table information. If there is a forwarding rule in the hardware flow table information that matches the packet to be processed, then forward the packet to be processed according to the matching forwarding rule. Otherwise, construct extended metadata based on the current scenario.

[0013] Based on the further improvement of the above method, in the uplink direction of the tunnel encapsulation scenario, the outer header of the obtained virtual Scalable LAN tunnel encapsulation packet is stripped to obtain the inner packet as the packet to be processed, and the corresponding fields in the extended metadata are filled according to the outer header.

[0014] Based on further improvements to the above method, and based on extended metadata and the association between virtual interfaces and hardware virtual function instance identifiers, the forwarding rules for the packets to be processed are determined, including: In the uplink direction, the current scenario is identified based on the tunnel network identifier in the extended metadata. If it is identified as a non-tunnel encapsulation scenario, the virtual interface associated with the hardware virtual function instance identifier in the extended metadata is obtained. The logical port identifier corresponding to the virtual interface is used as the ingress port identifier of the packet to be processed, and flow table matching is performed to obtain the forwarding rules. Otherwise, the ingress port identifier is obtained based on the preset tunnel logical port identifier, and the tunnel identifier metadata is set according to the extended metadata. Flow table matching is performed to obtain the forwarding rules.

[0015] Based on further improvements to the above method, and based on extended metadata and the association between virtual interfaces and hardware virtual function instance identifiers, the forwarding rules for the packets to be processed are determined, including: In the downlink direction, the current scenario is identified based on the tunnel network identifier in the extended metadata. If it is identified as non-tunnel encapsulation forwarding, the forwarding rule is determined as follows: forward the packet to be processed to the receiving queue corresponding to the hardware virtual function instance identifier in the extended metadata. Otherwise, the determined forwarding rule is: tunnel encapsulate the packet to be processed according to the extended metadata, and send the encapsulated packet from the physical port indicated by the hardware virtual function instance identifier in the extended metadata.

[0016] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. By creating virtual interfaces and establishing a unified user-space channel shared by multiple hardware virtual function instances, the traditional polling mode-driven thread's polling of a large number of independent port queues is converged into targeted processing of a single channel. At the same time, by constructing extended metadata containing hardware virtual function instance identifiers, the user-space virtual switch can accurately restore the port context of packets and execute forwarding decisions without polling the independent queues of each virtual function instance. This fundamentally solves the problems of high CPU resource consumption, high memory usage, and increased packet processing latency caused by large-scale virtual function representative port polling in existing technologies.

[0017] 2. By defining a tunnel network identifier field in the extended metadata, in the uplink direction of tunnel encapsulation scenarios, the hardware pre-strips the VXLAN outer header, extracts tunnel information, and fills it into the extended metadata. This allows user-space virtual switches to directly perform flow table matching based on standard semantics such as ingress ports and tunnel identifiers without performing time-consuming software tunnel decapsulation operations. In the downlink direction where the destination port is a tunnel logical port, the hardware automatically identifies and performs VXLAN tunnel encapsulation operations based on the non-zero values ​​of tunnel-related fields in the extended metadata. This hardware-software collaborative tunnel processing mechanism offloads the computational burden of tunnel parsing and encapsulation to the hardware, significantly reducing the CPU usage of tunnel packet processing.

[0018] 3. Before constructing extended metadata, the hardware prioritizes querying the local flow table cache, only sending the first packet to the user-space virtual switch if a cache miss occurs. After the user-space virtual switch completes the forwarding decision, it distributes the corresponding flow table rules to the hardware, enabling subsequent packets of the same data flow to be directly forwarded or tunneled by the hardware by matching the flow table rules, without needing to be sent again. This closed-loop mechanism of "first packet decision, flow table offloading, and subsequent direct hardware forwarding" maintains the flexible policy formulation capabilities of the software control plane while increasing the continuous forwarding throughput of the data plane to near the hardware line rate level.

[0019] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a flowchart of a bidirectional message processing method based on a unified user-space channel in an embodiment of the present invention. Detailed Implementation

[0021] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0022] A specific embodiment of the present invention discloses a bidirectional message processing method based on a unified user-space channel, such as... Figure 1 As shown, it includes the following steps: S1. Create a virtual interface in the user-mode virtual switch and establish its association with the hardware virtual function instance identifier; S2. Establish a user-mode channel as a bidirectional message transmission path shared between multiple hardware virtual function instances and the user-mode virtual switch; S3. Construct extended metadata containing hardware virtual function instance identifiers according to the message transmission direction, and obtain the transmission data according to the extended metadata and the message to be processed. S4. Send and receive data through the user-space channel, parse the transmitted data to obtain the message to be processed and extended metadata; based on the extended metadata and the association between the virtual interface and the hardware virtual function instance identifier, determine the forwarding rules for the message to be processed, and execute the forwarding of the message to be processed according to the forwarding rules.

[0023] The method in this embodiment is applicable to scenarios where smart network interface cards (NICs) supporting single-root I / O virtualization technology or network devices with similar hardware virtualization capabilities work in collaboration with user-mode virtual switches. This method, through software and hardware collaboration, fundamentally solves the problems of CPU resource idleness, excessive memory consumption, and increased packet processing latency caused by polling a large number of independent ports during large-scale virtual function instance deployments, while preserving the logical abstraction of standard virtual function representative ports.

[0024] This step is executed dynamically during the system initialization or runtime phase. Its purpose is to establish a corresponding software management anchor point in the user-space virtual switch for each Virtual Function (VF) instance in the hardware layer, but this anchor point does not participate in the actual data plane packet transmission and reception.

[0025] Specifically, in this embodiment, the user-space virtual switch is illustrated using the Open Virtual Switch (OVS-DPDK) combined with the Data Plane Development Kit. The hardware virtual function instance is a lightweight hardware resource unit derived from physical functions within a smart network interface card supporting SR-IOV technology. Each hardware virtual function instance has a unique identifier (vid) within the hardware. This embodiment does not impose any limitations on the specific value range or format of the identifier.

[0026] Step S1 is further refined into sub-steps S11-S13: S11. Receive management commands. The management commands include the name of the virtual interface to be created and the identifier of the hardware virtual function instance to be associated.

[0027] First, the management platform or control layer issues a command to the user-space virtual switch to create a virtual interface via a command-line interface or application programming interface (API). This command carries the name of the virtual interface to be created (e.g., "vf0") and the hardware virtual function instance identifier (e.g., "129") to which it needs to be associated.

[0028] On the hardware side, a hardware virtual function instance is pre-created using a dedicated network interface card (NIC) management tool. For example, executing the command `snictool -p -a vf0 -f 129 -m 09:ff:89:00:00:20 -u 1600 -q8 -d 1024` via command line creates a virtual function instance named `vf0` in the smart NIC hardware. Its hardware virtual function instance identifier (vid) is 129, and it is configured with 8 transmit / receive queues with a queue depth of 1024.

[0029] Furthermore, on the user-space virtual switch side, the aforementioned hardware resources are bound to the software's virtual interfaces using OVS management commands. For example, the following command is executed via command line: `ovs-vsctl add-port br-int vf0 --setInterface vf0 type=dpdk options:dpdk-devargs="vport129"`. This command registers a virtual interface named `vf0` with type `dpdk` with OVS, and specifies the association between this virtual interface and the virtual function instance with hardware `vid=129` through the `dpdk-devargs` parameter.

[0030] S12. Register the virtual interface with the user-space virtual switch and assign a logical port identifier to the virtual interface for reference in flow table rules.

[0031] After receiving a management command, the user-mode virtual switch registers the virtual interface in its internal data structure, recognizing it as a user-mode network device.

[0032] It is worth noting that, unlike existing technologies where each virtual function representative port must be bound to an independent physical queue, the virtual interface in this embodiment does not allocate receive and send queues during registration, nor is it bound to any physical or virtual network card driver resources. This design prevents the virtual interface from directly sending and receiving packets through a polling mode driver thread (PMD thread).

[0033] At the same time, the user-space virtual switch (OVS) assigns a logical port identifier (port_id) to the virtual interface for flow table rule reference. In the OpenFlow protocol suite, this logical port identifier corresponds to the ingress port field when matching flow tables. For example, the virtual interface vf0 might be assigned a logical port identifier of 10 (denoted as port_id=10).

[0034] S13. Record the mapping relationship between the virtual interface name, logical port identifier and hardware virtual function instance identifier.

[0035] User-space virtual switches maintain an internal logical port mapping table, which establishes a mapping relationship between the virtual interface name (e.g., "vf0"), the logical port identifier assigned to it (e.g., 10), and the associated hardware virtual function instance identifier (e.g., 129). Based on this mapping table, the corresponding virtual interface can be determined according to the hardware virtual function instance identifier in the extended metadata, and the hardware virtual function instance identifier can also be looked up from the virtual interface.

[0036] Through steps S11 to S13 above, a special type of virtual interface without data plane packet transmission and reception queues is established in the user-space virtual switch. These virtual interfaces exist as logical ports in flow table rules (e.g., in_port="vf0" or output:"vf1"), maintaining full compatibility with the existing port-based configuration management system, but they do not participate in actual data transmission and reception. The actual packet transmission and reception path will be carried by the unified user-space channel established in step S2, thereby achieving decoupling between the control plane and the data plane.

[0037] Since each virtual interface no longer needs to pre-allocate an independent large page memory pool for packet storage, tens of GB of physical memory resources can be saved in a system with hundreds of virtual function instances deployed, effectively improving the virtual machine deployment density of the host machine and significantly reducing system memory overhead.

[0038] After completing the creation and association configuration of the virtual interface in step S1, a unified user-space communication channel (referred to as the UPCALL channel) is further constructed in step S2 to replace the polling of each virtual function representative port's independent queue in the existing technology, and to aggregate the message sending and receiving between all hardware virtual function instances and user-space virtual switches onto this shared path.

[0039] It should be noted that the user-mode communication channel is created during the system initialization phase.

[0040] Specifically, the hardware driver or firmware registers the user-space device resources corresponding to the channel with the host during initialization, and then OVS-DPDK binds the device to the user-space polling module through startup parameters during startup.

[0041] For example, the startup configuration is as follows: `ovs-vsctl --no-wait set Open_vSwitch . \other_config:dpdk-extra="-a '0000:05:00.1' --vdev 'vupcall0,upcall=0000:05:00.1'"`. This configuration specifies the PCIe device address (0000:05:00.1) of the smart network card and declares a UPCALL virtual device named `vupcall0` through the `vdev` parameter, binding it to the UPCALL function of the smart network card. After OVS-DPDK starts, this UPCALL device is included in the polling management scope of the PMD thread as a standard user-space port.

[0042] It's worth noting that the lifespan of the UPCALL channel is independent of the number of hardware virtual function instances. Even if only one or all virtual function instances remain on the host machine and are deleted, the channel continues to exist, eliminating the need for repeated destruction and reconstruction, thus ensuring system stability.

[0043] Depending on the deployment environment and performance requirements, the user-space channel can employ any one of the following: Virtual Host User Protocol (vhost-user) channel, Data Plane Development Kit (DPDK) ring queue, or custom shared memory channel. The vhost-user channel is suitable for scenarios involving direct interaction with the virtual machine backend, adhering to the Virtio standard and using Unix domain sockets to transmit message descriptors or message data between the client process and the host user-space process. The DPDK ring queue is suitable for high-performance communication between pure user-space applications, implemented based on a lock-free ring queue, supporting a multi-producer-multi-consumer model, with messages passed in pointer form within the queue elements. The custom shared memory channel, negotiated between the smart NIC driver or firmware and the user-space virtual switch, defines a custom shared memory region and read / write pointer protocol, suitable for specific scenarios requiring fine-grained control over cache layout and notification mechanisms.

[0044] Regardless of the form used, the user-space channel is a single message sending and receiving path shared by multiple hardware virtual function instances, rather than each hardware virtual function instance having its own independent port queue.

[0045] To further improve the parallel processing efficiency of multi-core systems, multiple parallel transmit / receive sub-queues are configured within the user-space channel. In the uplink direction, the hardware performs a hash operation based on the packet's five-tuple (source IP, destination IP, source port, destination port, protocol number) to route packets belonging to the same data stream to the same sub-queue in the user-space channel. The corresponding PMD thread on the OVS-DPDK side is dedicated to processing this sub-queue, achieving lock-free parallel processing between different sub-queues, effectively avoiding the lock contention bottleneck of a single queue.

[0046] For example, the configuration command is: `snic_upcall_queue_set(queue_nb=4, queue_size=1024)`, which configures the UPCALL channel as 4 queues, each with a depth of 1024 message units. Correspondingly, the OVS-DPDK side configures 4 PMD threads via a PMD thread mask, with each PMD thread polling one UPCALL sub-queue: `ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0xF0`, where `pmd-cpu-mask=0xF0` indicates that 4 CPU cores are used to run 4 PMD threads respectively.

[0047] The unified user-space channel established in this step transforms the traditional method of polling N independent virtual function representative port receive queues one by one by the PMD thread into a targeted polling of a single UPCALL multi-queue channel. This reduces the overhead of ineffective polling by the PMD thread from O(N) to O(1), fundamentally solving the problem of excessive CPU idle rate and power waste caused by the surge in the number of virtual function instances. Simultaneously, the design of binding multiple queues to multiple PMD threads ensures that even under high-load scenarios with hundreds of VFs generating traffic simultaneously, packet processing performance can still be linearly scaled by increasing the number of channel queues and PMD threads.

[0048] Furthermore, for different types of messages and different transmission directions, efficient bidirectional message processing through hardware and software collaboration is achieved by constructing and using extended metadata.

[0049] Depending on whether the message needs to be transmitted across the physical network via a Virtual Extensible Local Area Network (VXLAN) tunnel, this embodiment divides the processing flow of steps S3 and S4 into two scenarios: a non-tunnel encapsulation scenario and a tunnel encapsulation scenario. Within each scenario, the message transmission direction is further divided into uplink and downlink directions. The uplink direction refers to the direction from the hardware side (smart network interface card) into the user-space virtual switch (OVS-DPDK); the downlink direction refers to the direction from the user-space virtual switch back to the hardware side and finally being sent out.

[0050] This embodiment facilitates the transmission of packet identifiers and tunnel encapsulation parameters between hardware and user-space virtual switches by defining extended metadata. This extended metadata is a structured data block of fixed length, including: The Hardware Virtual Function Instance Identifier (vid) is used to carry the hardware port identifier associated with the message to be processed; in the uplink direction, this field carries the identifier of the source port of the message; in the downlink direction, this field carries the identifier of the destination port of the message. The queue identifier (queue_id) is used to indicate the target transmit / receive sub-queue number in the user-space channel to ensure that the uplink and downlink processing of the same data stream is completed on the same sub-queue, maintaining stream-level ordering and affinity; The tunnel network identifier (VNI) is used to indicate the virtual network index in tunnel-encapsulated scenarios to distinguish different virtual networks; it is assigned a value of zero in non-tunnel-encapsulated scenarios. The tunnel endpoint Internet Protocol address (vtep_ip) is used to indicate the Internet Protocol IPv4 address of the peer tunnel endpoint VTEP in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. The tunnel endpoint media access control address (vtep_mac) is used to indicate the media access control MAC address of the peer tunnel endpoint VTEP or the next-hop gateway in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. Pad alignment identifiers are reserved fields used to ensure that the total length of extended metadata is the preset number of bytes.

[0051] For example, the total length of the extended metadata is 20 bytes, of which vid, queue_id and pad are 2 bytes, vni and vtep_ip are 4 bytes, and vtep_mac is 6 bytes.

[0052] The structure definition of the extended metadata described above applies uniformly to both uplink and downlink directions, as well as to both tunnel and non-tunnel scenarios. The bidirectional processing flow for both scenarios is described in detail below, with the construction entity and field assignment rules for the extended metadata in each scenario explained in the corresponding steps.

[0053] (a) Non-tunnel encapsulation scenario Non-tunnel encapsulation scenarios correspond to local communication between virtual machines within the same host machine, or direct communication within the same Layer 2 network domain without tunnel encapsulation. In this scenario, the message is always in the original Ethernet frame format, and the tunnel network identifier (VNI) field in the extended metadata is set to zero during construction. The receiver uses this to identify the current scenario and select the corresponding processing branch.

[0054] I. Upward direction The uplink direction processes raw Ethernet packets sent from the local virtual machine via a hardware virtual function instance. Its processing flow is divided into two stages: step S3, which corresponds to the hardware-side data construction and transmission phase; and step S4, which corresponds to the user-space virtual switch-side reception, parsing, and forwarding rule determination phase, followed by the forwarding execution phase.

[0055] 1. Hardware-side construction and data transmission stage.

[0056] It should be noted that the smart network interface card (NIC) hardware receives raw packets from a hardware virtual function instance, i.e., packets awaiting processing; before constructing extended metadata, the following steps are also included: Query the hardware flow table information in the internal hardware cache. If there is a forwarding rule in the hardware flow table information that matches the message to be processed, then forward the message to be processed according to the matching forwarding rule. Otherwise, construct extended metadata based on the current scenario.

[0057] Specifically, the hardware extracts the five-tuple (source IP address, destination IP address, source port number, destination port number, and protocol number) from the packet to be processed and searches for it in the hardware flow table cache using this five-tuple as the key. If a forwarding rule matching the five-tuple exists in the hardware flow table cache, it means that the data flow to which the packet belongs has already been decided by the user-space virtual switch, and the corresponding flow table rule has been sent to the hardware through the application programming interface. At this point, the hardware directly performs forwarding according to the action indicated by the matched rule (for example, directly copying the packet to the receive queue of the target hardware virtual function instance via DMA, or sending it from the physical port). The entire processing flow ends without the involvement of the user-space virtual switch.

[0058] If no matching rule is found in the hardware flow table cache (i.e., a flow table miss), it indicates that the packet may be the first packet of the data flow or that the flow table rule has not yet been unloaded. The hardware then begins to build extended metadata, including: The hardware virtual function instance identifier is assigned the identifier of the virtual function instance that sent the message to be processed; for example, if the message comes from a hardware virtual function instance with identifier 129, this field is filled with 129. This identifier will be used by the user-space virtual switch to restore the ingress port information of the message; The queue identifier is assigned by performing a hash operation on the five-tuple of the message to be processed and mapping the hash result to a specific receive sub-queue number of the user-space channel; The tunnel network identifier, tunnel endpoint Internet Protocol address, tunnel endpoint Media Access Control address, and padding alignment identifier are all assigned the value of zero.

[0059] It should be noted that during the above assignment process, the hardware virtual function instance identifier and queue identifier are obtained directly from the VF hardware context by the hardware or generated in real time by the hardware hash engine, without consuming host CPU resources.

[0060] After constructing the extended metadata, it is combined with the message to be processed into transmission data. The method of combining the transmission data is determined by the implementation of the user-space channel.

[0061] Specifically, when the user-space channel is a shared memory channel based on data copying, the hardware directly appends 20 bytes of extended metadata as a header to the front of the message to be processed, forming a physically contiguous data block. The beginning of this data block is the extended metadata, followed by the complete message to be processed. The hardware then writes this contiguous data block as a whole into the corresponding receive subqueue of the user-space channel.

[0062] When the user-space channel is a descriptor-based DPDK circular queue, the hardware constructs a transport descriptor (e.g., the DPDK's `rte_mbuf` structure), fills the dynamic extension field (dynfield) of this descriptor with extended metadata, and records a pointer to the storage address of the packet to be processed in the packet data pointer field of the descriptor. Subsequently, the hardware writes this descriptor to the corresponding receive sub-queue of the user-space channel. In this mode, the extended metadata and the packet to be processed can be stored separately in physical memory, establishing a logical association only through the descriptor, avoiding memory copying of packet data, and further improving processing performance in high-throughput scenarios.

[0063] 2. The receiving, parsing, and forwarding rule determination and execution phase on the user-mode virtual switch side.

[0064] In the user-space virtual switch (OVS-DPDK), a PMD thread is bound to the corresponding user-space channel receive sub-queue to retrieve transmission data from the sub-queue in a polling manner. Depending on the combination of the transmission data, the PMD thread employs a corresponding parsing method: it reads consecutive data blocks from the receive buffer, extracts the first 20 bytes as extended metadata according to a pre-agreed offset, and the remaining portion is the message to be processed; or, it directly reads the extended metadata from the dynamic extension field area of ​​the transport descriptor and accesses the message to be processed through the message data pointer in the descriptor.

[0065] Furthermore, the current scenario is identified based on the tunnel network identifier (VNI) in the extended metadata. If the value of this field is zero, it is identified as being in a non-tunnel encapsulation scenario, and the following operations are performed: The user-space virtual switch uses the hardware virtual function instance identifier (vid, e.g., 129) in the extended metadata to look up the logical port mapping table maintained in step S13. This mapping table records the mapping relationship between the virtual interface name, the logical port identifier (port_id), and the hardware virtual function instance identifier (vid). Through the query, the user-space virtual switch obtains the virtual interface (e.g., "vf0") associated with the hardware virtual function instance identifier 129, and further obtains the logical port identifier (e.g., port_id=10) corresponding to that virtual interface.

[0066] The user-space virtual switch uses the logical port identifier obtained from the above query as the ingress port identifier (in_port) of the current packet to be processed. Based on this, the user-space virtual switch sends the packet to be processed into the OpenFlow flow table pipeline, performs multi-level flow table matching to obtain a forwarding rule. This rule specifies the output port of the packet to be processed (e.g., output: "vf1") and the additional actions to be performed (such as modifying the MAC address, setting the VLAN tag, etc.). The packet to be processed is then forwarded according to the forwarding rule.

[0067] In this process, the source port identifier is carried in the extended metadata by the hardware, and the ingress port information is restored by the user-space virtual switch through the mapping table. This allows the user-space virtual switch to obtain the ingress port context of the packet completely without polling the independent receive queue of each hardware virtual function instance. Thus, forwarding decisions are made under the standard OpenFlow flow table matching framework, which maintains compatibility with the existing SDN system and eliminates the overhead of large-scale port polling.

[0068] II. Downward Direction The downlink process handles scenarios where the user-space virtual switch sends packets to a specific target port. The process is divided into two stages: step S3, which involves the user-space virtual switch constructing the transmission data, and step S4, which involves the hardware side receiving, parsing, determining forwarding rules, and executing the forwarding process.

[0069] It should be noted that the source of the message to be processed can be various, such as the uplink first packet injection, forwarded messages from physical ports or other virtual ports, and control messages spontaneously generated by user-space virtual switches. This embodiment does not limit this.

[0070] 1. Construct and transmit data on the user-mode virtual switch side.

[0071] Once the user-space virtual switch determines a packet to be processed and its destination port through flow table matching or other methods, it first sends the complete flow table rules corresponding to this decision to the internal flow table cache of the smart network interface card (NIC) hardware via the application programming interface (API). Subsequently, when subsequent packets belonging to the same data flow arrive at the hardware, they will directly match the hardware flow table rules and be forwarded or encapsulated by the hardware at the data plane, without needing to be sent back to the user-space virtual switch for processing.

[0072] It should be noted that the target port includes two cases: the target port is a local virtual interface and the target port is a tunnel logical port.

[0073] When the target port is a local virtual interface (e.g., output: "vf1"), it indicates that the packet to be processed needs to be directly delivered to a hardware virtual function instance within the host machine. The user-space virtual switch uses the virtual interface "vf1" indicated by the flow table output port as an index to look up the logical port mapping table maintained in step S13. Through the query, the hardware virtual function instance identifier (e.g., 130) associated with the virtual interface "vf1" is obtained, and this identifier is the virtual function instance identifier for receiving the packet to be processed.

[0074] At this point, the user-space virtual switch constructs extended metadata, including: The hardware virtual function instance identifier is assigned the value of the virtual function instance identifier that receives the message to be processed; The queue identifier is assigned the original queue identifier associated with the message to be processed, or it is calculated based on the hash of the five-tuple of the message to be processed; The tunnel network identifier, tunnel endpoint Internet Protocol address, tunnel endpoint Media Access Control address, and padding alignment identifier are all assigned the value of zero.

[0075] When the target port is a tunnel logical port (e.g., output: "vxlan0"), it indicates that the packet to be processed needs to be encapsulated in a VXLAN tunnel before being sent to the remote VTEP via the physical port. The user-space virtual switch determines the tunnel encapsulation parameters of the packet to be processed based on the flow table matching results. At this time, the packet to be processed is the inner packet obtained by stripping the outer header of the Virtual Extensible LAN tunnel encapsulation packet.

[0076] Specifically, the flow table rule has already specified the tunnel network identifier (tun_id) and the target tunnel endpoint Internet Protocol address (tun_dst) through the set_field action. The user-space virtual switch further obtains the MAC address (tnl_neigh) of the target tunnel endpoint or next-hop gateway by querying the neighbor table.

[0077] Since the encapsulated message needs to be sent from the physical port, the user-space virtual switch queries the logical port mapping table to obtain the hardware virtual function instance identifier associated with the physical port (e.g., vid=100 for the physical port).

[0078] The user-space virtual switch constructs extended metadata based on the above parameters, including: The hardware virtual function instance identifier is assigned the hardware virtual function instance identifier (100) associated with the physical port. The queue identifier is assigned the original queue identifier associated with the message to be processed, or is calculated based on the hash of the five-tuple of the message to be processed; The tunnel network identifier, tunnel endpoint Internet Protocol address field, and tunnel endpoint Media Access Control address field are assigned the values ​​tun_id, tun_dst, and tnl_neigh as specified by the flow table rule, respectively. The padding alignment identifier is assigned a value of zero.

[0079] After constructing the extended metadata, the extended metadata is combined with the message to be processed into transmission data and written into the send sub-queue of the user-space channel.

[0080] 2. Hardware-side reception, parsing, and determination of forwarding rules execution forwarding phase.

[0081] The smart network interface card (NIC) hardware receives transmitted data from the user-space channel and parses it to obtain extended metadata and messages to be processed.

[0082] If the value of the tunnel network identifier (vni) field in the extended metadata is zero, it is identified as non-tunnel encapsulation forwarding. The determined forwarding rule is: forward the packet to be processed to the receive queue corresponding to the hardware virtual function instance identifier in the extended metadata; the hardware executes this forwarding rule, and the virtual machine then receives the standard Ethernet frame to complete the processing flow.

[0083] If the value of the tunnel network identifier (vni) field in the extended metadata is non-zero, it is identified as tunnel encapsulation forwarding. The determined forwarding rule is: tunnel encapsulate the packet to be processed according to the extended metadata, and send the encapsulated packet from the physical port indicated by the hardware virtual function instance identifier in the extended metadata.

[0084] Specifically, the tunnel endpoint media access control address field (vtep_mac) in the extended metadata serves as the outer destination MAC, the tunnel endpoint internet protocol address field (vtep_ip) serves as the outer destination IP, and the tunnel network identifier field (vni) serves as the VXLAN VNI. These are combined with the hardware-preconfigured local physical port MAC address as the outer source MAC and the local VTEP IP address as the outer source IP. The UDP destination port is fixed at 4789 (the standard VXLAN port), and the UDP source port is automatically generated by the hardware based on the inner packet's five-tuple using RSS hashing. A complete VXLAN tunnel encapsulation is performed on the packet to be processed. After encapsulation, the encapsulated VXLAN packet is sent from the physical port indicated by the hardware virtual function instance identifier.

[0085] (II) Tunnel Encapsulation Scenarios The tunnel encapsulation scenario corresponds to the processing of packets arriving at the local host from a remote host via a VXLAN tunnel over a physical network. In this scenario, the uplink packet is a VXLAN tunnel encapsulated packet received from the physical port; the downlink packet is delivered to the local target hardware virtual function instance.

[0086] I. Upward direction The uplink direction processes VXLAN tunnel encapsulated packets received from the physical port of the smart network interface card. Its processing flow is divided into two stages: step S3, which corresponds to the hardware-side data construction and transmission phase; and step S4, which corresponds to the user-space virtual switch-side reception, parsing, and forwarding rule determination and execution phase.

[0087] 1. Hardware-side construction and data transmission stage.

[0088] After receiving a VXLAN tunnel encapsulation packet from a physical port (e.g., vid=100), the smart network interface card (NIC) hardware first extracts the outer header information of the packet. The outer header of this VXLAN packet includes: an outer Ethernet header, an outer IP header, a UDP header, and a VXLAN header. The hardware identifies the UDP destination port as 4789 (a standard VXLAN port), thus determining that the packet is a VXLAN tunnel encapsulation packet.

[0089] Similar to the uplink processing in non-tunnel encapsulation scenarios, before constructing extended metadata, the hardware queries the hardware flow table information cached internally. If a matching rule exists in the hardware flow table cache for the VXLAN packet (e.g., an established inner packet forwarding rule), the hardware directly performs decapsulation and subsequent forwarding actions, and the process ends without sending it to the user-space virtual switch. If no matching rule is found in the hardware flow table cache (i.e., flow table miss), the hardware strips the outer header of the obtained VXLAN tunnel encapsulation packet to obtain the inner packet as the packet to be processed, and fills in the corresponding fields in the extended metadata based on the outer header, including: Extract the 24-bit VXLAN Network Identifier (VNI) from the VXLAN header and fill it into the Tunnel Network Identifier field of the extended metadata; extract the source IP address (i.e., the IP address of the peer VTEP) from the outer IP header and fill it into the Tunnel Endpoint Internet Protocol Address field of the extended metadata; extract the source MAC address (i.e., the MAC address of the peer VTEP or the last-hop gateway) from the outer Ethernet header and fill it into the Tunnel Endpoint Media Access Control Address field of the extended metadata.

[0090] The hardware virtual function instance identifier in the extended metadata is assigned the identifier of the physical port receiving VXLAN packets within the hardware, to record the physical entry point of the packet into the host machine; the queue identifier is assigned by performing a hash operation on the five-tuple of the packet to be processed and mapping the hash result to a certain receive sub-queue number of the user-space channel, to ensure that packets of the same data stream are processed by the same PMD thread; the padding alignment identifier is assigned the value of zero.

[0091] After constructing the extended metadata, it is combined with the message to be processed into transmission data. The combination method of the transmission data is consistent with that described in the non-tunnel encapsulation scenario above. The hardware writes the transmission data into the corresponding receive sub-queue of the user-space channel.

[0092] Compared to the existing technology where user-space virtual switch software parses the VXLAN packet header layer by layer, this embodiment completely offloads the computational burden of tunnel parsing to hardware, significantly reducing the CPU overhead of processing the first packet of tunnel packets.

[0093] 2. The receiving, parsing, and forwarding rule determination and execution phase on the user-mode virtual switch side.

[0094] The PMD thread is bound to the corresponding user-mode channel receive sub-queue in the user-mode virtual switch. It retrieves the transmission data from the sub-queue in a polling manner and parses it to obtain extended metadata and messages to be processed (i.e., inner messages).

[0095] Furthermore, the user-space virtual switch identifies the current scenario based on the tunnel network identifier (VNI) in the extended metadata. If the value of this field is non-zero, the user-space virtual switch determines that it is currently in a tunnel encapsulation scenario and performs the following operations: User-space virtual switches do not query the virtual interface associated with the hardware virtual function instance identifier. This is because, in tunnel encapsulation scenarios, packets are not sent from the local virtual function instance, but arrive from a remote location via a tunnel. Their ingress port is the tunnel logical port, not the representative port of a local VF.

[0096] The user-space virtual switch obtains the ingress port identifier in_port based on the preset tunnel logical port identifier (i.e., the OpenFlow port number corresponding to vxlan0), and sets the tunnel identifier metadata based on the extended metadata, including: setting the tunnel network identifier tun_id based on the tunnel network identifier in the extended metadata, setting the tunnel source address tun_src based on the tunnel endpoint Internet Protocol address vtep_ip in the extended metadata, and recording the IP address of the peer VTEP.

[0097] After configuration, the user-space virtual switch uses the determined ingress port identifier as `in_port` and `tun_id` and `tun_src` as additional matching conditions to perform OpenFlow flow table matching on the packets to be processed. The flow table matching conditions include the ingress port (vxlan0), tunnel identifier (tun_id=100), source / destination MAC address of the inner packet, IP 5-tuple, and other fields. For example, the flow table rule is: `priority=300,in_port=vxlan0,tun_id=100,dl_dst=09:ff:89:00:00:22,actions=output:vf0`. This rule means that packets received from the vxlan0 tunnel interface, belonging to the VNI 100 virtual network, with a destination MAC address of 09:ff:89:00:00:22, will be forwarded to the local virtual interface vf0 after decapsulation.

[0098] After flow table matching, the user-space virtual switch generates a forwarding rule that specifies the output port of the packet to be processed (e.g., output: "vf0"). The packet is then delivered to the corresponding local hardware virtual function instance according to the forwarding rule.

[0099] In this process, the hardware pre-processes the stripping of the VXLAN outer header and extraction of key fields, allowing the user-space virtual switch to directly perform flow table matching using standard OpenFlow semantics (in_port=vxlan0, tun_id=VNI) without performing time-consuming tunnel decapsulation operations. This not only simplifies the software processing logic but also ensures unified management and policy enforcement of tunnel packets and local packets at the flow table level.

[0100] II. Downward Direction The downlink process handles the independent flow of a user-space virtual switch sending a packet to be processed to a local hardware virtual function instance. This process is divided into two stages: step S3, which involves the user-space virtual switch constructing the transmission data, and step S4, which involves the hardware side receiving, parsing, determining forwarding rules, and executing the forwarding process.

[0101] The source of the pending messages can be the aforementioned uplink VXLAN messages that are matched with the flow table and then sent to the local VF as a callback message, or it can be a control message (such as an ARP reply) generated spontaneously by the user-space virtual switch, or a message forwarded from other ports (such as patch ports), etc. This solution does not limit this.

[0102] 1. Construct and transmit data on the user-mode virtual switch side.

[0103] Once the user-space virtual switch determines a packet to be sent and its destination port through flow table matching or other methods, it first sends the corresponding flow table rules to the internal flow table cache of the smart network interface card hardware through the application programming interface.

[0104] In this scenario, the target port is simply a local virtual interface, and its processing logic is completely consistent with the case where the target port is a local virtual interface in the downlink direction of the aforementioned non-tunnel encapsulation scenario: the user-space virtual switch queries the logical port mapping table in reverse based on the target virtual interface to obtain the target hardware virtual function instance identifier (vid), and constructs extended metadata accordingly, in which the tunnel network identifier (vni), tunnel endpoint Internet Protocol address, tunnel endpoint Media Access Control address, and padding alignment identifier are all assigned a value of zero. Subsequently, the extended metadata is combined with the packet to be processed into transmission data and written into the send sub-queue of the user-space channel.

[0105] 2. Hardware-side reception, parsing, and determination of forwarding rules execution forwarding phase.

[0106] The smart network interface card (NIC) hardware receives transmitted data from the user-space channel and parses it to obtain extended metadata and messages to be processed.

[0107] The value of the tunnel network identifier (vni) field in the extended metadata is zero, which indicates non-tunnel encapsulation forwarding. The determined forwarding rule is: forward the packet to be processed to the receive queue corresponding to the hardware virtual function instance identifier in the extended metadata; the hardware executes this forwarding rule, and the virtual machine then receives standard Ethernet frames to complete the processing flow.

[0108] Compared with existing technologies, this embodiment provides a bidirectional packet processing method based on a unified user-space channel. By creating a virtual interface and establishing a unified user-space channel shared by multiple hardware virtual function instances, it converges the polling mode-driven thread's polling of a large number of independent port queues in traditional solutions into targeted processing of a single channel. At the same time, by constructing extended metadata containing hardware virtual function instance identifiers, the user-space virtual switch can accurately restore the port context of the packet and execute forwarding decisions without polling the independent queues of each virtual function instance. This fundamentally solves the problems of high CPU resource consumption, high memory usage, and increased packet processing latency caused by large-scale virtual function representative port polling in existing technologies. By defining a tunnel network identifier field in the extended metadata, in the uplink direction of tunnel encapsulation scenarios, the hardware pre-strips the VXLAN outer header, extracts tunnel information, and fills it into the extended metadata. This allows user-space virtual switches to directly perform flow table matching based on standard semantics such as ingress ports and tunnel identifiers without performing time-consuming software tunnel decapsulation operations. In the downlink direction where the destination port is a tunnel logical port, the hardware automatically identifies and performs VXLAN tunnel encapsulation operations based on the non-zero values ​​of tunnel-related fields in the extended metadata. This hardware-software collaborative tunnel processing mechanism offloads the computational burden of tunnel parsing and encapsulation to the hardware, significantly reducing the CPU usage of tunnel packet processing. Before constructing extended metadata, the hardware prioritizes querying the local flow table cache, only sending the first packet to the user-space virtual switch if a cache miss occurs. After the user-space virtual switch completes the forwarding decision, it distributes the corresponding flow table rules to the hardware, enabling subsequent packets of the same data flow to be directly forwarded or tunneled by the hardware by matching the flow table rules, without needing to be sent again. This closed-loop mechanism of "first packet decision, flow table offloading, and subsequent direct hardware forwarding" maintains the flexible policy-making capabilities of the software control plane while increasing the continuous forwarding throughput of the data plane to near the hardware line-rate level.

[0109] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0110] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A bidirectional message processing method based on a unified user-space channel, characterized in that, Includes the following steps: Create virtual interfaces in the user-space virtual switch and establish their association with hardware virtual function instance identifiers; Establish a user-mode channel as a bidirectional message transmission path shared between multiple hardware virtual function instances and the user-mode virtual switch; An extended metadata containing a hardware virtual function instance identifier is constructed based on the message transmission direction, and the transmission data is obtained based on the extended metadata and the message to be processed. The user-space channel is used to send and receive the transmission data, and the transmission data is parsed to obtain the message to be processed and extended metadata. Based on extended metadata and the association between virtual interfaces and hardware virtual function instance identifiers, the forwarding rules for the packets to be processed are determined, and the forwarding of the packets to be processed is executed according to the forwarding rules.

2. The bidirectional message processing method based on a unified user-space channel according to claim 1, characterized in that, The creation of the virtual interface and the establishment of its association with the hardware virtual function instance identifier include: Receive management commands, which include the name of the virtual interface to be created and the identifier of the hardware virtual function instance to be associated; Register the virtual interface with the user-space virtual switch and assign a logical port identifier to the virtual interface for flow table rule reference; Record the mapping relationship between the virtual interface name, the logical port identifier, and the hardware virtual function instance identifier.

3. The bidirectional message processing method based on a unified user-space channel according to claim 1, characterized in that, The construction of extended metadata containing hardware virtual function instance identifiers based on the message transmission direction includes: In the uplink direction, if it is in a non-tunnel encapsulation scenario, the hardware virtual function instance identifier is assigned the virtual function instance identifier that sends the message to be processed; if it is in a tunnel encapsulation scenario, the hardware virtual function instance identifier is assigned the identifier of the physical port that receives the virtual Scalable LAN tunnel encapsulation message. In the downlink direction, if the target port is a local virtual interface, the hardware virtual function instance identifier is assigned the value of the virtual function instance identifier for receiving the message to be processed; if the target port is a tunnel logical port, the hardware virtual function instance identifier is assigned the value of the identifier of the physical port for sending the tunnel-encapsulated message.

4. The bidirectional message processing method based on a unified user-space channel according to claim 1, characterized in that, The extended metadata is a structured data block with a fixed length, and also includes: Queue identifier, used to indicate the target transceiver sub-queue number in the user-mode channel; The tunnel network identifier is used to indicate the virtual network index in tunnel-encapsulated scenarios and is assigned a value of zero in non-tunnel-encapsulated scenarios. The Internet Protocol address of the tunnel endpoint is used to indicate the Internet Protocol address of the peer tunnel endpoint in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. The tunnel endpoint media access control address is used to indicate the media access control address of the peer tunnel endpoint or the next-hop gateway in tunnel encapsulation scenarios, and is assigned a value of zero in non-tunnel encapsulation scenarios. A padding alignment identifier is used to ensure that the total length of the extended metadata is a preset number of bytes.

5. The bidirectional message processing method based on a unified user-space channel according to claim 1, characterized in that, The user-mode channel can be any one of the following: virtual host user protocol channel, data plane development kit ring queue, or custom shared memory channel.

6. The bidirectional message processing method based on a unified user-space channel according to claim 1, characterized in that, The user-mode channel includes multiple parallel transmit / receive sub-queues, and each of the parallel transmit / receive sub-queues is bound to a different polling mode driver thread in the user-mode virtual switch.

7. The bidirectional message processing method based on a unified user-space channel according to claim 3, characterized in that, In the uplink direction, before constructing the extended metadata, the following is also included: Query the cached hardware flow table information. If there is a forwarding rule in the hardware flow table information that matches the packet to be processed, then forward the packet to be processed according to the matching forwarding rule. Otherwise, construct extended metadata based on the current scenario.

8. The bidirectional message processing method based on a unified user-space channel according to claim 4, characterized in that, In the uplink direction of the tunnel encapsulation scenario, the inner packet is obtained as the packet to be processed by stripping the outer header of the obtained virtual Scalable LAN tunnel encapsulation packet, and the corresponding fields in the extended metadata are filled in according to the outer header.

9. The bidirectional message processing method based on a unified user-space channel according to claim 1 or 3, characterized in that, The method for determining the forwarding rules for packets to be processed based on extended metadata and the association between virtual interfaces and hardware virtual function instance identifiers includes: In the uplink direction, the current scenario is identified based on the tunnel network identifier in the extended metadata. If it is identified as a non-tunnel encapsulation scenario, the virtual interface associated with the hardware virtual function instance identifier in the extended metadata is obtained, and the logical port identifier corresponding to the virtual interface is used as the ingress port identifier of the packet to be processed. Flow table matching is performed to obtain forwarding rules. Otherwise, the ingress port identifier is obtained based on the preset tunnel logical port identifier, and the tunnel identifier metadata is set according to the extended metadata. Flow table matching is performed to obtain forwarding rules.

10. The bidirectional message processing method based on a unified user-space channel according to claim 1 or 3, characterized in that, The method for determining the forwarding rules for packets to be processed based on extended metadata and the association between virtual interfaces and hardware virtual function instance identifiers includes: In the downlink direction, the current scenario is identified based on the tunnel network identifier in the extended metadata. If it is identified as non-tunnel encapsulation forwarding, the forwarding rule is determined as follows: forward the packet to be processed to the receiving queue corresponding to the hardware virtual function instance identifier in the extended metadata. Otherwise, the determined forwarding rule is: to tunnel encapsulate the packet to be processed according to the extended metadata, and send the encapsulated packet from the physical port indicated by the hardware virtual function instance identifier in the extended metadata.

Images