Datagram processing method and device, electronic equipment and storage medium

Abstract

The invention provides a datagram processing method and device, electronic equipment and a storage medium. According to the method, a high-performance kernel interaction processing mechanism under the multi-process service based on the DPDK is constructed, a communication mechanism under a multi-process mode is realized, multiple datagram address queues are provided under the multi-process mode, each process communicates with the VHost in the kernel mode through the uniquely corresponding datagram address queue, and the communication efficiency is improved. The resource access between the processes is lock-free and competition-free, the data is processed by fully utilizing a multi-core forwarding mechanism, the forwarding processing capability of the datagram between a kernel mode and a user mode is improved, and the product stability and the recursion capability of an intranet DNS product are improved.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a datagram processing method, device, electronic device and storage medium. Background Art

[0002] DPDK (Data Plane Development Kit) is an excellent transceiver package. It does not provide a user-mode protocol stack by itself, so there is a need to inject datagrams into the kernel protocol stack.

[0003] Among them, KNI, as the interface between user state and kernel state, is more efficient than traditional TAP devices (a virtual network device used to simulate physical network interfaces) because there are no system calls and memory copies. Summary of the invention

[0004] The present application shows a datagram processing method, device, electronic device and storage medium.

[0005] In a first aspect, the present application provides a datagram processing method, the method comprising:

[0006] For any one of the multiple independent user state processes in the data plane development kit DPDK in the user state, after receiving a first datagram sent by the user state network card through the user state process, the first datagram is cached in a shared memory through the user state process, and the shared memory is open to access rights for both the user state and the kernel state;

[0007] Acquire the address of the first datagram in the shared memory through the user state process;

[0008] The address is cached in a datagram address queue uniquely corresponding to the user state process by the user state process; different user state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user state process are open to access rights for both user state and kernel state;

[0009] Acquire the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue through the user state process; different datagram address queues have different uniquely corresponding IOevent file descriptors;

[0010] Sending the IOevent file descriptor to the virtual host VHost in kernel state through the user state process;

[0011] Receiving the IOevent file descriptor through the VHost in kernel mode;

[0012] Extracting, by the kernel-state VHost, the address of the first datagram in the shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor;

[0013] Extracting the first datagram from the shared memory according to the address by the VHost in kernel mode;

[0014] The first datagram is sent to the kernel-state protocol stack for processing through the kernel-state VHost.

[0015] In a second aspect, the present application shows a datagram processing method, the method comprising:

[0016] Obtaining, through the kernel-state virtual host VHost, a second datagram obtained by the kernel-state protocol stack after processing the first datagram;

[0017] The second datagram is cached in the shared memory through the kernel-state VHost; the shared memory is accessible to both the user-state and the kernel-state;

[0018] Obtain the address of the second datagram in the shared memory through the kernel-mode VHost;

[0019] Determine, through the kernel-state VHost, a datagram address queue uniquely corresponding to the user-state process for processing the second datagram in a plurality of mutually independent user-state processes in a data plane development kit DPDK in the user state;

[0020] The address is cached in a datagram address queue uniquely corresponding to a determined user-state process through the kernel-state VHost; different user-state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user-state process are open to access rights for both the user-state and kernel-state processes;

[0021] Monitoring whether an address is added to the datagram address queue by a determined user mode process;

[0022] In a case where an address is added to the datagram address queue, extracting the address of the second datagram in the shared memory from the datagram address queue through a determined user mode process;

[0023] extracting a second datagram from the shared memory according to the address by a determined user mode process;

[0024] The second datagram is sent to the user-mode network card through the determined user-mode process.

[0025] In a third aspect, the present application shows a datagram processing device, the device comprising:

[0026] A first cache module is used for caching, for any one of a plurality of mutually independent user-state processes in a data plane development kit DPDK in a user state, the first datagram sent by a user-state network card after being received by the user-state process, the first datagram in a shared memory through the user-state process, and the shared memory is open to access rights for both the user state and the kernel state;

[0027] A first acquisition module, used for acquiring an address of a first datagram in a shared memory through the user state process;

[0028] A second cache module is used to cache the address in a datagram address queue uniquely corresponding to the user state process through the user state process; different user state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user state process are open to access rights for both user state and kernel state;

[0029] A second acquisition module is used to acquire the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue through the user state process; different datagram address queues have different uniquely corresponding IOevent file descriptors;

[0030] A first sending module, used for sending the IOevent file descriptor to the virtual host VHost in kernel state through the user state process;

[0031] A receiving module, used for receiving the IOevent file descriptor through a VHost in kernel mode;

[0032] A first extraction module, configured to extract, through a kernel-state VHost, an address of a first datagram in a shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor;

[0033] A second extraction module, used for extracting the first datagram in the shared memory according to the address through the VHost in the kernel state;

[0034] The second sending module is used to send the first datagram to the kernel state protocol stack for processing through the kernel state VHost.

[0035] In a fourth aspect, the present application provides a datagram processing device, the device comprising:

[0036] A third acquisition module is used to acquire, through the kernel-state virtual host VHost, a second datagram obtained by the kernel-state protocol stack after processing the first datagram;

[0037] A third cache module is used to cache the second datagram in a shared memory through a kernel-state VHost; the shared memory is open to access rights for both a user state and a kernel state;

[0038] A fourth acquisition module, used for acquiring an address of the second datagram in the shared memory through the VHost in the kernel state;

[0039] A determination module, used to determine, through a kernel-state VHost, a datagram address queue uniquely corresponding to a user-state process for processing a second datagram among a plurality of mutually independent user-state processes in a data plane development kit DPDK in a user state;

[0040] A fourth cache module is used to cache the address in a datagram address queue uniquely corresponding to a determined user state process through a kernel state VHost; different user state processes have different unique datagram address queues, and each user state process has a unique datagram address queue that opens access rights to both the user state and the kernel state;

[0041] A monitoring module, used for monitoring whether an address is added to the datagram address queue through a determined user mode process;

[0042] A third extraction module, configured to extract the address of the second datagram in the shared memory from the datagram address queue by a determined user mode process when an address is added to the datagram address queue;

[0043] A fourth extraction module, configured to extract a second datagram from the shared memory according to the address through a determined user mode process;

[0044] The third sending module is used to send the second datagram to the user-state network card through a determined user-state process.

[0045] In a fifth aspect, the present application illustrates an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the method described in any of the above aspects.

[0046] In a sixth aspect, the present application illustrates a non-temporary computer-readable storage medium, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute a method as described in any of the above aspects.

[0047] In a seventh aspect, the present application illustrates a computer program product. When instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in any of the above aspects.

[0048] The technical solution provided by this application may have the following beneficial effects:

[0049] This application builds a high-performance kernel interaction processing mechanism under DPDK-based multi-process service, and realizes the communication mechanism in multi-process mode. In multi-process mode, there are multiple datagram address queues. Each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and competition-free. The multi-core forwarding mechanism is fully utilized to process data, improve the forwarding processing capability of datagrams between kernel state and user state, and improve product stability and the recursive capability of intranet DNS products. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 It is a schematic diagram of a datagram processing architecture of the present application.

[0051] Figure 2 It is a schematic diagram of a datagram processing architecture of the present application.

[0052] Figure 3 It is a step flow chart of a datagram processing method of the present application.

[0053] Figure 4 It is a step flow chart of a datagram processing method of the present application.

[0054] Figure 5 It is a structural block diagram of a datagram processing device of the present application.

[0055] Figure 6 It is a structural block diagram of a datagram processing device of the present application.

[0056] Figure 7 It is a block diagram of an electronic device of the present application.

[0057] Figure 8 It is a block diagram of an electronic device of the present application. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0059] In KNI mode, after receiving a datagram from the network card, the DPDK-based user-mode program puts the datagram that needs to be forwarded to the kernel for processing into the FIFO shared memory through the FIFO (First Input First Output) shared memory.

[0060] KNI_thread (thread) will be started in kernel state, obtain datagrams from FIFO shared memory, copy the datagrams to kernel state memory, enter the kernel protocol stack for processing, and then send them to the application for processing.

[0061] After the application completes processing, the processed datagram is placed in the FIFO shared memory through the kernel protocol stack and the TAP device.

[0062] The DPDK-based user-mode program polls the FIFO shared memory to process the processed datagrams, and sends the processed datagrams from DPDK and the network card to the network.

[0063] However, the inventors found that the above problem has the following defects:

[0064] KNI only supports single-queue interaction between user state and kernel state. When the amount of data that needs to be interacted between user state and kernel state is large, the efficiency of data interaction is low, resulting in low efficiency of data processing and performance bottlenecks.

[0065] In addition, the log service also uses KNI to communicate with the log server regarding logs. The log-related communications between KNI and the log server will occupy part of NKI's resources, exacerbating the performance issues of KNI for data interaction between user state and kernel state.

[0066] Secondly, the single queue between user state and kernel state supported by KNI is maintained by the master process in user state. When the slave process in user state needs to process data, it needs to interact with the master process and obtain the address of the data from the queue maintained by the master process. This leads to a large amount of interaction between the master process and the slave process in user state, which occupies system resources and aggravates the problem of low data processing efficiency.

[0067] To this end, the solution of this application is proposed.

[0068] Before introducing the solution of the present application, the technical terms that may be involved in the present application are first explained.

[0069] DNS (Domain Name System) is a distributed database on the Internet that maps domain names to IP (Internet Protocol) addresses. It allows users to access the Internet more conveniently without having to remember IP numbers that can be directly read by machines. The process of obtaining the IP address corresponding to a host through a host name is called domain name resolution (or host name resolution). The DNS protocol runs on top of the UDP (User Datagram Protocol) protocol and uses port number 53.

[0070] DPDK is a software library for datagram processing on general-purpose multi-core processors. It can bypass the Linux kernel-mode protocol stack and improve the efficiency of packet processing.

[0071] KNI: Used to process datagrams and send them back to the kernel, eliminating the need to implement all protocols at the DPDK layer.

[0072] IOevent (Input / Ooutput event input / output event) file descriptor (file descriptor) is used to identify the datagram address queue.

[0073] VHost (Virtual Host) is a technology that builds multiple website services with different domain names or based on different IP addresses on the same machine. It can assign different IP (Internet Protocol) addresses and ports to each website running on the same physical machine, and also allow multiple websites to have different domain names.

[0074] BIND9 (Berkeley Internet Name Domain version 9) is the latest version of the BIND (Berkeley Internet Name Domain) series and is a widely used open source DNS server software. It is mainly used to resolve the mapping relationship between domain names and IP addresses and provide domain name resolution services.

[0075] VIRTIO-USER: It was originally introduced with the VIRTIO-USER backend as a high-performance solution for IPC (Inter-Process Communication) and user space container networking. It is a solution proposed by DPDK for specific scenarios. It has two main uses: one is for DPDK application container support for VIRTIO, and the other is for communication with the kernel.

[0076] One of the uses of VIRTIO-USER is to be used as an exception path for communicating with the kernel. DPDK is a kernel-bypassing outsourcing solution, which is why it has high performance. However, sometimes datagrams (such as control messages) received from DPDK need to be sent to the kernel protocol stack for processing. This path is called an exception path in DPDK.

[0077] This technical solution adopts the VIRTIO-USER technology. On this basis, we have established a multi-process VIRTIO-USER forwarding model and built a high-performance kernel interaction processing architecture under DPDK-based multi-process services. The VIRTIO-USER mode in multi-process mode is implemented. In multi-process mode, each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and non-competitive, making full use of the multi-core forwarding system to process data and improve the forwarding processing capabilities of datagrams between kernel state and user state.

[0078] In multi-process mode, when the master user state process (master) starts, the shared memory and the datagram address queues corresponding to each user state process (including the master user state process and each slave user state process) are initialized.

[0079] When the slave user state process is started, the IOevent file descriptor corresponding to the datagram address queue uniquely corresponding to the slave user state process is obtained from the main user state process. When the slave user state process interacts with the kernel state VHost, it interacts with the kernel state VHost through the IOevent file descriptor to realize the sending and receiving of datagrams.

[0080] The solution of this application can be applied to cloud network intranet DNS products, involving intranet DNS network element devices. Currently, intranet DNS implements recursive cache separation function and provides recursive capability through open source BIND9.

[0081] Through this application, the dependency on KNI is also decoupled.

[0082] Reference Figure 1 and Figure 2 , showing a schematic diagram of a datagram processing architecture of the present application.

[0083] The architecture includes the following roles: Network Interface Controller (NIC), DPDK, VHost, Intranet DNS, TAP, protocol stack, and BIND9. Intranet DNS has a master user state process and a slave user state process. Each process corresponds to a Vring queue (such as the datagram address queue mentioned later). Each Vring queue corresponds to an IOevent file descriptor. The interaction between these roles can be seen as shown by the arrows in the figure, which will not be described in detail here.

[0084] VIRTIO PMD (Poll Mode Driver) is a driver mode used in DPDK to handle VIRTIO. VIRTIO PMD implements user-mode configuration and data processing of virtual or physical network cards through the VFIO interface.

[0085] A VHost adapter is a virtualized SCSI (Small Computer System Interface) adapter that allows a virtual machine or client partition to connect to storage or other SCSI devices in a virtualized manner. The VHost adapter plays a key role in providing a bridge between the virtual machine and the physical storage.

[0086] Reference Figure 3 , shows a flow chart of the steps of a datagram processing method of the present application, wherein the method comprises:

[0087] In step S101, for any one of the multiple independent user-state processes in the DPDK in user state, after receiving the first datagram sent by the user-state network card through the user-state process, the first datagram is cached in a shared memory through the user-state process, and the shared memory opens access rights to both the user state and the kernel state.

[0088] After receiving the first datagram, the network card node in the user state forwards the first datagram to the DPDK in the user state. One of the multiple independent user state processes in the DPDK receives the first datagram, and the first datagram is cached in the shared memory through the user state process.

[0089] Both user mode and kernel mode can access shared memory.

[0090] In user mode, DPDK can have an intranet DNS, and the intranet DNS has multiple user mode processes, one of which is the master user mode process and the others are slave user mode processes.

[0091] There is no lock or dependency between user-mode processes, and communication between them can be done using lock-free inter-process communication.

[0092] The main user mode process may be responsible for initializing the driver of the network card and the driver of the TAP device.

[0093] The network card in user mode has multiple network card channels; different network card channels correspond to different datagram address queues.

[0094] In this way, the user-mode network card sends a datagram through a network card channel, and the user-mode process corresponding to the datagram address queue corresponding to the network card channel receives the datagram.

[0095] In step S102, the address of the first datagram in the shared memory is obtained through the user mode process.

[0096] The address of the first datagram in the shared memory may be understood as the offset address of the first datagram in the shared memory.

[0097] In step S103, the user state process caches the address in a datagram address queue uniquely corresponding to the user state process. Different user state processes have different unique datagram address queues, and each unique datagram address queue corresponding to each user state process has access rights to both user state and kernel state.

[0098] The user state process can write data in a datagram address queue uniquely corresponding to the user state process and read data in a datagram address queue uniquely corresponding to the user state process.

[0099] The user-mode process cannot write data in a datagram address queue uniquely corresponding to other user-mode processes, and cannot read data in a datagram address queue uniquely corresponding to other user-mode processes.

[0100] In step S104, the user state process obtains the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue. Different datagram address queues have different uniquely corresponding IOevent file descriptors.

[0101] Among the multiple independent user-state processes in DPDK in user state, one is the master user-state process and the others are slave user-state processes. The master user-state process is responsible for creating a unique IOevent file descriptor for each datagram address queue.

[0102] In one embodiment, the user state process is: a main user state process in the DPDK in the user state and a slave user state process in multiple slave user state processes, and the IOevent file descriptor uniquely corresponding to the datagram address queue is: actively requested from the main user state process through inter-process communication after the slave user state process is started.

[0103] Alternatively, in another embodiment of the present application, the user state is a main user state process in the DPDK in the user state and a main user state process among multiple slave user state processes, and the IOevent file descriptor uniquely corresponding to the datagram address queue is: the main user state process assigned to itself.

[0104] In step S105, the IOevent file descriptor is sent to the virtual host VHost in the kernel state through the user state process.

[0105] In step S106, the IOevent file descriptor is received through the VHost in kernel mode.

[0106] In step S107, the address of the first datagram in the shared memory is extracted from the datagram address queue uniquely corresponding to the IOevent file descriptor by the kernel-mode VHost according to the IOevent file descriptor.

[0107] According to the IOevent file descriptor, the datagram address queue uniquely corresponding to the IOevent file descriptor can be locked, so that the address of the first datagram in the shared memory can be extracted from the datagram address queue uniquely corresponding to the IOevent file descriptor.

[0108] "Extraction" includes: reading the address of the first datagram in the shared memory in the datagram address queue uniquely corresponding to the IOevent file descriptor, and then deleting the address of the first datagram in the shared memory in the datagram address queue uniquely corresponding to the IOevent file descriptor to avoid the read address from constantly occupying storage space.

[0109] In step S108, the first datagram is extracted from the shared memory according to the address by the VHost in kernel mode.

[0110] “Extracting” includes: reading the first datagram in the shared memory according to the address, and then deleting the first datagram in the shared memory according to the address to avoid the first datagram constantly occupying storage space.

[0111] In step S109, the first datagram is sent to the kernel-state protocol stack for processing via the kernel-state VHost.

[0112] After the kernel-state VHost sends the first datagram to the kernel-state protocol stack for processing through the TAP device, the second datagram can be obtained.

[0113] In one example, the first datagram is dispatched to BIND9 for processing via a kernel-mode protocol stack to obtain a second datagram.

[0114] The process of processing the second datagram can be referred to as follows. Figure 2 The illustrated embodiment will not be described in detail here.

[0115] In one embodiment of the present application, there are multiple kernel-state processes in the kernel-state VHost, and each kernel-state process uniquely corresponds to a different user-state process, that is, the kernel-state process corresponds to the user-state process one-to-one. In this way, each kernel-state process also uniquely corresponds to a different IOevent file descriptor.

[0116] In step S107, when extracting the address of the first datagram in the shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor through the kernel state VHost, the kernel state VHost can determine the kernel state process uniquely corresponding to the IOevent file descriptor among multiple kernel state processes in the kernel state VHost. The IOevent file descriptor is dispatched to the determined kernel state process. The address of the first datagram in the shared memory is extracted from the datagram address queue uniquely corresponding to the IOevent file descriptor through the determined kernel state process according to the IOevent file descriptor.

[0117] Accordingly, in step S108, when the first datagram is extracted from the shared memory according to the address by the kernel-state VHost, the first datagram is extracted from the shared memory according to the address by the determined kernel-state process.

[0118] Accordingly, when the first datagram is sent to the kernel-state protocol stack for processing through the kernel-state VHost in step S109, the first datagram is sent to the kernel-state protocol stack for processing through the determined kernel-state process.

[0119] This application builds a high-performance kernel interaction processing mechanism under DPDK-based multi-process service, and realizes the communication mechanism in multi-process mode. In multi-process mode, there are multiple datagram address queues. Each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and competition-free. The multi-core forwarding mechanism is fully utilized to process data, improve the forwarding processing capability of datagrams between kernel state and user state, and improve product stability and the recursive capability of intranet DNS products.

[0120] Reference Figure 4 , shows a flow chart of the steps of a datagram processing method of the present application, wherein the method comprises:

[0121] In step S201, a second datagram obtained by processing a first datagram by a kernel-state protocol stack is obtained through a kernel-state VHost.

[0122] After the kernel-mode protocol stack completes processing of the first datagram and obtains the second datagram, the second datagram can be sent to the VHost through the TAP device, and the second datagram sent through the TAP device can be received by the Vhost.

[0123] In step S202, the second datagram is cached in a shared memory through the VHost in the kernel state. The shared memory has access rights open to both the user state and the kernel state.

[0124] In step S203, the address of the second datagram in the shared memory is obtained through the VHost in kernel state.

[0125] The address of the second datagram in the shared memory may be understood as the offset address of the second datagram in the shared memory.

[0126] In step S204, a datagram address queue uniquely corresponding to the user-state process for processing the second datagram is determined in a plurality of mutually independent user-state processes in the DPDK in the user state through the VHost in the kernel state.

[0127] In one embodiment of the present application, a kernel-state VHost has multiple kernel-state processes, each kernel-state process uniquely corresponds to a different user-state process, and each kernel-state process uniquely corresponds to a different IOevent file descriptor.

[0128] The second datagram obtained by the kernel-state protocol stack after processing the first datagram is obtained by a kernel-state process among multiple kernel-state processes in the kernel-state VHost. The second datagram is cached in the shared memory by the kernel-state process, and the address of the second datagram in the shared memory is obtained by the kernel-state process.

[0129] In this way, when determining, through the kernel-state VHost, a datagram address queue uniquely corresponding to the user-state process for processing the second datagram among multiple independent user-state processes in the data plane development kit DPDK in user state, it is possible to determine, through the one kernel-state process, a datagram address queue uniquely corresponding to the user-state process uniquely corresponding to the one kernel-state process among multiple independent user-state processes in the DPDK in user state.

[0130] For example, through the kernel state process, according to the IOevent file descriptor received in advance by the kernel state process, a datagram address queue uniquely corresponding to the user state process uniquely corresponding to the kernel state process is determined in multiple independent user state processes in the DPDK in user state. The IOevent file descriptor is sent in advance by the user state process uniquely corresponding to the kernel state process to the kernel state process.

[0131] In step S205, the kernel-mode VHost caches the address in a datagram address queue uniquely corresponding to a determined user-mode process. Different user-mode processes have different unique datagram address queues, and each unique datagram address queue of each user-mode process has access rights to both user-mode and kernel-mode.

[0132] In step S206, the determined user mode process monitors whether an address is added to the datagram address queue.

[0133] In step S207, when an address is added to the datagram address queue, the address of the second datagram in the shared memory is extracted from the datagram address queue by a determined user mode process.

[0134] “Extracting” includes: reading the address of the second datagram in the shared memory in the datagram address queue, and then deleting the address of the second datagram in the shared memory in the datagram address queue to avoid the read address from constantly occupying storage space.

[0135] In step S208, the second datagram is extracted from the shared memory according to the address by the determined user mode process.

[0136] “Extracting” includes: reading the second datagram in the shared memory according to the address, and then deleting the second datagram in the shared memory according to the address to avoid the second datagram constantly occupying storage space.

[0137] In step S209, the second datagram is sent to the user-mode network card through the determined user-mode process.

[0138] This application builds a high-performance kernel interaction processing mechanism under DPDK-based multi-process service, and realizes the communication mechanism in multi-process mode. In multi-process mode, there are multiple datagram address queues. Each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and competition-free. The multi-core forwarding mechanism is fully utilized to process data, improve the forwarding processing capability of datagrams between kernel state and user state, and improve product stability and the recursive capability of intranet DNS products.

[0139] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions involved are not necessarily required by the present application.

[0140] Reference Figure 5 , shows a datagram processing device of the present application, the device comprising:

[0141] A first cache module 11 is used for caching, for any one of a plurality of mutually independent user-state processes in a data plane development kit DPDK in a user state, the first datagram sent by a user-state network card, in a shared memory through the user-state process after the user-state process receives the first datagram, and the shared memory is open to access rights for both the user state and the kernel state;

[0142] A first acquisition module 12, used to acquire the address of the first datagram in the shared memory through the user state process;

[0143] The second cache module 13 is used to cache the address in a datagram address queue uniquely corresponding to the user state process through the user state process; different user state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user state process are open to access rights for both user state and kernel state;

[0144] The second acquisition module 14 is used to acquire the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue through the user state process; different datagram address queues have different uniquely corresponding IOevent file descriptors;

[0145] A first sending module 15, configured to send the IOevent file descriptor to the virtual host VHost in kernel state through the user state process;

[0146] A receiving module 16, configured to receive the IOevent file descriptor via a VHost in kernel mode;

[0147] A first extraction module 17 is used to extract the address of the first datagram in the shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor through the kernel-state VHost according to the IOevent file descriptor;

[0148] A second extraction module 18, configured to extract the first datagram from the shared memory according to the address through the VHost in the kernel state;

[0149] The second sending module 19 is used to send the first datagram to the kernel state protocol stack for processing through the kernel state VHost.

[0150] Among them, the user state process is: a main user state process in the DPDK in the user state and a slave user state process in multiple slave user state processes, and the IOevent file descriptor uniquely corresponding to the datagram address queue is: actively applied from the main user state process through inter-process communication after the slave user state process is started.

[0151] Among them, the kernel-state VHost has multiple kernel-state processes, each kernel-state process uniquely corresponds to a different user-state process, and each kernel-state process uniquely corresponds to a different IOevent file descriptor;

[0152] The first extraction module comprises:

[0153] A first determining unit is used to determine, through a kernel-state VHost, a kernel-state process uniquely corresponding to the IOevent file descriptor from among a plurality of kernel-state processes in the kernel-state VHost;

[0154] A scheduling unit, used for scheduling the IOevent file descriptor to a determined kernel state process;

[0155] A first extraction unit, configured to extract, through a determined kernel state process, an address of a first datagram in a shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor;

[0156] Accordingly, the second extraction module includes:

[0157] A second extraction unit, configured to extract the first datagram from the shared memory according to the address through a determined kernel state process;

[0158] Accordingly, the second sending module includes:

[0159] The sending unit is used to send the first datagram to the kernel state protocol stack for processing through the determined kernel state process.

[0160] This application builds a high-performance kernel interaction processing mechanism under DPDK-based multi-process service, and realizes the communication mechanism in multi-process mode. In multi-process mode, there are multiple datagram address queues. Each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and competition-free. The multi-core forwarding mechanism is fully utilized to process data, improve the forwarding processing capability of datagrams between kernel state and user state, and improve product stability and the recursive capability of intranet DNS products.

[0161] Reference Figure 6 , shows a datagram processing device of the present application, the device comprising:

[0162] A third acquisition module 21 is used to acquire, through the virtual host VHost in the kernel state, a second datagram obtained by the protocol stack in the kernel state after processing the first datagram;

[0163] A third cache module 22 is used to cache the second datagram in a shared memory through a kernel-state VHost; the shared memory is open to access rights for both user state and kernel state;

[0164] A fourth acquisition module 23, used for acquiring the address of the second datagram in the shared memory through the VHost in the kernel state;

[0165] A determination module 24 is used to determine, through the kernel state VHost, a datagram address queue uniquely corresponding to the user state process for processing the second datagram from multiple independent user state processes in the data plane development kit DPDK in the user state;

[0166] A fourth cache module 25 is used to cache the address in a datagram address queue uniquely corresponding to a determined user state process through a kernel state VHost; different user state processes have different unique datagram address queues, and each user state process has a unique datagram address queue that opens access rights to both the user state and the kernel state;

[0167] A monitoring module 26, configured to monitor whether an address is added to the datagram address queue through a determined user mode process;

[0168] A third extraction module 27 is used to extract the address of the second datagram in the shared memory from the datagram address queue through a determined user mode process when an address is added to the datagram address queue;

[0169] A fourth extraction module 28, configured to extract the second datagram from the shared memory according to the address through a determined user mode process;

[0170] The third sending module 29 is used to send the second datagram to the user-mode network card through the determined user-mode process.

[0171] Among them, the kernel-state VHost has multiple kernel-state processes, each kernel-state process uniquely corresponds to a different user-state process, and each kernel-state process uniquely corresponds to a different IOevent file descriptor;

[0172] The second datagram obtained after the kernel-state protocol stack processes the first datagram is obtained by a kernel-state process among multiple kernel-state processes in the kernel-state VHost; the second datagram is cached in the shared memory by the kernel-state process, and the address of the second datagram in the shared memory is obtained by the kernel-state process;

[0173] The determination module comprises:

[0174] The second determining unit is used to determine, through the one kernel state process, a datagram address queue uniquely corresponding to a user state process uniquely corresponding to the one kernel state process among multiple independent user state processes in the DPDK in the user state.

[0175] Wherein, the second determining unit includes:

[0176] A determination subunit is used to determine, through the one kernel state process, a datagram address queue uniquely corresponding to a user state process uniquely corresponding to the one kernel state process among multiple independent user state processes in the DPDK in user state according to an IOevent file descriptor received in advance by the one kernel state process; the IOevent file descriptor is sent in advance to the one kernel state process by the user state process uniquely corresponding to the one kernel state process.

[0177] This application builds a high-performance kernel interaction processing mechanism under DPDK-based multi-process service, and realizes the communication mechanism in multi-process mode. In multi-process mode, there are multiple datagram address queues. Each process communicates with the kernel-state VHost through its unique corresponding datagram address queue. Resource access between processes is lock-free and competition-free. The multi-core forwarding mechanism is fully utilized to process data, improve the forwarding processing capability of datagrams between kernel state and user state, and improve product stability and the recursive capability of intranet DNS products.

[0178] Optionally, an embodiment of the present application further provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.

[0179] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0180] Figure 7 800 is a block diagram of an electronic device 800 shown in the present application. For example, the electronic device 800 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0181] Reference Figure 7 , the electronic device 800 may include one or more of the following components: a processing component 802 , a memory 804 , a power component 806 , a multimedia component 808 , an audio component 810 , an input / output (I / O) interface 812 , a sensor component 814 , and a communication component 816 .

[0182] The processing component 802 generally controls the overall operation of the electronic device 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0183] The memory 804 is configured to store various types of data to support operations on the device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phone book data, messages, images, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0184] The power supply component 806 provides power to the various components of the electronic device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 800.

[0185] The multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also monitor the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0186] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC), and when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 804 or sent via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting audio signals.

[0187] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0188] The sensor assembly 814 includes one or more sensors for providing various aspects of status assessment for the electronic device 800. For example, the sensor assembly 814 can monitor the open / closed state of the device 800, the relative positioning of the components, such as the display and keypad of the electronic device 800, and the sensor assembly 814 can also monitor the position change of the electronic device 800 or a component of the electronic device 800, the presence or absence of contact between the user and the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and the temperature change of the electronic device 800. The sensor assembly 814 may include a proximity sensor configured to monitor the presence of nearby objects without any physical contact. The sensor assembly 814 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0189] The communication component 816 is configured to facilitate wired or wireless communication between the electronic device 800 and other devices. The electronic device 800 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast operation information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0190] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0191] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the instructions can be executed by a processor 820 of an electronic device 800 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0192] Figure 81 is a block diagram of an electronic device 1900 shown in the present application. For example, the electronic device 1900 may be provided as a server.

[0193] Reference Figure 8 , the electronic device 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions executable by the processing component 1922, such as an application. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0194] The electronic device 1900 may also include a power supply component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input / output (I / O) interface 1958. The electronic device 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

[0195] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0196] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0197] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

[0198] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0199] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0200] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0201] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0202] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0203] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0204] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A datagram processing method, characterized in that: The method comprises: For any one of the multiple independent user state processes in the data plane development kit DPDK in the user state, after receiving a first datagram sent by the user state network card through the user state process, the first datagram is cached in a shared memory through the user state process, and the shared memory is open to access rights for both the user state and the kernel state; Acquire the address of the first datagram in the shared memory through the user state process; The address is cached in a datagram address queue uniquely corresponding to the user state process by the user state process; different user state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user state process are open to access rights for both user state and kernel state; Acquire the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue through the user state process; different datagram address queues have different uniquely corresponding IOevent file descriptors; Sending the IOevent file descriptor to the virtual host VHost in kernel state through the user state process; Receiving the IOevent file descriptor through the VHost in kernel mode; Extracting, by the kernel-state VHost, the address of the first datagram in the shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor; Extracting the first datagram from the shared memory according to the address by the VHost in kernel mode; The first datagram is sent to the kernel-state protocol stack for processing through the kernel-state VHost.

2. The method according to claim 1, characterized in that The user state process is: a main user state process in the DPDK in the user state and a slave user state process in multiple slave user state processes, and the IOevent file descriptor uniquely corresponding to the datagram address queue is: actively requested from the main user state process through inter-process communication after the slave user state process is started.

3. The method according to claim 1, characterized in that There are multiple kernel-state processes in the kernel-state VHost, each kernel-state process uniquely corresponds to a different user-state process, and each kernel-state process uniquely corresponds to a different IOevent file descriptor; The extracting, by the kernel-mode VHost according to the IOevent file descriptor, the address of the first datagram in the shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor comprises: Determine, through the kernel-state VHost, a kernel-state process uniquely corresponding to the IOevent file descriptor from among multiple kernel-state processes in the kernel-state VHost; Dispatching the IOevent file descriptor to a determined kernel state process; Extracting, by a determined kernel state process, an address of a first datagram in a shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor; Correspondingly, extracting the first datagram from the shared memory according to the address through the VHost in the kernel state includes: Extracting a first datagram from the shared memory according to the address through a determined kernel state process; Accordingly, the sending of the first datagram to the kernel-state protocol stack for processing through the kernel-state VHost includes: The first datagram is sent to the kernel-state protocol stack for processing through the determined kernel-state process.

4. A datagram processing method, characterized in that: The method comprises: Obtaining, through the kernel-state virtual host VHost, a second datagram obtained by the kernel-state protocol stack after processing the first datagram; The second datagram is cached in the shared memory through the kernel-state VHost; the shared memory is accessible to both the user-state and the kernel-state; Obtain the address of the second datagram in the shared memory through the kernel-mode VHost; Determine, through the kernel-state VHost, a datagram address queue uniquely corresponding to the user-state process for processing the second datagram in a plurality of mutually independent user-state processes in a data plane development kit DPDK in the user state; The address is cached in a datagram address queue uniquely corresponding to a determined user-state process through the kernel-state VHost; different user-state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user-state process are open to access rights for both the user-state and kernel-state processes; Monitoring whether an address is added to the datagram address queue by a determined user mode process; In a case where an address is added to the datagram address queue, extracting the address of the second datagram in the shared memory from the datagram address queue through a determined user mode process; extracting a second datagram from the shared memory according to the address by a determined user mode process; The second datagram is sent to the user-mode network card through the determined user-mode process.

5. The method according to claim 4, characterized in that There are multiple kernel-state processes in the kernel-state VHost, each kernel-state process uniquely corresponds to a different user-state process, and each kernel-state process uniquely corresponds to a different IOevent file descriptor; The second datagram obtained after the kernel-state protocol stack processes the first datagram is obtained by a kernel-state process among multiple kernel-state processes in the kernel-state VHost; the second datagram is cached in the shared memory by the kernel-state process, and the address of the second datagram in the shared memory is obtained by the kernel-state process; The method of determining, through the kernel-state VHost, a datagram address queue uniquely corresponding to the user-state process for processing the second datagram in a plurality of mutually independent user-state processes in the DPDK in the user-state, comprises: Through the one kernel state process, a datagram address queue uniquely corresponding to a user state process uniquely corresponding to the one kernel state process is determined among a plurality of mutually independent user state processes in the DPDK in the user state.

6. The method according to claim 5, characterized in that The step of determining, through the one kernel state process, a datagram address queue uniquely corresponding to a user state process uniquely corresponding to the one kernel state process from a plurality of mutually independent user state processes in the DPDK in the user state comprises: Through the one kernel state process, according to the IOevent file descriptor received in advance by the one kernel state process, a datagram address queue uniquely corresponding to the user state process uniquely corresponding to the one kernel state process is determined among multiple independent user state processes in the DPDK in user state; the IOevent file descriptor is sent in advance to the one kernel state process by the user state process uniquely corresponding to the one kernel state process.

7. A datagram processing device, characterized in that: The device comprises: A first cache module is used for caching, for any one of a plurality of mutually independent user-state processes in a data plane development kit DPDK in a user state, the first datagram sent by a user-state network card after being received by the user-state process, the first datagram in a shared memory through the user-state process, and the shared memory is open to access rights for both the user state and the kernel state; A first acquisition module, used for acquiring an address of a first datagram in a shared memory through the user state process; A second cache module is used to cache the address in a datagram address queue uniquely corresponding to the user state process through the user state process; different user state processes have different unique datagram address queues, and the datagram address queues uniquely corresponding to each user state process are open to access rights for both user state and kernel state; A second acquisition module is used to acquire the read / write event IOevent file descriptor uniquely corresponding to the datagram address queue through the user state process; different datagram address queues have different uniquely corresponding IOevent file descriptors; A first sending module, used for sending the IOevent file descriptor to the virtual host VHost in kernel state through the user state process; A receiving module, used for receiving the IOevent file descriptor through a VHost in kernel mode; A first extraction module, configured to extract, through a kernel-state VHost, an address of a first datagram in a shared memory from the datagram address queue uniquely corresponding to the IOevent file descriptor according to the IOevent file descriptor; A second extraction module, used for extracting the first datagram in the shared memory according to the address through the VHost in the kernel state; The second sending module is used to send the first datagram to the kernel state protocol stack for processing through the kernel state VHost.

8. A datagram processing device, characterized in that: The device comprises: A third acquisition module is used to acquire, through the kernel-state virtual host VHost, a second datagram obtained by the kernel-state protocol stack after processing the first datagram; A third cache module is used to cache the second datagram in a shared memory through a kernel-state VHost; the shared memory is open to access rights for both a user state and a kernel state; A fourth acquisition module, used for acquiring an address of the second datagram in the shared memory through the VHost in the kernel state; A determination module, used to determine, through a kernel-state VHost, a datagram address queue uniquely corresponding to a user-state process for processing a second datagram among a plurality of mutually independent user-state processes in a data plane development kit DPDK in a user state; A fourth cache module is used to cache the address in a datagram address queue uniquely corresponding to a determined user state process through a kernel state VHost; different user state processes have different unique datagram address queues, and each user state process has a unique datagram address queue that opens access rights to both the user state and the kernel state; A monitoring module, used for monitoring whether an address is added to the datagram address queue through a determined user mode process; A third extraction module, configured to extract the address of the second datagram in the shared memory from the datagram address queue by a determined user mode process when an address is added to the datagram address queue; A fourth extraction module, configured to extract a second datagram from the shared memory according to the address through a determined user mode process; The third sending module is used to send the second datagram to the user-state network card through a determined user-state process.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the datagram processing method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the datagram processing method according to any one of claims 1 to 6 is implemented.

Images