Communication method and system supporting multiple protocol stacks

Abstract

The embodiment of the application provides a communication method and system supporting a plurality of protocol stacks, the method comprising: a network port controller can deliver a received message to a corresponding protocol stack for processing according to the type of the message. Management plane messages can be delivered to an Ethernet protocol stack for processing, and data plane messages can be delivered to a data plane protocol stack for processing. By supporting an Ethernet protocol stack and a data plane protocol stack on the same network port, the compatibility can be ensured, the requirement of the data plane message for delay can be met, and high-performance transmission of the data plane message is realized.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of communication, and in particular, to a communication method and system supporting multiple protocol stacks. BACKGROUND

[0002] In the field of autonomous driving, an autonomous driving system usually includes, but is not limited to, multiple sensors, a communication bus for interconnection, a core processor and the like hardware, and an autonomous driving software system running on the core processor. During the operation of the autonomous driving system, various types of sensor data need to be input to the autonomous driving software system through the corresponding communication bus. For example, based on the requirement of communication performance, data can be divided into two categories: data plane communication and management plane communication.

[0003] Data plane communication: data generated by various sensors outside the SoC (System on Chip), such as Lidar (Laser Radar) and Radar (Radar, which can also be referred to as millimeter wave radar). This type of data can be directly used in various algorithms in the autonomous driving software system. Since the data volume of this type of data is large, the bandwidth requirement is usually high (for example, a bandwidth of 2 Gbps or more is required).

[0004] Management plane communication: various types of device configuration, device state monitoring, image compression transmission and the like management plane services also need to be run on the SoC. This type of service has relatively low requirements on communication performance. However, this type of communication needs to be compatible with the user programming interface of POSIX (Portable Operating System Interface) and the network device management function.

[0005] For the communication data of the data plane, the autonomous driving system has very high real-time requirements. Therefore, if the external sensor data cannot be transmitted to the autonomous driving algorithm within a certain time, it will directly threaten the safety and reliability of autonomous driving. If an Ethernet protocol stack (also referred to as a standard protocol stack) and an Ethernet network interface driver are used to receive the communication data of the data plane, each data packet needs to pass through a thick Ethernet protocol stack, and also needs to pay the cost of data copying and complex message processing of the Ethernet protocol stack. Therefore, the Ethernet protocol stack cannot meet the hard index requirement of the deterministic transmission delay of the communication data of the data plane of the autonomous driving system. SUMMARY

[0006] In order to solve the above technical problems, embodiments of the present application provide a communication method and system supporting multiple protocol stacks. In the method, the network interface controller can hand over different types of messages to the corresponding protocol stack for processing according to the type of the message. In this way, the compatibility of the management plane message is guaranteed, and the fast processing of the data plane message is realized.

[0007] In a first aspect, an embodiment of the present application provides a communication system supporting multiple protocol stacks. The communication system comprises a network interface controller, an Ethernet protocol stack, and a data plane protocol stack. The network interface controller is configured to determine that a first packet received is a management plane packet, and output the first packet to the Ethernet protocol stack. The Ethernet protocol stack is configured to output the first packet to a first application in response to the first packet received. The network interface controller is further configured to determine that a second packet received is a data plane packet, and save the second packet in a first memory. The data plane protocol stack is configured to parse the second packet in the first memory to obtain location information of a specified field of the second packet in the first memory, and output the location information of the specified field to a second application, so that the second application acquires the specified field from the first memory according to the location information of the specified field. In this way, the communication system in the embodiment of the present application can deliver different types of packets to corresponding protocol stacks for processing according to the types of the packets. For example, the management plane packets are delivered to the standard Ethernet protocol stack for transceiving processing. For example, the data plane packets are delivered to the data plane protocol stack for transceiving processing. Thus, the requirements of different packets for transmission can be met. For example, the management plane packets are not sensitive to time delay, but need to meet the compatibility. Therefore, the management plane packets are processed by the Ethernet protocol stack, and the compatibility requirements of the Ethernet packets can be met. For example, the data plane packets are sensitive to time delay, so that the data plane packets can be quickly delivered to the application by processing the data packets by the data plane protocol stack. The requirements of the data plane packets for time delay can be met by the simplified processing of the data plane packets by the data plane protocol stack. In addition, the communication system in the embodiment of the present application can support multiple protocol stacks by using one network interface controller, so that the utilization of network interface resources is improved. By using one network interface to support concurrent operation of two communication stacks, the compatibility can be ensured, and the high performance requirements of the system can be met.

[0008] For example, the processing of the management packets by the Ethernet protocol stack needs at least two times of data copying.

[0009] For example, the Ethernet protocol stack can be compatible with the user programming interface and the network device management function of POSIX.

[0010] For example, the data plane protocol stack can be the UIO protocol stack in the following embodiments.

[0011] For example, the specified field can be a data field.

[0012] For example, the location information can comprise start address and length information of the data field.

[0013] For example, the communication system can comprise multiple data plane protocol stacks, and each data plane protocol stack corresponds to one or more applications.

[0014] For example, the first message and the second message can come from the same external device, such as a radar, or from different external devices, which is not limited in the application.

[0015] In a possible implementation, the network interface controller includes a correspondence between the characteristic field and the message type, and the network interface controller is specifically configured to: determine, based on the correspondence between the characteristic field and the message type, that the message type corresponding to the characteristic field of the first message is the management plane message. In this way, the network interface controller in the embodiment of the application can perform shunt processing on the message according to the type of the message, that is, the management plane message is handed over to the Ethernet protocol stack for processing, and the data plane message is handed over to the data plane protocol stack for processing.

[0016] For example, the network interface controller can include a hardware flow table, which can record the correspondence between the characteristic field and the message type.

[0017] In a possible implementation, the network interface controller includes a correspondence between the characteristic field and the message type, and the network interface controller is specifically configured to: determine, based on the correspondence between the characteristic field and the message type, that the message type corresponding to the characteristic field of the second message is the data plane message. In this way, the network interface controller in the embodiment of the application can perform shunt processing on the message according to the type of the message, that is, the management plane message is handed over to the Ethernet protocol stack for processing, and the data plane message is handed over to the data plane protocol stack for processing.

[0018] In a possible implementation, the network interface controller includes a first hardware queue corresponding to the management plane protocol stack, and the network interface controller is specifically configured to, after determining that the type of the first message is the management plane message, place the received first message in the first hardware queue. In this way, the network interface controller in the embodiment of the application can place the message in the corresponding queue through the queue corresponding to different protocol stacks. Thus, multiplexing of the same network interface is achieved, that is, the same network interface can support the transmission and reception of messages of multiple protocol stacks. For example, the network interface controller can place the management plane message in the first hardware queue, and hand over the message in the first hardware queue to the Ethernet protocol stack bound to the first hardware queue for processing.

[0019] In a possible implementation, the network interface controller is specifically configured to output the first message in the first hardware queue to the Ethernet protocol stack. In this way, the network interface controller can hand over the message in the first hardware queue to the Ethernet protocol stack bound to the first hardware queue for processing.

[0020] In a possible implementation, the network interface controller includes a second hardware queue corresponding to the data plane protocol stack, and the network interface controller is specifically configured to place the received second packet in the second hardware queue after determining that the type of the second packet is a data plane packet. In this way, the network interface controller in the embodiment of the present application can place the packet in the corresponding queue through the queue corresponding to the different protocol stacks. Thus, multiplexing of the same network interface is realized, that is, the same network interface can support the transmission and reception of packets of multiple protocol stacks. For example, the network interface controller can place the data plane packet in the second hardware queue, and hand over the packet in the second hardware queue to the data plane protocol stack bound to the second hardware queue for processing.

[0021] For example, the network interface controller can include a plurality of hardware queues corresponding to a plurality of data plane protocol stacks.

[0022] In a possible implementation, the network interface controller is specifically configured to output at least one packet in the second hardware queue to the first memory, where the at least one packet includes the second packet. In this way, the network interface controller can also perform batch transmission and reception of packets. That is, the network interface controller can hand over multiple packets in the queue to the data plane protocol stack for processing at a time, thereby reducing the overhead of each packet traversing the protocol stack. For example, the network interface controller in the embodiment of the present application can also implement a data zero-copy function, that is, outputting the at least one packet to the memory can enable the application to directly read data from the memory, so as to avoid the overhead required by data copying.

[0023] In a possible implementation, the network interface controller is further configured to write the position information of each packet in the at least one packet in the first memory into the second memory, and report an interrupt to the data plane protocol stack. The data plane protocol stack is specifically configured to acquire the position information of each packet in the at least one packet from the second memory in response to the received interrupt. Based on the acquired position information of each packet in the at least one packet, the at least one packet is read in the first memory, and the position information of the specified field of each packet in the at least one packet is determined. In this way, the interrupt pass-through mechanism in the embodiment of the present application can directly transmit the interrupt to the user-mode thread at a time, so as to avoid the performance loss caused by the uncertainty of interrupt scheduling delay.

[0024] For example, the data plane protocol stack can process one packet at a time, that is, the position information of the specified field of the packet is sent to the application one by one, and the application reads from the memory once for each received specified field information.

[0025] For example, the data plane protocol stack can process multiple packets at a time, that is, the position information of the specified field of each packet of the multiple packets is sent to the application at a time, and the application can simultaneously read the specified fields of the multiple packets in the memory, thereby further reducing the system overhead.

[0026] In a second aspect, an embodiment of the present application provides a communication method supporting multiple protocol stacks. The method is applied to a communication system supporting multiple protocol stacks, the communication system including a network port controller, an Ethernet protocol stack, and a data plane protocol stack; the network port controller determines that a received first message is a management plane message; the network port controller outputs the first message to the Ethernet protocol stack; the Ethernet protocol stack outputs the first message to a first application in response to the received first message; the network port controller determines that a received second message is a data plane message; the network port controller saves the second message to a first memory; the data plane protocol stack parses the second message in the first memory to obtain location information of a specified field of the second message in the first memory; the data plane protocol stack outputs the location information of the specified field to a second application, so that the second application obtains the specified field from the first memory according to the location information of the specified field.

[0027] In one possible implementation, the network port controller includes a correspondence between characteristic fields and message types, and the network port controller determines that the first message received is a management plane message, including: based on the correspondence between characteristic fields and message types, determining that the message type corresponding to the characteristic field of the first message is a management plane message.

[0028] In one possible implementation, the network port controller includes a correspondence between characteristic fields and message types, and the network port controller determines that the received second message is a data plane message, including: based on the correspondence between characteristic fields and message types, determining that the message type corresponding to the characteristic field of the second message is a data plane message.

[0029] In a possible implementation, the network port controller includes a first hardware queue corresponding to the management plane protocol stack. After the network port controller determines that the received first message is a management plane message, it also includes: placing the received first message in the first hardware queue.

[0030] In a possible implementation, the network port controller outputs the first message to the Ethernet protocol stack, including: outputting the first message in the first hardware queue to the Ethernet protocol stack.

[0031] In a possible implementation, the network port controller includes a second hardware queue corresponding to the data plane protocol stack. After the network port controller determines that the received second message is a data plane message, the method includes: placing the received second message in the second hardware queue.

[0032] In a possible implementation, the network port controller saves the second message into the first memory, including: outputting at least one message in the second hardware queue to the first memory, wherein the at least one message includes the second message.

[0033] In a possible implementation, after saving the second packet into the first memory, the network interface controller further includes: writing, by the network interface controller, the location information of each of the at least one packet in the first memory into the second memory; reporting, by the network interface controller, an interrupt to the data plane protocol stack; parsing, by the data plane protocol stack, the second packet in the first memory to obtain the location information of the specified field of the second packet in the first memory, including: obtaining, by the data plane protocol stack, the location information of each of the at least one packet from the second memory in response to the received interrupt; reading, by the data plane protocol stack, the at least one packet in the first memory based on the obtained location information of each of the at least one packet, and determining the location information of the specified field of each of the at least one packet.

[0034] The second aspect and any possible implementation manner of the second aspect correspond to the first aspect and any possible implementation manner of the first aspect respectively. For details, refer to the technical effects of the first aspect and any possible implementation manner of the first aspect, which will not be described herein again.

[0035] In a third aspect, an embodiment of the present application provides a chip. The chip includes at least one processor and a network interface controller. The network interface controller and the processor can implement the method in the first aspect and any possible implementation manner of the first aspect.

[0036] The third aspect and any possible implementation manner of the third aspect correspond to the first aspect and any possible implementation manner of the first aspect respectively. For details, refer to the technical effects of the first aspect and any possible implementation manner of the first aspect, which will not be described herein again.

[0037] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium. The computer readable storage medium stores a computer program. When the computer program is executed on a computer or a processor, the computer or the processor executes the method in the first aspect or any possible implementation manner of the first aspect.

[0038] The fourth aspect and any possible implementation manner of the fourth aspect correspond to the first aspect and any possible implementation manner of the first aspect respectively. For details, refer to the technical effects of the first aspect and any possible implementation manner of the first aspect, which will not be described herein again.

[0039] In a fifth aspect, an embodiment of the present application provides a computer program product. The computer program product contains a software program. When the software program is executed on a computer or a processor, the method in the first aspect or any possible implementation manner of the first aspect is executed.

[0040] The fifth aspect and any kind of implementation manner of the fifth aspect correspond to the first aspect and any kind of implementation manner of the first aspect respectively. The technical effects corresponding to the fifth aspect and any kind of implementation manner of the fifth aspect can refer to the technical effects corresponding to the first aspect and any kind of implementation manner of the first aspect, which will not be described here again. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 A host structure schematic diagram provided by an embodiment of the present application;

[0042] Figure 2 A structure schematic diagram of a data plane software stack shown by way of example;

[0043] Figure 3 An initialization flow schematic diagram shown by way of example;

[0044] Figure 4a A processing schematic diagram of a network port controller on a received message shown by way of example;

[0045] Figure 4b A processing schematic diagram of a network port controller on a received message shown by way of example;

[0046] Figure 4c A processing schematic diagram of a network port controller on a received message shown by way of example;

[0047] Figure 4d A module interaction flow schematic diagram in a receiving direction shown by way of example;

[0048] Figure 4e A processing schematic diagram of a data plane software stack on a received message shown by way of example;

[0049] Figure 4f A processing schematic diagram of a data plane software stack on a received message shown by way of example;

[0050] Figure 4g A processing schematic diagram of a data plane software stack on a received message shown by way of example;

[0051] Figure 4h A processing schematic diagram of an application on a received message shown by way of example;

[0052] Figure 5 A structure schematic diagram of an apparatus provided by an embodiment of the present application;

[0053] Figure 6 A structure schematic diagram of a chip provided by an embodiment of the present application. DETAILED DESCRIPTION

[0054] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work are within the protection scope of the present application.

[0055] The term "and / or" in the present application is only used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone.

[0056] The terms "first" and "second" and the like in the description and claims of the embodiments of the present application are used to distinguish different objects, and are not used to describe the specific order of the objects. For example, the first target object and the second target object are used to distinguish different target objects, and are not used to describe the specific order of the target objects.

[0057] In the embodiments of the present application, the words such as "exemplary" or "for example" are used to mean an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "exemplary" or "for example" are intended to present the relevant concept in a specific manner.

[0058] In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality of" is two or more. For example, a plurality of processing units means two or more processing units; a plurality of systems means two or more systems.

[0059] The communication method in the embodiments of the present application can be applied to an automatic driving system. For example, the automatic driving system can include a host and an external device. The communication method in the embodiments of the present application can also be applied to other application scenarios that have requirements for compatibility and timeliness of data processing, which are not limited by the present application.

[0060] Figure 1 A host structure schematic diagram is provided in the embodiments of the present application. Please refer to Figure 1 For example, the host includes but is not limited to: an application layer, a kernel layer, a management plane software stack running on the kernel, at least one data plane software stack (for example, data plane software stacks 1-n) running on the kernel, and a physical network port.

[0061] Exemplarily, the application layer optionally comprises one or more application programs. For example, task scheduling, master-slave communication, MDC (Mobile Data Center) awareness algorithm, authentication module (may also be referred to as authentication application program), and one or more algorithm applications, which may also be referred to as data plane applications in embodiments of the present application, such as App0-Appn shown in Figure 1 The algorithm applications may include but are not limited to fusion algorithm applications, awareness algorithm applications, and regulation and control algorithm applications.

[0062] Exemplarily, in embodiments of the present application, the software stack can be divided into a management plane software stack and a data plane software stack (for example, data plane protocol stacks 1-n shown in Figure 1 Exemplarily, the management plane software stack and the data plane software stack are isolated from each other and do not affect each other, and can run concurrently.

[0063] Exemplarily, the management plane software stack can be used to process communication data of the management plane. For example, a physical network port receives management plane data (may also be referred to as management plane packet, management plane data packet, or management plane information, which is not limited in the present application) input by an external device (such as a radar). The physical network port can output the management plane data to the management plane protocol stack. The management plane protocol stack processes the management plane data accordingly and outputs the processed data to the application layer.

[0064] Exemplarily, the management plane software stack can optionally run on a Linux kernel (may also be referred to as an operating system kernel) of the kernel layer. The management plane software stack includes but is not limited to an Ethernet protocol stack, an Ethernet network port driver, and an Ethernet driver framework.

[0065] Exemplarily, the Ethernet protocol stack, the Ethernet network port driver, and the Ethernet driver framework belong to the kernel state. Exemplarily, the management plane software stack can be compatible with the user programming interface of the POSIX standard.

[0066] Exemplarily, the processing procedure of the management plane software stack on the management plane data can refer to the description in the existing protocol standard. The present application will not be described again.

[0067] Still referring to Figure 1 Exemplarily, the data plane software stack can comprise one or more data plane software stacks. Exemplarily, each data plane software stack can be bound with one or more applications in the application layer. In embodiments of the present application, an example is taken that each data plane software stack is bound with one application in the application layer.

[0068] For example, a UIO (User Input Output) protocol stack in the data plane software stack can be used to parse the data plane packet stored in the memory to obtain the address and length of the payload field (also referred to as the effective data field) of the data plane packet in the memory. The address and length of the payload are sent to the application layer, so that the application layer can directly read the payload field of the data plane packet from the memory, and ignore other parts (such as the header) of the data plane packet. That is, in the embodiment of the present application, the UIO protocol stack can provide a simple processing mode for the data plane packet, and the decapsulation process is only to remove the header of the data plane packet to provide the payload field without the header for the application layer.

[0069] For example, the UIO network interface driver can include a module running on the Linux kernel in the kernel layer (such as UIO_K_DRV below) and a module running on the AOS (Automotive Operate System) kernel in the kernel layer (such as UIO_U_DRV below). The UIO network interface driver can be used to abstract the underlying hardware (such as the network interface controller) so that the application can access (or call) the underlying hardware. For example, the UIO network interface driver is also used for message receiving and sending processing, that is, to implement the receiving processing of the message from the external device and the sending processing of the message sent by the upper layer application to the external device.

[0070] For example, the UIO driver framework can be used to provide the underlying API (Application Programming Interface) compatible with the AOS kernel and the Linux kernel.

[0071] It should be noted that Figure 1 The components included in the application layer, the kernel layer and the software stack shown do not constitute a specific limitation on the device. In other embodiments of the present application, the device can include more or fewer components than shown, or combine certain components, or split certain components, or different component arrangements.

[0072] Figure 2 The structure of the software stack is shown for example. Please refer to Figure 2For example, in an embodiment of the present application, a physical network port may include multiple hardware queues, which may also be referred to as message queues. For example, the multiple queues may be divided into management plane queues and data plane queues. The management plane queue is used to cache management plane data. The data plane queue is used to cache data plane data. For example, the data plane queue may optionally include at least one data plane sub-queue. For example, each data plane sub-queue may be bound to a corresponding data plane software stack.

[0073] For example, Figure 2 As shown, the physical network includes queues 0 to n. Exemplarily, in an embodiment of the present application, a single queue is bound to a software stack. For example, queue 0 corresponds to the management plane software stack, and queue 0 is optionally a management plane queue. That is, the messages in queue 0 will be handed over to the management plane software stack for transceiver processing. Exemplarily, queue 1 corresponds to data plane software stack 1, and queue n corresponds to data plane software stack n. Queues 1 to n are optionally data plane queues. Accordingly, the messages in queue 1 will be handed over to data plane software stack 1 for transceiver processing. The messages in queue n will be handed over to data plane software stack n for transceiver processing.

[0074] For example, in an embodiment of the present application, the management plane software stack may be bound to multiple APPs (applications). Figure 2 Only the management plane software stack is shown to correspond to APP0. In fact, the management plane software stack can correspond to APP0 and multiple other APPs to output the messages in queue 0 to the corresponding APP and send the messages of multiple APPs to other devices.

[0075] For example, in the embodiment of the present application, a single data plane software stack corresponds to one APP. For example, please refer to Figure 2 Data plane software stack 1 corresponds to APP1, and data plane software stack n corresponds to APPn. That is, data plane software stack 1 can send and receive messages for APP1, and data plane software stack n can send and receive messages for APPn.

[0076] Still refer to Figure 2 For example, the data plane software stack 1 is taken as an example. The data plane software stack 1 includes but is not limited to: UIO protocol stack, UIO network port driver and UIO driver framework.

[0077] For example, in the embodiment of the present application, the UIO network port driver can be divided into two parts, including a user state part and a kernel state part. For example, for the convenience of description, the user state part is referred to as UIO_U_DRV and the kernel state part is referred to as UIO_K_DRV.

[0078] For example, the UIO network port driver runs on the AOS kernel of the kernel layer (to more clearly represent the interaction between the physical network port and the management plane software stack and the data plane software stack, Figure 2 (The kernel layer is not shown separately in the following figures.) Exemplarily, UIO_K_DRV optionally includes two components: one component is UIO_K_DRV running on the Linux kernel of the kernel layer, and the other component is UIO_AK_DRV running in the AOS kernel.

[0079] Combine Figure 2 , Figure 3 FIG. 1 is a schematic diagram of an exemplary initialization process. Figure 3 The initialization process shown can also be understood as a preparation process. Figure 3 , specifically including:

[0080] S301, UIO_K_DRV creates a UIO device and creates shared memory.

[0081] Exemplarily, in an embodiment of the present application, the UIO network port driver may further include NIC_DRV, which is a common network port driver module running within the Linux kernel. Exemplarily, NIC_DRV stores an initialization function, and NIC_DRV executes the initialization function. For example, initialization may include memory allocation, data structure initialization, etc. Furthermore, NIC_DRV executes the initialization function, causing NIC_DRV to call UIO_K_DRV for initialization.

[0082] Exemplarily, in response to the call of NIC_DRV, UIO_K_DRV runs the initialization function of UIO_K_DRV, so that UIO_K_DRV creates the UIO device and creates the shared memory.

[0083] Exemplarily, the UIO device may optionally be a hardware device. For example, it may be a network port controller. It can be understood that, in the embodiment of the present application, UIO_K_DRV virtualizes the underlying hardware (e.g., the network port controller) into a UIO device, exposing the underlying hardware to the user-mode UIO network port driver. The user-mode UIO network port driver can then operate the underlying hardware. For example, through relevant instructions, the UIO device can be opened.

[0084] Exemplarily, UIO_K_DRV optionally applies for MBUF (Memroy buffer, shared memory) memory from the MBUF module.

[0085] For example, the MBUF is used to provide the shared memory pool for the application and the UIO communication stack to perform memory allocation, recycling, and the like, and is used to provide the UIO network interface driver with a memory block with continuous physical addresses. In addition, the MBUF is used to provide the UIO driver with an API interface for converting a virtual address to a physical address. The specific role of the MBUF can refer to the prior art embodiments, and will not be described here.

[0086] For example, the MBUF memory is used to store data. In the subsequent process, the network interface controller can write data into the MBUF memory, and the application can directly read data from the MBUF memory. In addition, the data of the application can be written into the MBUF memory, and the network interface controller can directly read the data from the MBUF memory and send it, so as to realize zero-copy of data without the participation of the CPU, thereby reducing the CPU overhead.

[0087] For example, the UIO_K_DRV can also apply for and create shared memory from the kernel. Optionally, the shared memory includes but is not limited to communication memory between the user mode and the kernel mode, hardware register memory, buffer descriptor (BD) memory, and the like.

[0088] For example, the UIO_K_DRV can call a UIO device registration function provided by the operating system kernel, so that the UIO device is registered to the operating system kernel. It can be understood that the UIO_K_DRV returns the identification information (such as the device name of the UIO device) of the created UIO device to the UIO network interface driver in the user mode. In this way, the UIO network interface driver in the user mode can perform relevant operations on the UIO device according to the identification information of the UIO device, such as the device name of the UIO device, such as opening the UIO device.

[0089] S302, the application opens the UIO device.

[0090] For example, the UIO_U_DRV in the user mode can provide the application with an API interface function. The application can perform corresponding operations on the UIO device through the API interface function. For example, the application can input an opening instruction through the API interface function provided by the UIO_U_DRV, and the opening instruction can optionally include a corresponding UIO device name, which is used to indicate the opening of the UIO device corresponding to the specified UIO device name.

[0091] S303, the UIO_U_DRV authenticates the application.

[0092] For example, the UIO_U_DRV receives an operation instruction issued by an application program, such as an opening instruction. To ensure the safety of the device, the UIO_U_DRV can optionally authenticate the application program to detect whether the application program has the permission to operate the UIO device.

[0093] For example, an authentication module, which can also be referred to as a permission control module, can be included in the autonomous driving operating system. Optionally, the authentication module can be located in the application layer shown in FIG. 1. Figure 1 For example, the UIO_U_DRV can call the authentication module to authenticate the application program to check whether the application program is legal. Optionally, if the application program is not legal, the UIO_U_DRV denies the access of the application program to the UIO device based on the result returned by the authentication module. Optionally, if the application program is legal, the UIO_U_DRV allows the application program to access the UIO device based on the result returned by the authentication module.

[0094] S304, the UIO_U_DRV binds the process with the SMMU module.

[0095] For example, the SMMU (system memory manage unit) is a hardware module inside the SoC that is specifically used for virtual address and physical address conversion. It can be understood that this module can be used to provide the underlying hardware with the function of converting between the user-mode virtual address and the physical address of the hardware. For example, when the network controller needs to read data from the MBUF memory, it obtains the virtual address corresponding to the data in the MBUF memory. The network controller can call the SMMU module to convert the user-mode virtual address to obtain the corresponding physical address. The SMMU module can send the physical address to the bus so that the storage device extracts the corresponding data based on the physical address and transmits it to the network controller.

[0096] The binding process of the process and the SMMU module will be briefly described below. For example, in response to the operation instruction received by the application program to open the UIO device, the UIO_U_DRV calls the interface provided by the SMMU module to output the process ID of the application program to the SMMU module.

[0097] Exemplarily, the SMMU module returns a SSID (substream identifier) to the UIO_U_DRV after the process is bound to the SMMU module. Exemplarily, the SMMU module can understand as implementing address translation function by searching page table of memory address, and the SSID can be used to identify the page table to which the virtual address belongs. Exemplarily, each application has its own address page table in the operating system, and the SMMU module can find the page table corresponding to the application process based on the SSID, and search the corresponding relationship between the virtual address and the physical address in the page table.

[0098] Exemplarily, the UIO_U_DRV receives the SSID returned by the SMMU module. The UIO_U_DRV allocates the SSID to the network interface controller. So that the network interface controller can call the SMMU module for address translation based on the SSID. It should be noted that the role of the SMMU module is only briefly described in the embodiments of the present application, and the specific details can refer to the implementation process of the SMMU module in the prior art embodiments, which will not be described herein.

[0099] S305, the UIO_U_DRV maps the shared memory in the kernel mode to the user space.

[0100] Exemplarily, as described above, the UIO_K_DRV in the kernel mode creates the MBUF memory and the plurality of shared memories in S301. It can be understood that each memory has a corresponding virtual address in the kernel mode, and the UIO network interface driver in the kernel mode can read and write the memory based on the virtual address of each memory.

[0101] In the embodiments of the present application, the UIO_U_DRV can map the memory in the kernel mode to the user mode, so that the UIO driver in the user mode can also read and write each memory. Specifically, the UIO_U_DRV can call the mmap function provided by the operating system to map the plurality of memories created by the UIO_K_DRV to the user mode. It can be understood that each memory has a corresponding virtual address in the user mode, and the UIO driver in the user mode can access these memories based on the virtual address of each memory.

[0102] Exemplarily, the communication memory between the user mode and the kernel mode can be used to store the number of packet sending and receiving queues, the hardware interrupt number, the number of threads, the base address of the BD (buffer descriptor), etc. The UIO_U_DRV can obtain the corresponding information, such as the hardware interrupt number, from the communication memory between the user mode and the kernel mode based on the mapping relationship. Wherein, each queue corresponds to a hardware interrupt number, for example, as shown in Figure 2 , the queue 1 corresponds to the hardware interrupt number 1, and the queue n corresponds to the hardware interrupt number n. The hardware interrupt number is generated by the system, which will not be repeated hereinafter.

[0103] S306, the UIO_U_DRV registers an interrupt to the UIO_AK_DRV.

[0104] For example, after the UIO_U_DRV obtains the information such as the transmit / receive interrupt number from the communication memory between the user mode and the kernel mode, the UIO_U_DRV can call the interrupt registration function provided by the UIO_AK_DRV to register the interrupt.

[0105] For example, the UIO_U_DRV can output the obtained information such as the hardware interrupt number to the UIO_AK_DRV. For example, the UIO_AK_DRV applies for an interrupt and registers an interrupt processing function to the operating system kernel in response to the received information such as the hardware interrupt number. For example, the operating system can assign a corresponding software interrupt number to the hardware interrupt number. The UIO_AK_DRV can register the interrupt processing based on the interrupt number. In the subsequent packet transmission process, when the packet transmission is completed, the network interface controller can report the hardware interrupt number of the queue to the operating system, and the operating system can determine the corresponding software interrupt number and the interrupt event corresponding to the software interrupt number based on the corresponding hardware interrupt number, so as to enable the UIO device (for example, the network interface controller) to perceive the interrupt. It should be noted that the purpose of assigning the software interrupt number is to ensure system safety, so that the hardware interrupt number is only used for hardware transmission, and the processing between the kernels can be processed based on the software interrupt number.

[0106] S307, the UIO_U_DRV starts a thread and a UIO device.

[0107] For example, the UIO_U_DRV starts a data plane thread. The data plane thread can be used to wait for the arrival of the transmit / receive packet event of the network interface hardware, so as to execute the transmit / receive packet related processing flow in the thread function.

[0108] For example, the UIO_U_DRV starts a management plane thread. The management plane thread is used to call the poll function to block and wait for various management plane event messages of the operating system. For example, network interface Link down, Link up, network interface failure, etc. For example, the management plane thread can apply for an event ID and an interrupt number to the event scheduling module in the UIO_AK_DRV. The management plane thread can input the event ID and the interrupt number corresponding to each other to the UIO_U_DRV. Correspondingly, the UIO_U_DRV can input the event ID and the interrupt number corresponding to each other to the operating system kernel.

[0109] For example, the data plane thread can output the event ID to the event management scheduler. For example, the event management scheduler can save the corresponding relationship between the event ID and the thread ID of the data plane thread.

[0110] Exemplarily, UIO_U_DRV enables the UIO device (ie, the network port controller). For example, UIO_U_DRV can write information to the network port controller queue interrupt enable register to start the queue in the network port controller corresponding to the protocol stack to which UIO_U_DRV belongs (eg Figure 2 The network port controller can respond to the UIO_U_DRV operation and start receiving and sending messages.

[0111] For example, Figure 3 After the preparation process is completed, the UIO device suspends the data plane thread and the management plane thread and enters the sleep state to wait for the arrival of the packet sending and receiving event.

[0112] Combine Figure 2 and Figure 3 , Figure 4a This is a schematic diagram showing an example of how the network port controller processes the received message. Figure 4a For example, external device 1 (such as a radar) sends message 1 to the host. Message 1 is a management plane message. Figure 4a The dotted line shown in the figure is a schematic diagram of the transmission path of the management plane message. Exemplarily, the network port controller receives message 1. The network port controller may be pre-configured with a hardware flow table. Exemplarily, the hardware flow table may record the correspondence between address information and communication type (including data plane communication and management plane communication). For example, the network port controller may search the hardware flow table based on the address information carried in the message, such as the five-tuple information, to obtain the communication type corresponding to the five-tuple information that is successfully matched, so as to determine whether the message is a data plane message or a management plane message.

[0113] For example, if the network port controller determines that message 1 is a management plane message, the network port controller can place the message in the queue corresponding to the management plane protocol stack, that is, Figure 2 The management plane protocol stack can process the messages in queue 0 accordingly and output the data to the corresponding application, such as APP0.

[0114] Combine Figure 2 and Figure 3 , Figure 4b This is a schematic diagram showing an example of how the network port controller processes the received message. Figure 4b For example, external device 1 (such as a radar) sends message 2 to the host. Message 2 is a data plane message. Figure 4b The dotted line shown in FIG is a schematic diagram of the transmission path of the data plane message.

[0115] For example, the network interface controller determines that the packet 2 is a data plane packet. The network interface controller can place the packet in a corresponding queue based on a binding relationship between the queue, the UIO protocol stack and the application. For example, the network interface controller receives a packet from the external device 1. After detecting that the packet is a data plane packet, the network interface controller can place the data plane packet from the external device 1 in the queue 1 based on the corresponding relationship between the external device 1 and the queue 1.

[0116] Still referring to Figure 4b , for example, the data plane packet (e.g., the packet 2) in the queue 1 will be processed by the data plane software stack 1 so that the APP 1 obtains the packet 2.

[0117] The processing mode of the data plane packet will be described in detail below in conjunction with specific embodiments. Please refer to Figure 4c , for example, as described in the steps in Figure 3 , in the preparation phase, the UIO_K_DRV creates the MBUF memory and one or more shared memories (e.g., the BD memory in Figure 4c ). After the network interface controller receives the complete packet 1, the network interface controller can store the packet 2 in the MBUF memory. For example, the network interface controller can read the virtual address of the MBUF memory from the BD memory based on the virtual address of the BD memory in the kernel state. For example, the network interface controller can output the packet 2, the SSID (the concept is described above) and the virtual address of the MBUF memory to the SMMU module. For example, as described above, the SMMU module can detect the page table identified by the SSID based on the SSID. The SMMU can retrieve the corresponding hardware address in the page table based on the virtual address. For example, the SMMU module can output the data and the hardware address to the bus and transmit them to the storage device, such as the DDR (Double Data Rate, Double Data Rate Synchronous Dynamic Random Access Memory) through the bus. The DDR can write the packet 2 into the MBUF memory indicated by the hardware address.

[0118] For example, after the network interface controller completes the writing of the packet 2, the network interface controller updates the related information of the data recorded in the BD memory. For example, the network interface controller moves the write pointer in the BD memory to indicate the number of packets currently written by the network interface controller into the MBUF memory. For example, one BD is used to indicate that one packet is stored in the memory. Correspondingly, in the subsequent process, the UIO_U_DRV can determine the number of packets written by the network interface controller into the MBUF memory based on the movement of the pointer in the BD memory. And, the related information corresponding to the packet can also be obtained based on the write pointer. For example, the related information includes but is not limited to: the starting address of the packet, the length of the packet, etc.

[0119] In conjunction with Figure 4c , Figure 4dThe message receiving processing flowchart is shown for example. Please refer to Figure 4d , and specifically includes:

[0120] S401, the network interface controller reports an interrupt to the operating system kernel.

[0121] For example, as shown in Figure 4c , after the network interface controller writes at least one message into the memory, the network interface controller can generate a hardware interrupt to trigger the operating system kernel to execute subsequent steps. For example, as described above, in the preparation phase, the network interface controller obtains the hardware interrupt number corresponding to each queue. If the network interface controller completes the write operation of message 2 in queue 1, the network interface controller can report the hardware interrupt number 1 corresponding to queue 1 to the operating system kernel (for example, the Linux kernel in the kernel layer).

[0122] Optionally, in the embodiment of the present application, the network interface controller can generate an interrupt and trigger other modules to execute the processing flow of multiple messages after receiving multiple messages, for example, two or more messages. So that the UIO protocol stack can process multiple messages at a time to reduce the number of interrupts and further reduce the overhead required for processing messages each time.

[0123] S402, the operating system kernel outputs a software interrupt number to the UIO_K_DRV.

[0124] For example, the operating system kernel responds to the received hardware interrupt number sent by the network interface controller. As described above, the operating system kernel maintains the correspondence between the hardware terminal number and the software terminal number. For example, the operating system kernel can obtain the corresponding software terminal number based on the received hardware interrupt number. For example, the operating system outputs the software interrupt number to the UIO_K_DRV to call the interrupt processing function in the UIO_K_DRV (the concept can refer to the above).

[0125] S403, the UIO_K_DRV outputs an event ID to the event scheduling module.

[0126] For example, the UIO_K_DRV responds to the received software interrupt number and can obtain the event ID corresponding to the software interrupt number based on the interrupt processing function.

[0127] For example, the UIO_K_DRV outputs the event ID to the event scheduling control module to indicate that there is an interrupt event corresponding to the event ID.

[0128] S404, the UIO_K_DRV closes the queue interrupt.

[0129] For example, during the process of handling the current interrupt by the UIO_K_DRV and other modules, the UIO_K_DRV can instruct the operating system kernel to close the interrupt of the queue. That is, no interrupt will be generated after receiving the packet in the queue, so as to prevent the current processing flow of the terminal by the UIO_K_DRV and other modules from being interrupted by the subsequent interrupt. It can be understood that the automatic driving system is accompanied by a corresponding overhead during the process of handling the packet corresponding to each interrupt. If the receiving process is repeated during the current processing flow interrupted by the subsequent interrupt, the scheduling overhead will be increased. Therefore, closing the interrupt can effectively reduce the scheduling overhead.

[0130] S405, the event scheduling module determines the corresponding thread based on the event ID.

[0131] For example, as described above, the event scheduling module records the correspondence between the event ID and the thread. For example, in the embodiment of the present application, one event ID corresponds to one thread, and a single thread can process the packets of multiple queues.

[0132] For example, the event scheduling module determines the thread corresponding to the received event ID in response to the event ID.

[0133] S406, the event scheduling module wakes up the data plane thread.

[0134] For example, as described above, the data plane thread in the UIO_U_DRV is in a sleep state after the preparation process. For example, after determining the data plane thread that needs to be woken up, the event scheduling module can wake up the data plane thread, so that the data plane thread performs the transceiving packet processing.

[0135] S407, the data plane thread performs transceiving packet processing.

[0136] For example, the data plane thread can read the interrupt status register of the queue to determine whether it is a transmit (TX) interrupt or a receive (RX) interrupt.

[0137] For example, if the data plane thread determines that it is a receive interrupt (the transmit interrupt will be described in the following embodiment), it can be determined that the network controller has successfully received at least one packet, which can be one packet, or two or more packets. For example, as described above, the network controller writes at least one packet into the MBUF memory and indicates the number of received packets, the address of the packet in the memory, and the length of the packet by moving the write pointer in the BD memory

[0138] To better illustrate the processing manner of the data plane software stack to the data plane packet, the processing manner of the data plane software stack to packet 2 is described below. In other embodiments, if other packets are stored in the MBUF memory, the processing manner is the same as that of packet 2, and details are not described herein.

[0139] Referring to Figure 4e , for example, as described above in S305, the UIO_U_DRV maps the kernel-mode MBUF memory and the shared memory to the user mode, that is, the data plane thread in the UIO_U_DRV can read information in the MBUF memory and the shared memory based on the virtual addresses of the MBUF memory and the shared memory in the user mode.

[0140] Still referring to Figure 4e , for example, the data plane thread can read the relevant information (including the address and length of packet 2 in the MBUF memory, etc.) indicated by the read pointer in the BD memory by moving the read pointer until the read pointer coincides with the write pointer. It should be noted that the pointer reading manner in the BD memory can refer to the related content in the prior art embodiments, and details are not described herein.

[0141] Still referring to Figure 4e , for example, the data plane thread outputs the address and length of packet 2 in the MBUF memory to the UIO protocol stack.

[0142] Referring to Figure 4f , for example, the UIO protocol stack can read packet 2 in the MBUF memory based on the address and length of packet 2 in the MBUF memory. The UIO protocol stack can detect the address and length of the payload field of packet 2. For example, the packet can optionally include a header and a payload field, and can also include a CRC field, etc., which is not limited in the present application. The data plane thread can read the address and length of the payload field of packet 2 in the MBUF memory.

[0143] Referring to Figure 4g , for example, the UIO protocol stack can send the address and length of the payload field of packet 2 to APP1.

[0144] Referring to Figure 4h , for example, APP1 can read the payload field from the MBUF memory based on the address and length of the payload field input by the UIO protocol stack. That is, in the embodiments of the present application, the UIO protocol stack can strip the header of packet 2 so that the upper-layer application directly obtains the data part in the packet.

[0145] It should be noted that only the payload field is taken as an example for description in the embodiments of the present application. In other embodiments, the UIO protocol stack can be previously negotiated with the APP to determine which fields in the message the APP is interested in, and the UIO protocol stack can send the address and length of the field of interest of the APP to the APP.

[0146] For example, in the embodiments of the present application, as described above, the network port controller can report a hardware interrupt after receiving a plurality of messages, that is, the MBUF memory has stored a plurality of messages at this time, and the BD memory records the related information (such as the address and length of the message in the MBUF memory) of each of the plurality of messages.

[0147] In one example, the data plane thread and the UIO protocol stack can process the plurality of messages in the MBUF memory one by one according to the processing method of message 2 described above. For example, the data plane thread sends the address and length of a message to the UIO protocol stack after obtaining the address and length of the message. The UIO protocol stack parses the message, sends the address and length of the payload field to the APP, and sequentially processes other messages in the MBUF memory.

[0148] In another example, the data plane thread and the UIO protocol stack can process a plurality of messages at the same time. For example, the data plane thread can obtain the address and length of each of the plurality of messages from the BD memory. The data plane thread sends the addresses and lengths of the plurality of messages to the UIO protocol stack. The UIO protocol stack reads the address and length of the payload field of each of the plurality of messages. And the UIO protocol stack sends the address and length of the payload field of each of the plurality of messages to the APP.

[0149] In the embodiments of the present application, the application can directly read the payload field from the MBUF memory based on the address and length of the payload field of the message input by the data plane software stack in the MBUF memory. Thus, zero-copy transmission of the message is realized, and multiple copying of the message in the processing flow of the management plane protocol stack, that is, the Ethernet software protocol stack, is not required.

[0150] Optionally, after the application reads the message, the UIO network port driver can be instructed to release the memory area in the MBUF memory storing the message to recycle the memory area, thereby saving memory resources.

[0151] In the embodiment of the present application, in the process of reporting the interrupt by the network port controller, the UIO network port driver responds to the interrupt with the highest priority when processing the interrupt, and notifies the event dispatcher in the interrupt function to notify the corresponding thread in the user-mode UIO network port driver to process the interrupt event in time. Thus, through the interrupt pass-through manner, the requirement of the vehicle automatic driving field for time delay deterministic data communication is met.

[0152] S408, the data plane thread enables the hardware interrupt.

[0153] For example, after the data plane thread completes the processing of the current interrupt, the data plane thread can instruct the operating system kernel to re-enable the interrupt. In response to the instruction of the data plane thread, the operating system kernel can allow the network port controller to continue reporting the interrupt and repeatedly execute the above process.

[0154] For example, Figure 4d The modules shown in the figure are the interaction processes in the receiving direction. For the sending direction, that is, the application needs to send data to the external device. The specific process can be: in combination with Figure 2 For example, APP1 writes data into the MBUF memory. Moreover, APP1 outputs the address of the data in the MBUF memory and the data length and other related information to the corresponding software stack, that is, the data plane software stack 1. The UIO protocol stack transmits the obtained related information to the UIO network port driver. For example, the UIO network port driver can update the pointer in the BD memory based on the related information. The specific updating manner can refer to the prior art, and the present application is not limited.

[0155] For example, the network port controller can obtain the virtual address of the data in the MBUF memory, the data length and other information based on the pointer in the BD memory. For example, the network port controller can obtain the data from the MBUF memory through the SMMU module. The specific details are similar to the data receiving process, which will not be described here.

[0156] For example, after the network port controller obtains the data, the network port controller can perform corresponding processing on the data, for example, Ethernet encapsulation on the data, to obtain the corresponding packet. The network port controller places the packet in the queue 1 and sends it.

[0157] For example, after the packet in the queue 1 is sent, the network port controller can report the queue interrupt number of the queue 1 to the operating system kernel. The specific details can refer to the description of S402-S406. For example, after the UIO_U_DRV (specifically, the data plane thread) is awakened, it can be determined that the current interrupt event is a sending interrupt, and it can be further determined that the data in the MBUF memory has been sent. For example, the UIO_U_DRV can release the cache area storing the data. And re-enable the hardware interrupt, that is, execute S408.

[0158] The following describes a device provided by an embodiment of the present application. Figure 5 As shown:

[0159] Figure 5 This is a schematic diagram of the structure of a communication device provided in an embodiment of the present application. Figure 5 As shown, the communication device 500 may include: a processor 501 , a transceiver 505 , and optionally a memory 502 .

[0160] The transceiver 505 may be referred to as a transceiver unit, a transceiver, or a transceiver circuit, etc., and is configured to implement transceiver functions. The transceiver 505 may include a receiver and a transmitter. The receiver may be referred to as a receiver or a receiving circuit, etc., and is configured to implement a receiving function; the transmitter may be referred to as a transmitter or a transmitting circuit, etc., and is configured to implement a transmitting function.

[0161] The memory 502 may store a computer program or software code or instruction 504, which may also be referred to as firmware. The processor 501 may control the MAC layer and the PHY layer by running the computer program or software code or instruction 503 therein, or by calling the computer program or software code or instruction 504 stored in the memory 502, to implement the communication methods provided in various embodiments of the present application. The processor 501 may be a central processing unit (CPU), and the memory 502 may be, for example, a read-only memory (ROM) or a random access memory (RAM).

[0162] The processor 501 and transceiver 505 described in this application can be implemented on an integrated circuit (IC), an analog IC, a radio frequency integrated circuit RFIC, a mixed signal IC, an application specific integrated circuit (ASIC), a printed circuit board (PCB), an electronic device, etc.

[0163] The communication device 500 may further include an antenna 506. The modules included in the communication device 500 are merely examples and are not limited in this application.

[0164] As mentioned above, the communication device described in the above embodiment may be an automatic driving system, but the scope of the communication device described in this application is not limited thereto, and the structure of the communication device may not be limited thereto. Figure 5The communication device can be a stand-alone device or can be a part of a larger device. For example, the communication device can be implemented as:

[0165] (1) a stand-alone integrated circuit (IC), or chip, or chip system or subsystem; (2) a set of one or more ICs, optionally including memory elements to store data and instructions; (3) a module that can be embedded within another device; (4) a vehicle-mounted device; and the like; (5) other; and the like.

[0166] For the case that the communication device is implemented as a chip or chip system, refer to Figure 6 for a structural diagram of the chip. Figure 6 The chip includes a processor 601 and an interface 602. The number of the processor 601 can be one or more, and the number of the interface 602 can be multiple. Optionally, the chip or chip system can include a memory 603.

[0167] All the related content of each step involved in the above method embodiments can be referred to the function description of the corresponding function module, and will not be repeated here.

[0168] Based on the same technical concept, the embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program includes at least one piece of code, which can be executed by a computer to control the computer to implement the above method embodiments.

[0169] Based on the same technical concept, the embodiments of the present application further provide a computer program, which is executed by a terminal device to implement the above method embodiments.

[0170] The program can be stored in a storage medium packaged with the processor in whole or in part, or in a storage medium not packaged with the processor in whole or in part.

[0171] Based on the same technical concept, the embodiments of the present application further provide a chip, which includes a network interface controller and a processor. The network interface controller and the processor can implement the above method embodiments.

[0172] The steps of methods or algorithms described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable media, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC.

[0173] Those skilled in the art can realize that the functions described in the above one or more examples can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions can be stored in or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available media that can be accessed by a general purpose or special purpose computer.

[0174] The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described specific embodiments, and the above-described specific embodiments are merely illustrative, not restrictive, and those of ordinary skill in the art can make many forms under the inspiration of the present application without departing from the scope of the present application and the scope of protection of the claims, which are all within the scope of protection of the present application.

Claims

1. A communication system supporting multiple protocol stacks, characterized by The network interface controller, the Ethernet protocol stack and the data plane protocol stack are included. The network interface controller is configured to: determine that a received first packet is a management plane packet; output the first packet to the Ethernet protocol stack; The Ethernet protocol stack is configured to: in response to the received first packet, output the first packet to a first application; The network interface controller is further configured to: determine that a received second packet is a data plane packet; save the second packet to a first memory; The data plane protocol stack is configured to: analyze the second packet in the first memory to obtain location information of a specified field of the second packet in the first memory; output the location information of the specified field to a second application, so that the second application acquires the specified field from the first memory according to the location information of the specified field.

2. The system of claim 1, wherein, The network interface controller includes a correspondence between a feature field and a packet type, and the network interface controller is specifically configured to: determine, based on the correspondence between the feature field and the packet type, that the packet type corresponding to the feature field of the first packet is a management plane packet.

3. The system of claim 1, wherein, The network interface controller includes a correspondence between a feature field and a packet type, and the network interface controller is specifically configured to: determine, based on the correspondence between the feature field and the packet type, that the packet type corresponding to the feature field of the second packet is a data plane packet.

4. The system of claim 2, wherein, The network interface controller includes a first hardware queue corresponding to the Ethernet protocol stack, and the network interface controller is specifically configured to: after determining that the type of the first packet is a management plane packet, place the received first packet in the first hardware queue.

5. The system of claim 4, wherein, The network interface controller is specifically configured to: output the first packet in the first hardware queue to the Ethernet protocol stack.

6. The system of claim 3, wherein, The network interface controller includes a second hardware queue corresponding to the data plane protocol stack, and the network interface controller is specifically configured to: after determining that the type of the second packet is a data plane packet, place the received second packet in the second hardware queue.

7. The system of claim 6, wherein, The network interface controller is specifically configured to: output at least one packet in the second hardware queue to the first memory, wherein the at least one packet includes the second packet.

8. The system of claim 7, wherein The network interface controller is further configured to: write location information of each packet in the at least one packet in the first memory into a second memory; report an interrupt to the data plane protocol stack; The data plane protocol stack is specifically configured to: in response to the received interrupt, acquire the location information of each packet in the at least one packet from the second memory; based on the acquired location information of each packet in the at least one packet, read the at least one packet in the first memory and determine location information of a specified field of each packet in the at least one packet.

9. A communication method of supporting a multi-protocol stack, characterized by, The system includes a network interface controller, an Ethernet protocol stack and a data plane protocol stack; The network interface controller determines that a received first packet is a management plane packet; The network interface controller outputs the first packet to the Ethernet protocol stack; The Ethernet protocol stack outputs the first packet to a first application in response to receiving the first packet; The network interface controller determines that a received second packet is a data plane packet; The network interface controller stores the second packet in a first memory; The data plane protocol stack parses the second packet in the first memory to obtain location information of a specified field of the second packet in the first memory; The data plane protocol stack outputs the location information of the specified field to a second application, so that the second application obtains the specified field from the first memory according to the location information of the specified field.

10. The method of claim 9, wherein, The network interface controller includes a correspondence between a feature field and a packet type, and the network interface controller determines that a received first packet is a management plane packet, including: Based on the correspondence between the feature field and the packet type, it is determined that the packet type corresponding to the feature field of the first packet is a management plane packet.

11. The method of claim 9, wherein, The network interface controller includes a correspondence between a feature field and a packet type, and the network interface controller determines that a received second packet is a data plane packet, including: Based on the correspondence between the feature field and the packet type, it is determined that the packet type corresponding to the feature field of the second packet is a data plane packet.

12. The method of claim 10, wherein, The network interface controller includes a first hardware queue corresponding to the Ethernet protocol stack, and after the network interface controller determines that a received first packet is a management plane packet, the network interface controller further includes: The received first packet is placed in the first hardware queue.

13. The method of claim 12, wherein, The network interface controller outputs the first packet to the Ethernet protocol stack, including: The first packet in the first hardware queue is output to the Ethernet protocol stack.

14. The method of claim 11, wherein, The network interface controller includes a second hardware queue corresponding to the data plane protocol stack, and after the network interface controller determines that a received second packet is a data plane packet, the network interface controller further includes: The received second packet is placed in the second hardware queue.

15. The method of claim 14, wherein, The network interface controller stores the second packet in a first memory, including: At least one packet in the second hardware queue is output to the first memory, wherein the at least one packet includes the second packet.

16. The method of claim 15, wherein, After the network interface controller stores the second packet in the first memory, the network interface controller further includes: The network interface controller writes location information of each packet in the at least one packet in the first memory into a second memory; The network interface controller reports an interrupt to the data plane protocol stack; The data plane protocol stack parses the second packet in the first memory to obtain location information of a specified field of the second packet in the first memory, including: The data plane protocol stack obtains the location information of each packet in the at least one packet from the second memory in response to receiving the interrupt; The data plane protocol stack reads the at least one packet in the first memory based on the position information of each packet in the at least one packet obtained, and determines position information of a specified field of each packet in the at least one packet.

Images