Intra-server delay control device, intra-server delay control method and program

Abstract

An intra-server delay control device (200) comprises: a data arrival notification unit (220) that gives notification of and transfers data acquired by a data arrival monitoring unit (210) to a data processing APL (1); and a sleep management unit (230) that makes a polling thread go to sleep but wakes the polling thread up by hardware interrupt when a packet has arrived. The sleep management unit (230) allows hardware interrupts and controls sleep timing on the basis of the characteristics of an application program.

Description

[Technical field]

[0001] The present invention relates to an intra-server delay control device, an intra-server delay control method, and a program. [Background technology]

[0002] With the advancement of virtualization technology such as NFV (Network Functions Virtualization), systems are being built and operated for each service.In addition, a form called Service Function Chaining (SFC) is becoming mainstream, in which service functions are divided into reusable modules and run on independent virtual machine (VM: Virtual Machine, container, etc.) environments, allowing them to be used as components when needed and improving operability, as opposed to the form in which systems are built for each service.

[0003] A known technology for configuring virtual machines is a hypervisor environment consisting of Linux (registered trademark) and KVM (kernel-based virtual machine). In this environment, a Host OS (an OS installed on a physical server is called a Host OS) with a built-in KVM module operates as a hypervisor in a memory area called kernel space, which is different from the user space. In this environment, a virtual machine operates in the user space, and a Guest OS (an OS installed on a virtual machine is called a Guest OS) operates within the virtual machine.

[0004] A virtual machine running a Guest OS is different from a physical server running a Host OS in that all HW (hardware), including network devices (typified by Ethernet (registered trademark) card devices, is subject to register control required for interrupt processing from the HW to the Guest OS and writing from the Guest OS to the hardware. In this type of register control, notifications and processing that should be executed by physical hardware are simulated by software, so performance is generally lower than in a Host OS environment.

[0005] To address this performance degradation, there is a technology that reduces HW emulation, particularly from the Guest OS to the Host OS and external processes that exist outside the virtual machine, and improves communication performance and versatility through a high-speed, unified interface. One such technology is a device abstraction technology called Virtio, or paravirtualization technology, which has already been incorporated into many general-purpose operating systems, including Linux (registered trademark) and FreeBSD (registered trademark), and is currently in use.

[0006] Virtio defines data exchange by queues designed with ring buffers as a one-way transport for data input / output such as console, file input / output, and network communication, through queue operations. By using the Virtio queue specifications to prepare the number and size of queues appropriate for each device when the Guest OS starts, communication between the Guest OS and the outside of the virtual machine can be achieved using only queue operations without performing hardware emulation.

[0007] Data transfer technologies within a server include New API (NAPI), DPDK (Data Plane Development Kit), and KBP (Kernel Busy Poll).

[0008] When a packet arrives, the New API (NAPI) processes the packet by a hardware interrupt request and then a software interrupt request (see Non-Patent Document 1) (see FIG. 19 described later).

[0009] DPDK realizes packet processing function in user space where application runs, and immediately harvests packets when they arrive from user space using polling model. In detail, DPDK is a framework for controlling NIC (Network Interface Card) in user space, which was previously done by Linux kernel (registered trademark). The biggest difference with the processing in Linux kernel is that it has a polling-based reception mechanism called PMD (Pull Mode Driver). Normally, in Linux kernel, an interrupt occurs when data arrives at NIC, and reception processing is executed as a result. On the other hand, PMD has a dedicated thread that continuously checks data arrival and performs reception processing. PMD can perform high-speed packet processing by eliminating overhead such as context switching and interrupts. DPDK significantly improves the performance and throughput of packet processing, making it possible to secure more time for data plane application processing. However, DPDK exclusively uses computer resources such as CPU (Central Processing Unit) and NIC.

[0010] Patent Document 1 describes a network delay control device in a server (KBP: Kernel Busy Poll). KBP constantly monitors packet arrivals using a polling model in the kernel. This suppresses softIRQ and achieves low-latency packet processing.

[0011] [Rx side packet processing using New API (NAPI)] FIG. 19 is a schematic diagram of Rx-side packet processing by New API (NAPI) implemented in Linux kernel 2.5 / 2.6 and later (see Non-Patent Document 1). As shown in FIG. 19, the New API (NAPI) executes a data processing APL1 placed in a user space 60 available to a user on a server having an OS70 (e.g., a Host OS), and transfers packets between the NIC 11 of the HW 10 connected to the OS70 and the data processing APL1.

[0012] The OS 70 includes a kernel 71 , a ring buffer 72 , and a driver 73 , and the kernel 71 includes a protocol processing unit 74 . Kernel 71 is a core function of OS 70 (for example, a host OS), and monitors hardware and manages the execution status of programs on a process-by-process basis. Here, kernel 71 responds to requests from data processing APL1, and also conveys requests from HW 10 to data processing APL1. Kernel 71 processes requests from data processing APL1 via a system call (a "user program running in non-privileged mode" requests processing from the "kernel running in privileged mode"). The Kernel 71 transmits a packet to the data processing APL1 via the Socket 75. The Kernel 71 receives a packet from the data processing APL1 via the Socket 75.

[0013] The ring buffer 72 is located in the memory space of the server and is managed by the Kernel 71. The ring buffer 72 is a buffer of a certain size that stores messages output by the Kernel 71 as logs, and when the upper limit size is exceeded, the messages are overwritten from the top.

[0014] Driver73 is a device driver that monitors hardware with kernel71. Driver73 depends on kernel71, and if the created (built) kernel source changes, it will become a different driver. In this case, you will need to obtain the driver source, rebuild it on the OS that uses the driver, and create the driver.

[0015] The protocol processing unit 74 performs protocol processing of L2 (data link layer), L3 (network layer), and L4 (transport layer) defined by the OSI (Open Systems Interconnection) reference model.

[0016] Socket75 is an interface that kernel71 uses for inter-process communication. Socket75 has a socket buffer and does not require frequent data copying. The process for establishing communication via Socket75 is as follows: 1. The server creates a socket file that accepts clients. 2. The acceptance socket file is named. 3. A socket queue is created. 4. The first connection from a client in the socket queue is accepted. 5. A socket file is created on the client side. 6. The client issues a connection request to the server. 7. On the server side, a connection socket file is created in addition to the acceptance socket file. As a result of establishing communication, data processing APL1 becomes able to call system calls such as read() and write() on kernel71.

[0017] In the above configuration, the Kernel 71 receives notification of the arrival of a packet from the NIC 11 via a hardware interrupt (hardIRQ), and schedules a software interrupt (softIRQ) for packet processing. The New API (NAPI) implemented in Linux kernel 2.5 / 2.6 above processes packets by a hardware interrupt (hardIRQ) and then a software interrupt (softIRQ) when a packet arrives. As shown in Figure 19, packet transfer using the interrupt model transfers packets using interrupt processing (see symbol a in Figure 19), which creates a wait for the interrupt processing and increases the delay in packet transfer.

[0018] The following provides an overview of packet processing on the NAPI Rx side. [Rx side packet processing configuration using New API (NAPI)] FIG. 20 is a diagram for explaining an outline of Rx-side packet processing by New API (NAPI) in the area surrounded by the dashed line in FIG. <Device driver> As shown in Figure 20, the device driver includes NIC11 (physical NIC), which is a network interface card, hardIRQ81, which is a handler that is called when a processing request is made to NIC11 and executes the requested processing (hardware interrupt), and netif_rx82, which is a processing function for software interrupts.

[0019] <Networking layer> In the networking layer, there are disposed softIRQ 83, which is a handler that is called when a processing request from netif_rx 82 occurs and executes the requested processing (software interrupt), and do_softirq 84, which is a control function unit that executes the software interrupt (softIRQ).In addition, there are disposed net_rx_action 85, which is a packet processing function unit that receives and executes a software interrupt (softIRQ), poll_list 86, which registers information on the net device (net_device) that indicates which device the hardware interrupt from the NIC 11 is from, netif_receive_skb 87, which creates an sk_buff structure (a structure that enables the Kernel 71 to recognize the state of the packet), and the Ring Buffer 72.

[0020] <Protocol layer> In the protocol layer, packet processing functional units such as ip_rcv88 and arp_rcv89 are arranged.

[0021] The above netif_rx82, do_softirq84, net_rx_action85, netif_receive_skb87, ip_rcv88, and arp_rcv89 are program components (function names) used for packet processing in Kernel71.

[0022] [Rx side packet processing operation using New API (NAPI)] The arrows (symbols) b to m in FIG. 20 indicate the flow of packet processing on the Rx side. When the hardware function unit 11a of the NIC 11 (hereinafter referred to as NIC 11) receives a packet (or a frame) in a frame from the other device, it copies the arriving packet to the Ring Buffer 72 by DMA (Direct Memory Access) transfer without using the CPU (see symbol b in FIG. 20). This Ring Buffer 72 is a memory space in the server, and is managed by the Kernel 71 (see FIG. 19).

[0023] However, if the NIC 11 simply copies an arriving packet to the Ring Buffer 72, the Kernel 71 cannot recognize the packet. Therefore, when a packet arrives, the NIC 11 raises a hardware interrupt (hardIRQ) to hardIRQ 81 (see symbol c in FIG. 20), and netif_rx 82 executes the following process, which allows the Kernel 71 to recognize the packet. Note that hardIRQ 81, enclosed in an oval in FIG. 20, indicates a handler rather than a functional unit.

[0024] Netif_rx82 is the function that actually performs the processing. When hardIRQ81 (handler) is started (see symbol d in FIG. 20), it saves the net device (net_device) information, which is one of the pieces of information about the contents of the hardware interrupt (hardIRQ), in poll_list86, indicating which device the hardware interrupt from NIC11 is from. Then, netif_rx82 registers the pruning of the queue. Here, pruning of the queue means referring to the contents of the packets stored in the buffer, and deleting the corresponding queue entry from the buffer, taking into consideration the next processing to be performed on the packet. Specifically, when a packet is stuffed into the Ring Buffer72, netif_rx82 uses the driver of NIC11 to register the subsequent pruning of the queue in poll_list86 (see symbol e in FIG. 20). As a result, the queue pruning information resulting from the packing of packets into the Ring Buffer72 is registered in poll_list86.

[0025] In this way, in Fig. 20<Device driver> In the above, when the NIC 11 receives a packet, it copies the packet that has arrived by DMA transfer to the Ring Buffer 72. In addition, the NIC 11 starts up the hardIRQ 81 (handler), and the netif_rx 82 registers the net_device in the poll_list 86 and schedules a software interrupt (softIRQ). So far, we have completed the steps in Figure 20.<Device driver> Processing of hardware interrupts in stops.

[0026] Thereafter, netif_rx82 uses the information (specifically, the pointer) in the queue stored in poll_list86 to notify softIRQ83 (handler) of the harvesting of the data stored in Ring Buffer72 via a software interrupt (softIRQ) (see symbol f in Figure 20), and notifies do_softirq84, which is the software interrupt control function unit (see symbol g in Figure 20).

[0027] do_softirq84 is a software interrupt control function section, which defines each function of software interrupt (there are various packet processes, and interrupt processing is one of them. This defines interrupt processing). Based on this definition, do_softirq84 notifies net_rx_action85, which actually processes the software interrupt, of the current (corresponding) software interrupt request (see symbol h in Figure 20).

[0028] When the turn of the softIRQ comes, net_rx_action 85 calls a polling routine for reaping packets from Ring Buffer 72 based on net_device registered in poll_list 86 (see symbol i in FIG. 20), and reaps the packets (see symbol j in FIG. 20). At this time, net_rx_action 85 continues reaping until poll_list 86 becomes empty. Thereafter, net_rx_action 85 notifies netif_receive_skb 87 (see symbol k in FIG. 20).

[0029] The netif_receive_skb 87 creates an sk_buff structure, analyzes the contents of the packet, and passes the processing to the downstream protocol processor 74 (see FIG. 19) for each type. That is, the netif_receive_skb 87 analyzes the contents of the packet, and when processing is to be performed according to the contents of the packet,<Protocol layer> If it is L2, the process is passed to arp_rcv 89 (symbol m in FIG. 20).

[0030] Fig. 21 shows an example of video (30 FPS) data transfer. The workload shown in Fig. 21 has a transfer rate of 350 Mbps, and data is transferred intermittently every 30 ms.

[0031] FIG. 22 is a diagram showing the CPU utilization rate used by the busy poll thread in the KBP described in Patent Document 1. In FIG. As shown in Fig. 22, in KBP, the kernel thread occupies a CPU core to perform busy poll. Even in the case of intermittent packet reception as shown in Fig. 21, KBP has a problem of high power consumption because the CPU is always used regardless of whether packets arrive or not.

[0032] Next, we will explain the DPDK system. [DPDK system configuration] FIG. 23 is a diagram showing a configuration of a DPDK system that controls the HW 110 including the accelerator 120. The DPDK system includes HW 110, OS 140, DPDK 150, which is high-speed data transfer middleware arranged on user space 160, and data processing APL 1. The data processing APL1 is a packet processing carried out prior to the execution of the APL. The HW 110 communicates with the data processing APL 1 for transmitting and receiving data. In the following description, as shown in Fig. 23, a data flow in which the data processing APL 1 receives a packet from the HW 110 is referred to as Rx side reception, and a data flow in which the data processing APL 1 transmits a packet to the HW 110 is referred to as Tx side transmission.

[0033] The HW 110 includes an accelerator 120 and a NIC 130 (physical NIC) for connecting to a communication network. The accelerator 120 is a calculation unit hardware that performs a specific calculation at high speed based on an input from a CPU. Specifically, the accelerator 120 is a PLD (Programmable Logic Device) such as a GPU (Graphics Processing Unit) or an FPGA (Field Programmable Gate Array). In Fig. 23, the accelerator 120 includes a plurality of Cores (Core processors) 121, an Rx queue (queue) 122 that holds data in a first-in-first-out list structure, and a Tx queue 123.

[0034] A part of the processing of the data processing APL1 is offloaded to the accelerator 120, thereby achieving performance and power efficiency that cannot be achieved by software (CPU processing) alone. It is assumed that the accelerator 120 described above will be applied to a large-scale server cluster such as a data center that implements NFV (Network Functions Virtualization) or SDN (Software Defined Network).

[0035] The NIC 130 is NIC hardware that realizes a NW interface, and includes an Rx queue 131 and a Tx queue 132 that hold data in a first-in, first-out list structure. The NIC 130 is connected to an opposing device 170 via, for example, a communication network, and transmits and receives packets. The NIC 130 may be, for example, a SmartNIC, which is a NIC with an accelerator. The SmartNIC is a NIC that can offload load-intensive processing, such as IP packet processing that reduces processing power, to reduce the load on the CPU.

[0036] DPDK150 is a framework for controlling NIC in user space160, and specifically consists of high-speed data transfer middleware. DPDK150 has PMD (Poll Mode Driver) 151, a polling-based reception mechanism (a driver that can select polling mode or interrupt mode for data arrival). PMD151 has a dedicated thread that continuously checks for data arrival and performs reception processing.

[0037] DPDK150 realizes packet processing function in user space160 where APL runs, and makes it possible to reduce packet transfer delay by immediately reaping packets when they arrive from user space160 using a polling model. In other words, DPDK150 harvests packets by polling (busy polling the queue in the CPU), so there is no waiting and delay is small.

[0038] Patent Document 1 describes a network delay control device in a server (KBP: Kernel Busy Poll). KBP constantly monitors packet arrivals using a polling model in the kernel. This suppresses softIRQ and achieves low-latency packet processing.

[0039] Incidentally, both packet transfer using the interrupt model and the polling model have the following problems. In the interrupt model, packets are transferred by software interrupt processing, which allows the kernel to process packets after receiving an event (hardware interrupt) from HW. Because the interrupt model transfers packets by interrupt (software interrupt) processing, there are issues with conflicts with other interrupts and waiting when the interrupt destination CPU is used by a higher priority process, resulting in large delays in packet transfer. In this case, if the interrupt processing becomes congested, the waiting delays will become even larger. For example, in packet transfer based on the interrupt model, packets are transferred by interrupt processing, so that waiting for the interrupt processing occurs, resulting in a large delay in packet transfer.

[0040] The mechanism by which delay occurs in the interrupt model will be explained below. In a typical kernel, packet transfer processing is performed by hardware interrupt processing and then software interrupt processing. When a software interrupt occurs in packet forwarding processing, the software interrupt processing cannot be executed immediately under the following conditions (1) to (3). Therefore, the software interrupt processing is scheduled by arbitration using a scheduler such as ksoftirqd (a kernel thread for each CPU that is executed when the load of the software interrupt becomes high), resulting in a wait on the order of ms. (1) When there is a conflict with other hardware interrupt processing (2) When there is a conflict with other software interrupt processing (3) When other high-priority processes, kernel threads (migration threads, etc.), or interrupt destination CPUs are in use Under the above conditions, the software interrupt process cannot be executed immediately. [Prior art documents] [Patent documents]

[0041] [Patent Document 1] International Publication No. 2021 / 130828 [Non-patent literature]

[0042] [Non-Patent Document 1] New API (NAPI), [online], [searched on January 11, 2022], Internet <URL: http: / / http: / / lwn.net / 2002 / 0321 / a / napi-howto.php3> Summary of the Invention [Problem to be solved by the invention]

[0043] When a polling thread for reception is arranged in the kernel, as in the server network delay control device (KBP) described in Patent Document 1, it is difficult to perform reception processing that takes into account the characteristics of each application, because it is oriented toward versatility. As a result, low latency and power saving in reception processing may be impaired. For example, the above-mentioned power-saving server network delay control device has a function to immediately put the polling thread to sleep when reception processing is completed and no next data arrives (poll_list becomes empty). This function is generally expected to have the effect of improving power saving. On the other hand, if an application has the characteristic of "receiving data from the kernel immediately without requiring in-kernel protocol processing," the reception processing may be immediately completed and poll_list may easily become empty, so that the application may go to sleep even if data is being received continuously. As a result, wake-ups due to hardware interrupts occur frequently, which may impair power saving and low latency.

[0044] The present invention has been made in consideration of this background, and an object of the present invention is to transfer packets with reduced delays within a server while reducing power consumption, even for applications that have different characteristics. [Means for solving the problem]

[0045] In order to solve the above-mentioned problems, a delay control device in a server is provided which is arranged in a user space and starts a thread for monitoring arrival of packets using a polling model, the delay control device comprising: a data arrival monitoring unit which monitors a receiving queue of a device by polling, and acquires data when a packet has arrived; a data arrival notification unit which notifies an application program of the data acquired by the data arrival monitoring unit and passes it on; and a sleep management unit which puts the thread to sleep if a packet does not arrive for a predetermined period of time, and which releases the sleep of the thread by a hardware interrupt when a packet arrives. And, The present invention provides an intra-server delay control device that is characterized by being equipped with the following. Effect of the Invention

[0046] According to the present invention, it is possible to reduce power consumption and to transfer packets with small delays within a server, even for applications having different characteristics. [Brief description of the drawings]

[0047] [Figure 1] 1 is a schematic configuration diagram of an intra-server delay control system according to a first embodiment of the present invention. [Diagram 2] 2 is a diagram for explaining the operation of the intra-server delay control system according to the first embodiment of the present invention; FIG. [Diagram 3] 11 is a flowchart of a transfer process during operation of a polling thread in the intra-server delay control device of the intra-server delay control system according to the first embodiment of the present invention (when a data arrival notifying unit does not process a packet). [Figure 4] FIG. 2 is a diagram for explaining the operation of a transfer process (when a data arrival notifying unit does not process a packet) during operation of a polling thread in the intra-server delay control device of the intra-server delay control system according to the first embodiment of the present invention. [Diagram 5] 1 is a flowchart of a transfer process (when a data arrival notifying unit processes a packet) during operation of a polling thread in an intra-server delay control device of the intra-server delay control system according to the first embodiment of the present invention. [Figure 6] FIG. 2 is a diagram for explaining the operation of a transfer process (when a data arrival notifying unit processes a packet) during operation of a polling thread of an intra-server delay control device of the intra-server delay control system according to the first embodiment of the present invention. [Figure 7] 4 is a processing flowchart showing a process from when a polling thread of an intra-server delay control device of the intra-server delay control system according to the first embodiment of the present invention wakes up from a sleep state. [Figure 8] 1 is an explanatory diagram of the operation of a polling thread of an intra-server delay control device of an intra-server delay control system according to a first embodiment of the present invention, from a sleep state to a wake-up state. FIG. [Figure 9] FIG. 11 is a schematic configuration diagram of an intra-server delay control system according to a second embodiment of the present invention. [Figure 10] 11 is an explanatory diagram of the operation of a characteristic information collection unit of an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. FIG. [Figure 11] 11 is an explanatory diagram of the operation of the logic distribution unit of the intra-server delay control device of the intra-server delay control system according to the second embodiment of the present invention. FIG. [Figure 12] 13 is a processing flowchart of logic change to a data arrival monitoring unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. [Figure 13] 13 is an explanatory diagram of the operation of changing logic to a data arrival monitoring unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. FIG. [Figure 14] 13 is a processing flowchart of logic change to a data arrival notification unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. [Figure 15] 13 is an explanatory diagram of the operation of changing logic to a data arrival notification unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. FIG. [Figure 16] 13 is a processing flowchart of logic change to a sleep management unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. [Figure 17] 11 is an explanatory diagram of the operation of changing logic to a sleep management unit in an intra-server delay control device of an intra-server delay control system according to a second embodiment of the present invention. FIG. [Figure 18] 1 is a hardware configuration diagram showing an example of a computer that realizes the functions of an intra-server delay control device in the intra-server delay control system according to the first and second embodiments of the present invention. FIG. [Figure 19] This is a schematic diagram of Rx-side packet processing using the New API (NAPI) implemented in the Linux kernel 2.5 / 2.6. [Figure 20]20 is a diagram for explaining an outline of Rx-side packet processing by New API (NAPI) in the area surrounded by a dashed line in FIG. 19. FIG. [Figure 21] FIG. 1 is a diagram showing an example of video (30 FPS) data transfer. [Figure 22] FIG. 1 is a diagram showing the CPU utilization rate used by a busy poll thread in the KBP described in Patent Document 1. [Figure 23] FIG. 1 is a diagram illustrating the configuration of a DPDK system that controls HW equipped with an accelerator. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0048] Hereinafter, an intra-server delay control system and the like in an embodiment for carrying out the present invention (hereinafter, referred to as "the present embodiment") will be described with reference to the drawings. (First embodiment) Fig. 1 is a schematic diagram of an intra-server delay control system according to a first embodiment of the present invention. The same components as those in Fig. 23 are denoted by the same reference numerals. As shown in FIG. 1, the intra-server delay control system 1000 executes a data processing APL (Application) 1 (application program; hereinafter, referred to as "application" as appropriate) placed in a User space 160 available to a user on a server equipped with an OS (e.g., a Host OS) 140, and transfers packets between a NIC 130 (device) of a HW 110 connected to the OS and the data processing APL 1. The intra-server delay control system 1000 includes HW 110, OS 140, an intra-server delay control device 200 arranged on a user space 160, and a data processing device APL1. The data processing APL1 is a packet processing carried out prior to the execution of the APL. The HW 110 communicates with the data processing APL 1 to send and receive data. The HW 110 includes a NIC 130 (device) for connecting to a communication network. The HW 110 may include an accelerator 120 shown in FIG.

[0049] [In-server delay control device] The intra-server delay control device 200 is a polling thread that is placed in a user space. The polling thread (internal server delay control device 200) is characterized in that it is provided in the user space, not in the OS kernel. The polling thread (internal server delay control device 200) defines data reception processing in the user space, so it is possible to change the reception processing method according to the application characteristics (characteristics of the application program).

[0050] The intra-server delay control device 200 includes a data arrival monitor 210 , a data arrival notifier 220 , and a sleep manager 230 .

[0051] <Data Arrival Monitoring Unit 210> The data arrival monitor 210 monitors the receiving queue of the device by polling, and when a packet arrives, acquires the data and passes it to the data arrival notifier 220 . Specifically, the data arrival monitoring unit 210 monitors the receiving queue of the device by polling, and when a packet has arrived, it refers to the packet held in the ring buffer and performs pruning by deleting the corresponding queue entry from the ring buffer based on the next process. That is, the data arrival monitoring unit 210 monitors the receiving queue of the device by polling and performs pruning immediately. The data arrival monitor 210 checks whether data has arrived in the receiving queue of the device at a predetermined timing based on the characteristics of the application.

[0052] After a predetermined period of pause, the data arrival monitor 210 checks whether data has arrived in the receiving queue of the device. That is, the data arrival monitor 210 monitors while suppressing the number of CPU cycles by temporarily suspending polling according to the characteristics of the application.

[0053] <Data Arrival Notification Unit 220> The data arrival notification unit 220 notifies and transfers the data acquired by the data arrival monitoring unit 210 to the application.

[0054] When the characteristic of the application is the characteristic of processing packets sequentially, the data arrival notification unit 220 notifies immediately when a packet arrives. On the other hand, when the characteristic of the application is the characteristic of batch-processing packets, the data arrival notification unit 220 notifies when a predetermined number of packets have arrived.

[0055] The data arrival notification unit 220 has a packet processing function, executes the packet processing function based on the characteristics of the application program, and does not notify the application program when the packet processing function is executed. In this way, the data arrival notification unit 220 can select a method of notifying in batches or a method of sequential notification according to the characteristics of the application, and can further cause this functional unit to process packets.

[0056] <Sleep management unit 230> The Sleep management unit 230 controls the timing of permitting hardware interrupts and sleeping based on the characteristics of the application. The Sleep management unit 230 puts the Polling Thread to sleep to permit HW interrupts, or prohibits HW interrupts to wake up the Polling Thread. At this time, the timing of sleeping can be controlled according to the characteristics of the application.

[0057] The Sleep management unit 230 puts the Polling Thread to sleep when no packet arrives, and when a packet arrives again, it is awakened from HardIRQ and Polling is started.

[0058] During Polling, when starting to sleep, the Sleep management unit 230 stops the Polling Thread, permits HW interrupts, and sleeps. At this time, by reducing the CPU operating frequency and operating voltage, the power consumption during sleep is further reduced.

[0059] The sleep management unit 230 has a mechanism for controlling the timing of sleep by permitting HW interrupts according to the characteristics of the application. For example, in the case of an application in which packets arrive immediately even if the driver's receive queue becomes empty, polling can be continued.

[0060] When the sleep management unit 230 is in the sleep state, it is woken up by a HW interrupt that occurs when a packet arrives, and starts polling while the HW interrupt is disabled. At this time, the CPU operating frequency and voltage are reset to higher values.

[0061] The sleep management unit 230 compares the time that has elapsed since the packet did not arrive with a time suitable for the characteristics of the application, and if the time that has elapsed since the packet did not arrive is equal to or greater than the time suitable for the characteristics of the application, it enables a hardware interrupt and puts the thread to sleep.

[0062] The operation of the intra-server delay control system 1000 configured as described above will now be described. [Overall operation of the server delay control system 1000] FIG. 2 is a diagram for explaining the operation of the intra-server delay control system 1000 of FIG. The arrows (symbols) aa to gg in FIG. 2 indicate the flow of packet processing on the Rx side. When the NIC 130 receives a packet (or a frame) from the opposite device in a frame, it bypasses the OS 140 and transmits the packet to the data arrival monitor 210 of the Polling Thread (the intra-server delay control device 200).

[0063] <Operation of Data Arrival Monitoring Unit 210> The data arrival monitor 210 monitors the receiving queue of the device by polling (see FIG. 2). <polling>See symbol aa), and when a packet arrives, it is harvested and handed over to the data arrival notifying unit 220 (see symbol bb in FIG. 2). If the latency requirement of the application is not strict or the packet arrival interval is not short, it is possible to perform reception monitoring while reducing the number of CPU cycles by temporarily suspending Polling (power saving).

[0064] The data arrival monitor 210 starts a polling thread that monitors packet arrivals and directly monitors the receiving queue of the network device. When a packet arrives, it is immediately harvested without waiting, which allows low-latency packet processing to be achieved ("Feature 1: Low-latency packet transfer").

[0065] <Operation of the data arrival notifying unit 220> The data arrival notification unit 220 notifies the data processing APL (Application) 1 of the data harvested by the data arrival monitoring unit 210 and delivers it (see FIG. 2). <notify>; Symbol cc reference).

[0066] Here, the arrival notification method can be selected according to the characteristics of the application, such as "notify immediately when data arrives for an application that processes packets sequentially" or "notify when a certain number of data has arrived for an application that processes packets in batches". Furthermore, when the application is simple, instead of notifying, by having a function to process packets, it is also possible to reduce the overhead of arrival notification and process packets.

[0067] The Polling Thread (server internal delay control device 200) can achieve further reduction in latency and power consumption according to the characteristics of the application and traffic information by controlling the frequency of polling for harvesting, the method of notifying the arrived data to the application, and the timing of putting the Polling Thread to sleep ("Feature 2: Reception processing aware of application characteristics and traffic information").

[0068] <Operation of Sleep Management Unit 230> When a packet arrives, the NIC 130 raises a HW interrupt (hardIRQ) to hardIRQ81 (handler) (in Figure 2 <interrupt>When the hardwire 81 (handler) is started, the sleep management unit 230 is woken up by a HW interrupt that occurs when a packet arrives (see FIG. 2). <wakeup>(see symbol ee) and starts polling while disabling HW interrupts. In other words, the sleep management unit 230 puts the polling thread to sleep when no packet has arrived, and when a packet arrives again, it is woken up by the HardIRQ 81 and starts polling.

[0069] The sleep management unit 230 puts the polling thread to sleep and allows HW interrupts, or disables HW interrupts and wakes up the polling thread (see FIG. 2). <enable disable>(See symbol ff.) In this case, the timing of sleep can be controlled according to the characteristics of the application.

[0070] When starting sleep during polling, the sleep management unit 230 stops the polling thread and sleeps while permitting HW interrupts (see FIG. 2).<Polling Start / stop> (See symbol gg.) At this time, the power consumption during sleep is further reduced by lowering the CPU operating frequency and operating voltage.

[0071] The sleep management unit 230 has a mechanism for controlling the timing of sleep by permitting HW interrupts according to the characteristics of the application. For example, in the case of an application in which packets arrive immediately even if the driver's receive queue becomes empty, polling can be continued.

[0072] The sleep management unit 230 puts the polling thread to sleep when no packet has arrived. This reduces unnecessary CPU usage and achieves power saving. By lowering the CPU operating voltage and operating frequency when the device goes to sleep, power saving can be achieved even further ("Feature 3: Power saving"). In addition, the Polling Thread in the sleep state can be woken up by the HardIRQ handler 81 when a packet arrives, allowing immediate startup while avoiding softIRQ contention.

[0073] <How to determine parameters U, T, and K> A method for determining the parameters U, T, and K used in the flow charts of FIG. 3 and FIG. 5 will be described later. The Polling Thread (internal server delay control device 200) uses a data arrival monitoring interval U (a parameter of the data arrival monitoring unit 210), a time T from when a packet does not arrive until sleep is entered (a parameter of the sleep management unit 230), and the number of batches K for notifying or processing packets (a parameter of the data arrival notification unit 220). In the first embodiment, the parameters U, T, and K are fixed values ​​set in advance by the operator. In the second embodiment described below, the parameters U, T, and K are dynamically set via the logic management unit 310 (for convenience of explanation, they are described together here).

[0074] Example of determining data arrival monitoring interval U There are fixed values ​​that are set in advance by the operator, and dynamic settings via the logic management unit 310 (described later). In the case of dynamic configuration via the logic manager 310 (described below), there are two cases: Example 1: The packet arrival frequency is acquired by the data arrival monitor 210, and U is set so that arrival monitoring can be performed at a frequency close to that frequency. Example 2: Obtain the maximum allowable delay from an application or a controller external to the server, and set U so that arrival monitoring can be performed at a frequency that maintains that delay.

[0075] Example of determining the time T from when a packet is not received until the device goes into sleep There are fixed values ​​that are set in advance by the operator, and dynamic settings via the logic management unit 310 (described later). In the case of dynamic configuration via the logic manager 310, there are two cases: Example 1: The sleep management unit 230 acquires the time from going into sleep to waking up, and if that interval is so short that it adversely affects delay time and power saving performance, T is increased. Example 2: The packet arrival frequency is obtained from the data arrival monitor 210, an application, or a controller external to the server, and if it is high, T is made small so that sleep can be performed as much as possible.

[0076] Example of determining the number of batches K to notify or process packets The batch number K will now be described. That is, when multiple packets are stored in the Ring_Buffer area, the data arrival monitor 210 cuts the multiple packets together and passes them to the subsequent protocol processor (not shown). This number of packets cut together is called a quota, and is called batch processing, and the number of processes is called the batch number (batch processing number). There are fixed values ​​that are set in advance by the operator, and dynamic settings via the logic management unit 310 (described later). In the case of dynamic configuration via the logic manager 310 (described below), the following examples are given. Example 1: Obtain batch processing information within the application from the application and set K accordingly.

[0077] Next, the transfer process during the operation of the Polling Thread will be described with reference to Figures 3 to 6. The transfer process during the operation of the Polling Thread can be performed in two cases: when the data arrival notification unit 220 does not process packets (see Figures 3 and 4), and when the data arrival notification unit 220 processes packets (see Figures 5 and 6). Each case will be described.

[0078] [Transfer Processing During Polling Thread Operation (When the Data Arrival Notification Unit 220 Does Not Process Packets)] <Flowchart> FIG. 3 is a flowchart of a transfer process during operation of the polling thread (when the data arrival notifying unit 220 does not process a packet).

[0079] In step S11, the data arrival monitor 210 checks, at intervals appropriate for the application characteristics, whether data has arrived in the receiving queue of the NIC 130. The data arrival monitor 210 pauses for a period of time U, for example, before checking. In step S12, the data arrival monitor 210 determines whether data has arrived in the receiving queue. If no data has arrived in the receiving queue (S12: No), the process proceeds to step S17.

[0080] When data has arrived at the reception queue (S12: Yes), in step S13, the data arrival monitoring unit 210 acquires the data from the reception queue and transmits the corresponding information to the data arrival notification unit 220 (when multiple data have arrived at the reception queue, multiple data are transmitted). Also, at this time, the Sleep management unit 230 resets the elapsed time S since the packet became outstanding to 0.

[0081] In step S14, the data arrival notification unit 220 adds the number of packets N that have arrived so far and compares it with the batch number K suitable for the application characteristics.

[0082] In step S15, the data arrival notification unit 220 determines whether N≥K. If N<K (S15: No), it returns to step S11 above.

[0083] If N≥K (S15: Yes), in step S16, the data arrival notification unit 220 notifies the application of the data arrival, delivers the data, sets the number of packets N that have arrived so far to 0, and returns to step S11 above.

[0084] In step S17, the Sleep management unit 230 compares the elapsed time S since the packet became outstanding with the time T suitable for the application characteristics.

[0085] In step S18, the Sleep management unit 230 determines whether S≥T. If S<T (S18: No), it returns to step S11 above.

[0086] If S≥T (S18: Yes), in step S19, the Sleep management unit 230 enables the HW interrupt, lowers the CPU operating frequency and operating voltage, puts the Polling Thread to sleep, and ends the processing of this flow.

[0087] The number of batches K (≧1), the time T (≧0) suitable for the application characteristics, and the pause time U (≧0) will be described. K, T, and U are set in advance by the operator. K, T, and U are dynamically changed by the logic management unit 310 (an example of determining K, T, and U will be described later in the second embodiment).

[0088] <Operation explanation diagram> FIG. 4 is a diagram for explaining the operation of the transfer process during the operation of the Polling Thread (when the data arrival notifying unit 220 does not process a packet). When the NIC 130 receives a packet, it copies the packet directly to the Ring Buffer (a buffer in main memory) using DMA (Direct Memory Access) without going through the CPU (see Figure 4). <polling>(See symbol aa.) This Ring Buffer is set up in advance so that it can be accessed directly from the Polling Thread in User Space 160 without going through the OS kernel.

[0089] The NIC 130 generates an interrupt to the CPU that the polling thread is running, and the CPU notifies the polling thread of wakeup in the context of a hardware interrupt, waking up the sleep management unit 230. After that, the polling thread runs in the CPU.

[0090] The sleep management unit 230 sets the frequency of the CPU high and inhibits interrupts to the CPU (see FIG. 4). <enable>(See symbol ff.) The CPU frequency can be changed from User Space 160 by changing the CPUgovernor settings.

[0091] The sleep management unit 230 instructs the data arrival monitor unit 210 to start polling (see FIG. 4).<Polling stop> (See symbol gg.) The Polling start instruction is specifically a call from the sleep management unit 230 to a function for processing the data arrival monitoring unit 210.

[0092] The data arrival monitoring unit 210 checks the arrival of packets in the ring buffer area to which the packets are DMA'd at an arrival confirmation interval determined in advance by the operator, and if a packet has arrived, it transmits the address information (pointer) of the packet to the data arrival notification unit 220 (see symbol bb in Figure 4).

[0093] The data arrival notifying unit 220 checks whether the number of pieces of pointer information transmitted from the data arrival monitoring unit 210 reaches the number of batches for notifying packets, which has been determined in advance by the operator (steps S14 to S15 in FIG. 3).

[0094] If the number of transmitted pointer information reaches the number of batches for notifying the determined packets, the process proceeds to the following process. If not, the process returns to the packet arrival confirmation by the data arrival monitor 210.

[0095] The data arrival notification unit 220 stores the address information in a memory shared by the application and the polling thread, starts a thread in which the application runs, and executes the process within the thread (see FIG. 4). <notify>; see sign cc).

[0096] When the time during which no packets have arrived continues for a period of time determined in advance by the operator, the data arrival monitor 210 calls the sleep manager 230 (step S12 in FIG. 3). When the data arrival monitor 210 returns, the process returns to the sleep manager 230.

[0097] The sleep management unit 230 reduces the CPU frequency, enables interrupts to the CPU, and puts the polling thread into a sleep state (step S19 in FIG. 3).

[0098] [Transfer Processing During Polling Thread Operation (When the Data Arrival Notification Unit 220 Processes Packets)] If the operator has configured the application logic to be executed in the same thread, the processing is performed within the Polling Thread.

[0099] <Flowchart> 5 is a flowchart of a transfer process during the operation of the Polling Thread (when the data arrival notification unit 220 processes packets). Steps that perform the same processes as in the flow of FIG. 3 are given the same numbers and their explanations are omitted. In step S15, the data arrival notifying unit 220 determines whether or not N≧K holds, and if N≧K holds (S15: Yes), the process proceeds to step S21. In step S21, data arrival notification unit 220 processes the packet (for example, forwards it to another server) and returns to step S11. Data arrival notification unit 220 also sets the number of packets N that have arrived so far to 0. Since data arrival notification unit 220 processes the packet, there is no process of notifying an application of data arrival and handing over the data, as in data arrival notification unit 220 in step S16 of FIG.

[0100] <Operation explanation diagram> 6 is a diagram for explaining the operation of the transfer process (when the data arrival notifying unit 220 processes a packet) during the operation of the Polling Thread. The same components as those in the operation explanatory diagram of FIG. 4 are given the same reference numbers and the explanation thereof will be omitted.

[0101] The data arrival notification unit 220 processes packets. The packet processing performed by the data arrival notification unit 220 in the polling thread is a transfer process to another server, which is a relatively light load process.

[0102] [Processing until Polling Thread wakes up from Sleep state] Fig. 7 is a processing flow chart showing how the Polling Thread wakes up from a sleep state. Fig. 8 is a diagram explaining the operation. The same components as those in Fig. 2 are given the same numbers. In step S31, data arrives at the NIC 130, and an interrupt is issued from the NIC 130 to the CPU. In step S32, a HW interrupt context is started in the relevant CPU. In step S33, the sleep management unit 230 of the polling thread is woken up in the context of the HW interrupt.

[0103] Specifically, as shown in FIG. 8, when a packet arrives, the NIC 130 raises a HW interrupt (hardIRQ) to the hardIRQ 81 (handler) (see FIG. 8). <interrupt>When the hardwire 81 (handler) is started, the sleep management unit 230 is woken up by a HW interrupt that occurs when a packet arrives (see FIG. 8). <wakeup>;see code ee), and starts polling while disabling HW interrupts.

[0104] In step S34, the sleep management unit disables the interrupt from the NIC 130 (see FIG. 8). <enable>; see symbol ff), set the CPU operating frequency and operating voltage high, and start polling of the data arrival monitor unit 210. When polling is in progress, the sleep manager 230 stops the polling thread when starting sleep, and sleeps while permitting HW interrupts (see FIG. 8).<Polling Start > ; see sign gg).

[0105] Second embodiment 9 is a schematic diagram of an in-server delay control system according to a second embodiment of the present invention, in which the same components as those in FIG. As shown in FIG. 9, the intra-server delay control system 1000A includes HW 110, OS 140, an intra-server delay control device 300 arranged on a user space 160, and a data processing device APL1.

[0106] The intra-server delay control device 300 includes a logic management unit 310 in addition to the functional units of the data arrival monitor unit 210, data arrival notifier unit 220, and sleep manager unit 230 (hereinafter referred to as "individual functional units") of the intra-server delay control device 200 in FIG. The logic management unit 310 collects application characteristic information and thread processing information, and based on the collected information, in the case of an application in which the load varies depending on the time period and the processing method and processing speed vary, changes the processing logic of at least one of the functional units, the data arrival monitoring unit 210, the data arrival notification unit 220, and the sleep management unit 230.

[0107] <Logic Management Unit 310> When multiple processing logics are possible for each functional unit of the intra-server delay control device 200 in FIG. 1, the logic management unit 310 dynamically selects a processing logic and notifies each functional unit of the selected processing logic. In the case of an application in which the load varies depending on the time of day and the processing method and processing speed vary, the logic management unit 310 maintains low latency and power saving by changing the processing logic of each functional unit within the polling thread and changing the reception processing method.

[0108] The logic management unit 310 is made up of two functional units: a characteristic information collection unit 311 and a logic distribution unit 312 . The characteristic information collector 311 collects application and traffic characteristics from the application and the polling thread. The characteristic information collector 311 collects information required to appropriately determine logic suitable for characteristics that vary over time.

[0109] The logic distribution unit 312 appropriately determines logic suitable for each functional unit based on the application and traffic characteristic information collected by the characteristic information collection unit 311, and distributes it to each functional unit. The logic distribution unit 312 instructs each functional unit to operate with logic suitable for the characteristics that vary over time. The characteristic information collector 311 and the logic distributor 312 will be described in detail below with reference to an operation explanatory diagram.

[0110] <Characteristics Information Collector 311> First, the characteristic information collecting unit 311 will be described. FIG. 10 is a diagram illustrating the operation of the characteristic information collector 311. As shown in FIG. The characteristic information collector 311 collects characteristic information from applications and polling threads. The characteristic information collection unit 311 collects application characteristic information and polling thread processing information, and passes them to the logic distribution unit 312. The application characteristic information and polling thread processing information are information for determining the logic of each functional unit. The collected information is used to determine logic suitable for each functional unit.

[0111] An example of the characteristics information of an application will be described. An example of characteristic information of an application is "changes in packet processing methods within an application." For example, when the load on the Application Logic increases and the packet processing method is changed from sequential processing to batch processing, the characteristic information collector 311 collects that information (see symbol hh in FIG. 10). This information is used, for example, to change the processing logic of the data arrival notifier 220 from "sequentially notify the application when data arrives" to "notify the application after K pieces of data arrive."

[0112] An example of processing information of the Polling Thread will be described. An example of processing information for a Polling Thread is "statistical information on the time from going to sleep to waking up." For example, if there is an increase in cases where the user wakes up immediately after going to sleep, that information is collected (see reference character ii in FIG. 10). This information is used, for example, to change the logic by which the sleep management unit 230 starts to sleep from "immediately sleep when no packet arrives" to "sleep a certain period of time after no packet arrives."

[0113] Above, application characteristic information and polling thread processing information were given as examples of information for determining the logic of each functional unit. However, in addition to characteristic information from within the same server, such as an application or polling thread, information may also be received from another system and used to select the logic. For example, when the intra-server delay control device 300 is installed in a vDU (virtualized Distributed Unit) server or a vCU (virtualized Centralized Unit) server in a vRAN (virtualized Radio Access Network), it can receive information on the service provision status from a higher-level controller, a RAN Intelligent Controller (RIC), and use the information to select logic.

[0114] <Logic distribution unit 312> Next, the logic distribution unit 312 will be described. FIG. 11 is a diagram illustrating the operation of the logic distribution unit 312. As shown in FIG. The logic distribution unit 312 determines and distributes logic suitable for each functional unit based on the information collected by the characteristic information collection unit 311, and changes the logic of each functional unit.

[0115] Example of data arrival monitoring logic distribution When the latency requirement of an application becomes weaker or the data arrival frequency becomes lower, it may be acceptable to reduce the frequency of data arrival monitoring to save power. In this case, the frequency is changed from "data arrival monitoring by busy loop" to, for example, "data arrival monitoring once per 1 μs" (see symbol jj in Figure 11).

[0116] Example of data arrival notification logic delivery When application processing is changed from sequential processing to batch processing, it may be better to batch data arrival notification as well to reduce latency and power consumption. In this case, the logic of "sequentially notifying the application of data arrival" is changed to "notifying the application of data arrival after K pieces of data have arrived" (see symbol kk in Figure 11).

[0117] Example of Sleep start logic distribution If it becomes common for the system to go to sleep and then be woken up immediately by an interrupt, in order to prevent increased delays and power consumption due to excessive interrupts, the logic will be changed from "go to sleep immediately when no data has arrived" to "go to sleep Tμs after no data has arrived" (see symbol ll in Figure 11).

[0118] The operation of the intra-server delay control system 1000A configured as described above will now be described. [Overall operation of the server delay control system 1000A]

[0119] <Settings> The logic management unit 310 runs on a CPU separate from the polling thread. A shared memory exists between each functional unit in the polling thread and the logic manager 310.

[0120] <Operation 1> When the NIC 130 receives a packet, it copies the packet directly to the Ring Buffer (a buffer in main memory) using DMA (Direct Memory Access) without going through the CPU. Note that this Ring Buffer is set up in advance so that it can be accessed directly from the Polling Thread in User Space without going through the OS kernel.

[0121] The NIC 130 generates an interrupt to the CPU that the polling thread is running, and the CPU notifies the polling thread of wake-up in the context of a hardware interrupt, waking up the sleep management unit 230 . From then on, the Polling Thread will run on that CPU.

[0122] The sleep management unit 230 sets the CPU frequency high and prohibits interrupts to the CPU. The CPU frequency can be changed from the user space by the CPU governor setting.

[0123] The sleep management unit 230 records the time from going into sleep to waking up, and stores the time in a memory shared with the logic management unit 310.

[0124] The sleep management unit 230 instructs the data arrival monitoring unit 210 to start polling (the sleep management unit 230 calls a function corresponding to the processing of the data arrival monitoring unit 210). At this time, the sleep management unit 230 reads out the time information from when the packet does not arrive until when the sleep starts from a memory area shared with the logic management unit 310, and calls the function corresponding to the processing of the data arrival monitoring unit 210 by specifying the value as an argument.

[0125] The data arrival monitor 210 refers to the memory shared with the logic manager 310 and reads out the arrival confirmation interval. At this arrival confirmation interval, the data arrival monitor 210 checks the arrival of the packet in the ring buffer area to which the packet is DMA-transmitted. If the packet has arrived, the data arrival notifier 220 transmits the address information (pointer) of the packet.

[0126] The data arrival notification unit 220 checks whether the number of pieces of pointer information transmitted from the data arrival monitoring unit 210 reaches the number of batches written in the memory shared with the logic management unit 310. If the number of pieces of pointer information reaches the number of batches written in the memory shared with the logic management unit 310, the operation proceeds to the following. If not, the operation returns to the arrival confirmation operation of the data arrival monitoring unit 210 and processing is executed in a loop.

[0127] The data arrival notification unit 220 stores the address information in a memory shared by the application and the polling thread, wakes up a thread on which the application runs, and executes processing within that thread. If the operator has set the application logic (data processing APL1) to be executed in the same thread, the processing is performed within the Polling Thread.

[0128] In the above, if the time specified as an argument has elapsed with no packet having arrived, the data arrival monitoring unit 210 calls the sleep management unit 230. That is, when the data arrival monitoring unit 210 returns, the processing returns to the sleep management unit 230. Immediately before returning the function, the data arrival monitoring unit 210 writes the average packet arrival frequency during the operation of the Polling Thread to a memory shared with the logic management unit 310.

[0129] The sleep management unit 230 reduces the CPU frequency, enables interrupts to the CPU, and puts the polling thread into a sleep state.

[0130] When the application (data processing APL1) changes the number of batch processes in response to the load or the like, it appropriately writes the change to the memory shared with the logic management unit 310. When the application runs in a thread separate from the polling thread, a separate shared memory is also set in advance between the application and the logic management unit 310.

[0131] <Operation 2> The following runs on a different CPU from the Polling Thread and runs independently in terms of time. The following <Action 2> and the above <Action 1> can occur in parallel. The characteristic information collector 311 circulates around and monitors each shared memory with the functional units in the polling thread, and if writing has been performed in the shared memory, it executes the following process.

[0132] If the data arrival frequency is written in a memory shared with the data arrival monitoring unit 210 and the value is smaller than the current data arrival confirmation interval, the data arrival frequency is set as the new data arrival confirmation interval and the logic distribution unit 312 is called (a function corresponding to the logic distribution unit 312 is called).

[0133] The logic distribution unit 312 writes the new data arrival confirmation interval in the memory shared with the data arrival monitor unit 210 .

[0134] If the batch number has been written in the memory shared with the application, that batch number is set as the new data arrival notification batch number, and the logic distribution unit 312 is called (a function corresponding to the logic distribution unit 312 is called).

[0135] The logic distribution unit 312 writes the new data arrival notification batch number in the memory shared with the data arrival notification unit 220 .

[0136] The time from going to sleep to waking up is written in the memory shared with the sleep management unit 230, and if this value is smaller than a predetermined threshold (e.g., 5 μs) (the threshold differs depending on the system, so advance setting is required), it decides to extend the time from when a packet does not arrive until going to sleep by 5 μs, and calls the logic distribution unit 312 (calls a function corresponding to the logic distribution unit 312).

[0137] The logic distribution unit 312 writes the new "time from when a packet does not arrive until when sleep is entered" in the memory shared with the sleep management unit 230. This completes the explanation of the overall operation of the intra-server delay control system 1000A.

[0138] [Operation of logic management unit 310] Next, an example of processing by the logic management unit 310 will be described with reference to the flowcharts and operation explanatory diagrams shown in FIGS.

[0139] <Example of logic changes to the data arrival monitor unit 210> First, as an example of processing by the logic management unit 310, an example of logic change to the data arrival monitor unit 210 will be described. Fig. 12 is a processing flow chart for changing logic to the data arrival monitor 210. Fig. 13 is an explanatory diagram of the operation. The same components as in Fig. 11 are given the same numbers. 12, in step S41, the data arrival monitor 210 acquires the packet arrival frequency and periodically notifies the characteristic information collector 311 (see symbol mm in FIG. 13). For example, the data arrival monitor 210 transmits the packet arrival frequency to the characteristic information collector 311 at the timing when Polling is put into sleep.

[0140] In step S42, the characteristic information collector 311 compares the packet arrival frequency with the current arrival monitoring interval. If the packet arrival frequency is less than the arrival monitoring interval (S43: No), the process proceeds to step S46.

[0141] In step S43, if the packet arrival frequency is greater than or equal to the arrival monitoring interval (S43: Yes), the characteristic information collection unit 311 decides in step S44 to widen the arrival monitoring interval (for example, by 1 μs) and transmits the logic change to the logic distribution unit 312 (see symbol nn in Figure 13).

[0142] In step S45, the logic distribution unit 312 distributes logic to the data arrival monitoring unit 210, widens the arrival monitoring interval, and ends the processing of this flow.

[0143] On the other hand, if the packet arrival frequency is less than the arrival monitoring interval in step S43 (S43: No), then in step S46 the characteristic information collecting unit 311 decides to narrow the arrival monitoring interval and transmits the change in logic to the logic delivering unit 312. For example, the characteristic information collecting unit 311 transmits that the arrival monitoring interval will be narrowed by 1 μs (see symbol nn in FIG. 13).

[0144] In step S47, the logic distribution unit 312 distributes logic to the data arrival monitoring unit 210, narrows the arrival monitoring interval, and ends the processing of this flow.

[0145] <Example of logic changes to the data arrival notification unit 220> Next, as an example of processing by the logic management unit 310, an example of changing logic to the data arrival notification unit 220 will be described. Fig. 14 is a processing flow chart for changing logic to the data arrival notifying unit 220. Fig. 15 is an explanatory diagram of the operation. The same components as in Fig. 11 are given the same numbers. In the flow of FIG. 14, when the data processing APL1 (application) changes the batch processing number in step S51, it notifies the logic management unit 310 of the batch processing number (see reference character oo in FIG. 15).

[0146] In step S52, the characteristic information collector 311 determines to notify the arrival of data with the changed number of batch processes, and notifies the logic distributor 312 of the change in logic.

[0147] In step S53, the logic distribution unit 312 distributes the number of batch processes to the data arrival notification unit 220 (see reference sign pp in FIG. 15), causing it to make a change and end the processing of this flow.

[0148] <Example of Logic Change to the Sleep Management Unit 230> Next, as an example of the processing of the logic management unit 310, an example of a logic change to the Sleep management unit 230 will be described. FIG. 16 is a flowchart of the processing of the logic change to the Sleep management unit 230. FIG. 17 is an operation explanatory diagram thereof. The same components as those in FIG. 11 are denoted by the same reference numerals. In the flow of FIG. 16, in step S61, the Sleep management unit 230 records the time from entering Sleep until being woken up by a HardIRQ, and transmits the information to the characteristic information collection unit 311 (see reference sign qq in FIG. 17). For example, the Sleep management unit 230 transmits it via shared memory at the timing of waking up.

[0149] In step S62, the characteristic information collection unit 311 calculates the average time from when the Polling Thread enters Sleep until it is woken up, and determines whether there is an adverse effect on performance. The determination of whether there is an adverse effect on performance varies depending on the system. For example, the average time from entering Sleep until being woken up is set to 5 μs.

[0150] In step S63, the characteristic information collection unit 311 determines whether the average time from entering Sleep until being woken up is 5 μs. If the average time from entering Sleep until being woken up is 5 μs (S63: Yes), in step S64, the characteristic information collection unit 311 determines to increase the time from when a packet fails to arrive until entering Sleep (for example, increase it by 5 μs), and transmits the logic change to the logic distribution unit 312 (see reference sign rr in FIG. 17).

[0151] In step S65, the logic distribution unit 312 distributes logic to the data arrival notification unit 220, changes the time from when a packet does not arrive until the sleep state is entered, and ends the processing of this flow.

[0152] [Hardware configuration] The intra-server delay control devices 200 and 300 according to the first and second embodiments are realized by a computer 900 having a configuration as shown in FIG. 18, for example. FIG. 18 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the intra-server delay control devices 200 and 300. As shown in FIG. The computer 900 has a CPU 901 , a ROM 902 , a RAM 903 , a HDD 904 , a communication interface (I / F) 906 , an input / output interface (I / F) 905 , and a media interface (I / F) 907 .

[0153] The CPU 901 operates based on a program stored in the ROM 902 or HDD 904, and controls each part of the intra-server delay control device 200, 300 shown in Figures 1 and 9. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0154] The CPU 901 controls an input device 910 such as a mouse and a keyboard, and an output device 911 such as a display, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0155] The HDD 904 stores programs executed by the CPU 901, data used by the programs, and the like. The communication I / F 906 receives data from other devices via a communication network (for example, NW (Network) 920) and outputs it to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0156] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to the target process from the recording medium 912 onto the RAM 903 via the media I / F 907 and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductor memory tape medium, or a semiconductor memory.

[0157] For example, when the computer 900 functions as the in-server delay control devices 200 and 300 configured as one device according to the present embodiment, the CPU 901 of the computer 900 realizes the functions of the in-server delay control devices 200 and 300 by executing the program loaded onto the RAM 903. Also, the data in the RAM 903 is stored in the HDD 904. The CPU 901 reads and executes a program related to the target process from the recording medium 912. Additionally, the CPU 901 may read a program related to the target process from other devices via the communication network (NW 920).

[0158] [Application Example] <Application Example to VM Configuration> The present invention can be applied to each of the host in the VM (Virtual Machine) configuration and the Polling Thread arranged in the guest. By doing this, in a system with a virtual server configuration of VMs, in both the Host OS and the Guest OS, it is possible to perform packet transfer with reduced delay within the server without modifying the APL.

[0159] <Example of application to container configuration> The present invention can also be applied to a Polling Thread arranged in a container configuration. In systems with virtual server configurations such as containers, packet transfer can be performed with reduced delays within the server without modifying the application.

[0160] <Example of application to bare metal configuration (non-virtualized configuration)> The present invention can be applied to systems with a non-virtualized configuration, such as a bare metal configuration, in which packets can be transferred with reduced delay within the server without modifying the application.

[0161] <Scale in / out> When traffic volume is high and multiple NIC devices or NIC ports are used, by running multiple Polling Threads in association with them, it is possible to scale in / out the Polling Threads while controlling the HW interrupt frequency.

[0162] [effect] As described above, the intra-server delay control device according to the first embodiment is an intra-server delay control device 200 (see FIG. 1) that is placed in a user space and starts a thread that monitors packet arrival using a polling model, and includes a data arrival monitoring unit 210 that monitors the receiving queue of a device (NIC 130) by polling and acquires the data if a packet has arrived, a data arrival notification unit 220 that notifies an application program (data processing APL1) of the data acquired by the data arrival monitoring unit 210 and passes it on, and a sleep management unit 230 that puts the thread (polling thread) to sleep if no packet arrives for a predetermined period of time and wakes up the thread (polling thread) from sleep mode using a hardware interrupt (hardIRQ) when a packet arrives, and the sleep management unit 230 is characterized in that it controls the timing of sleep by permitting a hardware interrupt (hardIRQ) based on the characteristics of the application program.

[0163] In this way, the intra-server delay control device 200 stops software interrupts (softIRQ) for packet processing, which is the main cause of NW delays, and the data arrival monitor unit 210 of the intra-server delay control device 200 executes a thread for monitoring packet arrival, and performs packet processing using a polling model (without softIRQ) when a packet arrives. If no packet arrives for a predetermined period, the sleep management unit 230 puts the thread (polling thread) to sleep, so that the thread (polling thread) goes to sleep when no packet arrives. The sleep management unit 230 releases the thread from sleep mode using a hardware interrupt (hardIRQ) when a packet arrives. Furthermore, the sleep management unit 230 controls the timing of sleep by permitting a hardware interrupt (hardIRQ) based on the characteristics of the application program. This provides the following advantages (1) to (4).

[0164] (1) A polling model is realized that stops software interrupts (softIRQ) when a packet arrives, which causes delays. In other words, unlike the existing technology NAPI, the intra-server delay control system 1000 realizes a polling model instead of the interrupt model, which is the main cause of network delays. When a packet arrives, it is immediately harvested without waiting, making it possible to realize low-latency packet processing ("Achieving low latency with a polling model").

[0165] (2) The polling thread in the intra-server delay control device 200 monitors the arrival of packets in polling mode. The polling thread that monitors the arrival of packets goes to sleep while no packets have arrived. When no packets have arrived, the CPU is not used due to the sleep state, which can provide a power saving effect ("Reducing unnecessary CPU usage and achieving power saving by managing the sleep state of the polling thread").

[0166] (3) Furthermore, the method of reception processing can be changed to match the characteristics of the application program, making it possible to achieve both low latency and power saving even for application programs with different characteristics ("Achieving low latency and power saving tailored to application programs").

[0167] (4) Since the data reception process is defined in the user space, the method of reception process can be changed according to the characteristics of the application program. The present invention can be applied to a case where there is a polling thread in user space, such as DPDK.

[0168] In this way, the intra-server delay control device 200 (see FIG. 1) can achieve both low latency and power saving by managing the sleep state of the polling thread that performs packet transfer processing when the polling thread exists in the user space. Furthermore, it can achieve both low latency and power saving even for applications with different application program characteristics.

[0169] In the intra-server delay control device 200, the sleep management unit 230 compares the time that has elapsed since the packet did not arrive with a predetermined time suitable for the characteristics of the application program, and if the time that has elapsed since the packet did not arrive is equal to or greater than the time suitable for the characteristics of the application program, enables a hardware interrupt and puts the thread to sleep.

[0170] In this way, the sleep management unit 230 controls the timing of sleep by permitting HW interrupts according to the characteristics of the application program. For example, the sleep management unit 230 can continue polling in the case of an application program in which packets arrive immediately even if the driver's receive queue becomes empty during polling. This makes it possible to achieve further reductions in delay and power saving according to the characteristics of the application program and the traffic characteristics.

[0171] In the intra-server delay control device 200, the data arrival monitor 210 is characterized in that it checks whether data has arrived in the receiving queue of the device at a predetermined timing based on the characteristics of the application program.

[0172] In this way, by controlling the frequency of harvesting by polling according to the characteristics of the application program and traffic information, it is possible to achieve further reduction in latency and power saving according to the characteristics of the application program and traffic.

[0173] In the intra-server delay control device 200, the data arrival monitor 210 is characterized in that it checks whether data has arrived in the receiving queue of the device after a predetermined period of suspension.

[0174] In this way, when the delay requirements of the application program are not strict or the packet arrival interval is not short, the data arrival monitoring unit 210 can temporarily suspend polling (for example, after pausing for a specified period of time, check whether data has arrived in the device's reception queue), thereby enabling reception monitoring while reducing the number of CPU cycles and achieving power savings.

[0175] In the intra-server delay control device 200, the data arrival notification unit 220 is characterized in that if the application program has a characteristic of processing packets sequentially, it notifies immediately when a packet arrives, and if the application program has a characteristic of processing packets in batches, it notifies when a predetermined number of packets have arrived.

[0176] In this way, the arrival notification method can be selected according to the characteristics of the application program, and further reduction in delay according to the characteristics of the application program can be achieved.

[0177] In the intra-server delay control device 200, the data arrival notification unit 220 has a packet processing function, and executes the packet processing function according to the characteristics of the application program, and is characterized in that when the packet processing function is executed, no notification is given to the application program.

[0178] In this way, if the application program is simple, by providing a function for processing packets instead of notifying them, it is possible to process packets while reducing the overhead of arrival notification, thereby achieving further reduction in delay according to the characteristics of the application program.

[0179] The intra-server delay control device 300 (see FIG. 9) of the second embodiment is characterized by having a logic management unit 310 that collects characteristic information of an application program and thread processing information, and based on the collected information, changes the processing logic of at least one of the functional units of the data arrival monitoring unit 210, the data arrival notification unit 220, and the sleep management unit 230 in the case of an application program in which the load varies depending on the time period and the processing method and processing speed vary.

[0180] In this way, the logic management unit 310 dynamically determines the processing logic of each functional unit of the polling thread (data arrival monitoring unit 210, data arrival notification unit 220, sleep management unit 230) in accordance with the characteristics of the application program and the processing of the thread, and distributes it to each functional unit. This makes it possible to maintain low latency and power saving in the reception process even for applications whose characteristics change dynamically, by operating each functional unit with processing logic that matches the changing characteristics.

[0181] In addition, among the processes described in each of the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified. In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc.

[0182] In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized by software for a processor to interpret and execute a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, SD (Secure Digital) card, or optical disk. [Explanation of symbols]

[0183] 1 Data processing APL (application program) 10 HW 70 Guest OS 72 Ring Buffer 74 Protocol Processing Unit 110HW 130 NIC (physical NIC) (device) 140 OS 160 user space 200,300 Server Delay Control Device (Polling Thread) 210 Data arrival monitoring unit (each functional unit) 220 Data arrival notification unit (each functional unit) 230 Sleep management department (each functional department) 310 Logic Management Unit 311 Characteristics Information Collection Department 312 Logic Distribution Department 1000 Server Delay Control System< / enable> < / wakeup> < / interrupt> < / notify> < / enable> < / polling> < / enable> < / wakeup> < / interrupt> < / notify> < / polling>

Claims

1. A server-side delay control device that is located in a user space and launches a thread that monitors packet arrivals using a polling model, a data arrival monitor unit that monitors the receiving queue of the device by polling and acquires data when a packet has arrived; a data arrival notification unit that notifies an application program of the data acquired by the data arrival monitoring unit and transfers the data to the application program; a sleep management unit that puts the thread to sleep if no packet arrives for a predetermined period of time, and that releases the thread from sleep mode by a hardware interrupt when a packet arrives. The delay control device in a server is characterized by:

2. The sleep management unit compares the time that has elapsed since the packet did not arrive with a time that is suitable for the characteristics of the application program, and if the time that has elapsed since the packet did not arrive is equal to or greater than a predetermined time that is suitable for the characteristics of the application program, enables a hardware interrupt and puts the thread to sleep.

2. The delay control device in a server according to claim 1 .

3. The data arrival monitoring unit checks whether data has arrived in the receiving queue of the device at a predetermined timing based on the characteristics of an application program.

2. The delay control device in a server according to claim 1 .

4. The data arrival notification unit notifies the application program immediately upon packet arrival if the application program has a characteristic of processing packets sequentially, and notifies the application program when a predetermined number of packets have arrived if the application program has a characteristic of processing packets in batches.

2. The delay control device in a server according to claim 1 .

5. The data arrival notification unit has a packet processing function, executes the packet processing function according to the characteristics of the application program, and does not notify the application program when the packet processing function is executed.

2. The delay control device in a server according to claim 1 .

6. collecting information regarding characteristics of application programs and processing information for said threads; In the case of an application program in which the load varies depending on the time period and the processing method and processing speed vary based on the collected information, a logic management unit is provided which changes the processing logic of at least one of the functional units, the data arrival monitoring unit, the data arrival notification unit, and the sleep management unit.

2. The delay control device in a server according to claim 1 .

7. A method for controlling delay in a server by a delay control device in a server, the method including: launching a thread that is arranged in a user space and monitors arrival of a packet using a polling model; The server delay control device includes: monitoring a receiving queue of the device by polling, and acquiring data if a packet has arrived; notifying an application program of the acquired data and transferring the data to the application program; putting the thread to sleep if no packet arrives for a predetermined period of time, and waking up the thread from sleep mode by a hardware interrupt when a packet arrives. A method for controlling delay within a server.

8. A program for causing a computer to function as the server internal delay control device according to any one of claims 1 to 6.

Images