Servers and Programs

Abstract

To provide a server delay control device, a server delay control method and a program that perform packet transfer for applications having different application characteristics with a shorter delay in a server while reducing power consumption.SOLUTION: A server delay control device 200 includes: a data arrival notification unit 220 that notifies data processing APL 1 of data acquired by a data arrival monitoring unit 210 and passes the data to the data processing APL; and a sleep management unit 230 that causes a polling thread to sleep and cancels sleep of the polling thread by hardware interrupt when a packet arrives. The sleep management unit 230 controls timing of the sleep by permitting the hardware interrupt on the basis of characteristics of an application program.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to server and programs.

Background Art

[0002] Based on the progress of virtualization technologies such as NFV (Network Functions Virtualization), systems are being constructed and operated for each service. Also, from the form of constructing a system for each service, service functions are divided into reusable module units and operated on an independent virtual machine (VM: Virtual Machine or container, etc.) environment, and this form called SFC (Service Function Chaining) that enhances operability by using it as needed like a component is becoming the mainstream.

[0003] As a technology for constructing a virtual machine, a hypervisor environment composed of Linux (registered trademark) and KVM (kernel-based virtual machine) is known. In this environment, a Host OS (the OS installed on a physical server is called a Host OS) incorporating a KVM module operates in a memory area different from the user space called the kernel space as a hypervisor. In this environment, a virtual machine operates in the user space, and a Guest OS (the OS installed on the virtual machine is called a Guest OS) operates within the virtual machine.

[0004] Unlike a physical server running a Host OS, a virtual machine running a Guest OS uses all hardware, including network devices (such as Ethernet® card devices), to control registers necessary for interrupt handling from the hardware to the Guest OS and for writing from the Guest OS to the hardware. In such register control, notifications and processes that should be performed by the physical hardware are simulated by software, so performance is generally lower than in a Host OS environment.

[0005] In addressing this performance degradation, there are technologies that reduce hardware imitation and improve communication performance and versatility through a high-speed, unified interface, particularly when communicating from the Guest OS to the Host OS and external processes outside of the virtual machine. One such technology is virtio, a device abstraction technology, or paravirtualization technology, which has already been developed and is incorporated into many general-purpose operating systems, including Linux (registered trademark) and FreeBSD (registered trademark), and is currently in use.

[0006] In virtio, data exchange for data input / output such as console, file input / output, and network communication is defined by queue operations, using queues designed with ring buffers as a transport for unidirectional data transfer. By utilizing the virtio queue specifications and preparing the appropriate number and size of queues for each device at the time of Guest OS startup, communication between the Guest OS and the outside of the virtual machine can be achieved solely through 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] New API (NAPI) processes packets upon arrival by requesting a hardware interrupt followed by a software interrupt (see Non-Patent Document 1) (see Figure 19 below).

[0009] DPDK implements packet processing functionality in user space where applications run, and immediately harvests packets upon arrival from user space using a polling model. Specifically, DPDK is a framework for controlling the NIC (Network Interface Card), a task traditionally handled by the Linux kernel, within user space. The biggest difference from the Linux kernel's processing is its polling-based receiving mechanism called PMD (Pull Mode Driver). Normally, the Linux kernel generates an interrupt upon data arrival at the NIC, triggering the receiving process. In contrast, PMD uses a dedicated thread to continuously check for data arrival and perform receiving processing. PMD enables high-speed packet processing by eliminating overhead such as context switching and interrupts. DPDK significantly improves packet processing performance and throughput, allowing more time for data plane application processing. However, DPDK exclusively uses computer resources such as the CPU (Central Processing Unit) and NIC.

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

[0011] [Rx-side packet processing using the New API (NAPI)] Figure 19 is a schematic diagram of Rx-side packet processing using the New API (NAPI) implemented in Linux kernel 2.5 / 2.6 (see Non-Patent Document 1). As shown in Figure 19, the New API (NAPI) executes a data processing APL1 located in the user space 60 accessible to the user on a server equipped with OS 70 (e.g., Host OS), and performs packet forwarding between the NIC 11 of HW 10 connected to OS 70 and the data processing APL1.

[0012] OS70 includes kernel71, ring buffer72, and driver73, and kernel71 includes protocol processing unit74. Kernel71 is a core function of OS70 (for example, the Host OS), and it monitors hardware and manages the execution status of programs on a process basis. Here, kernel71 responds to requests from data processing APL1 and also transmits requests from HW10 to data processing APL1. Kernel71 processes requests from data processing APL1 via system calls (a user program running in unprivileged mode requests processing from the kernel running in privileged mode). Kernel71 transmits packets to data processing APL1 via Socket75. Kernel71 receives packets from data processing APL1 via Socket75.

[0013] Ring Buffer72 is managed by Kernel71 and resides in the server's memory space. Ring Buffer72 is a fixed-size buffer that stores messages output by Kernel71 as a log, and when it exceeds its upper limit, it is overwritten from the beginning.

[0014] Driver73 is a device driver used in kernel71 to monitor hardware. Note that Driver73 depends on kernel71, and if the kernel source code used to create it changes, it will become a different driver. In this case, you will need to obtain the relevant driver source code, rebuild it on the OS where the driver will be used, and then create the driver.

[0015] The protocol processing unit 74 performs protocol processing for L2 (Data Link Layer), L3 (Network Layer), and L4 (Transport Layer) as defined by the OSI (Open Systems Interconnection) reference model.

[0016] Socket75 is the interface that kernel71 uses for inter-process communication. Socket75 has a socket buffer and does not frequently perform data copying operations. The process for establishing communication via Socket75 is as follows: 1. The server creates a socket file to accept clients. 2. The server names the acceptance socket file. 3. The server creates a socket queue. 4. The server accepts the first connection from a client in the socket queue. 5. The client creates a socket file. 6. The client sends a connection request to the server. 7. The server creates a connection socket file in addition to the acceptance socket file. As a result of establishing communication, data processing APL1 can call system calls such as read() and write() on kernel71.

[0017] In the above configuration, Kernel71 receives notification of packet arrival from NIC11 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 and above, processes packets upon arrival using a hardware interrupt (hardIRQ) followed by a software interrupt (softIRQ). As shown in Figure 19, packet forwarding using the interrupt model involves waiting for interrupt processing (see symbol a in Figure 19), which increases the delay in packet forwarding.

[0018] The following describes the overview of packet processing on the NAPI Rx side. [Rx-side packet processing configuration using New API (NAPI)] Figure 20 is a diagram illustrating the overview of Rx-side packet processing by the New API (NAPI) in the area enclosed by the dashed line in Figure 19. <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 occurs on NIC11 and executes the requested processing (hardware interrupt); and netif_rx82, which is a software interrupt processing function unit.

[0019] <Networking layer> The Networking layer contains softIRQ83, a handler that is called when a processing request occurs in netif_rx82 and executes the requested processing (software interrupt), and do_softirq84, a control function unit that implements the software interrupt (softIRQ). It also contains net_rx_action85, a packet processing function unit that receives and executes software interrupts (softIRQ), poll_list86, which registers net device information indicating which device the hardware interrupt from NIC11 is from, netif_receive_skb87, which creates the sk_buff structure (a structure that allows Kernel71 to perceive the status of packets), and Ring Buffer72.

[0020] <Protocol layer> The protocol layer contains packet processing functions such as ip_rcv88 and arp_rcv89.

[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 within Kernel 71.

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

[0023] However, if NIC11 simply copies the packet that arrives in Ring Buffer72, Kernel71 will not be able to recognize that packet. Therefore, when a packet arrives, NIC11 raises a hardware interrupt (hardIRQ) to hardIRQ81 (see symbol c in Figure 20), and netif_rx82 executes the following process so that Kernel71 can recognize the packet. Note that hardIRQ81, enclosed in an ellipse in Figure 20, represents the handler, not the functional part.

[0024] netif_rx82 is a function that actually performs processing. When hardIRQ81 (handler) is raised (see reference d in Figure 20), it stores in poll_list86 the information of the net_device indicating which device the hardware interrupt from NIC11, which is one of the information of the content of the hardware interrupt (hardIRQ), belongs to. Then, netif_rx82 registers the queue trimming. Here, queue trimming means referring to the content of the packets accumulated in the buffer and deleting the corresponding queue entry from the buffer in consideration of the next processing to be performed for the processing of that packet. Specifically, upon receiving that packets are stuffed into Ring Buffer72, netif_rx82 uses the driver of NIC11 to register the subsequent queue trimming in poll_list86 (see reference e in Figure 20). As a result, queue trimming information due to packets being stuffed into Ring Buffer72 is registered in poll_list86.

[0025] Thus, in the <Device driver> of Figure 20, when NIC11 receives a packet, it copies the packet that has arrived at Ring Buffer72 by DMA transfer. Also, NIC11 raises hardIRQ81 (handler), and netif_rx82 registers the net_device in poll_list86 and schedules a software interrupt (softIRQ). Up to this point, the processing of the hardware interrupt in the <Device driver> of Figure 20 stops.

[0026] After that, netif_rx82 uses the information (specifically, pointers) in the queue stored in poll_list86 to trim the data stored in Ring Buffer72, raises it to softIRQ83 (handler) with a software interrupt (softIRQ) (see reference f in Figure 20), and notifies do_softirq84, which is the control function part of the software interrupt (see reference g in Figure 20).

[0027] do_softirq84 is the software interrupt control unit, and it defines various software interrupt functions (there are various types of packet processing, and interrupt processing is one of them; it defines interrupt processing). Based on this definition, do_softirq84 notifies net_rx_action85, which actually performs the software interrupt processing, of the request for the current (relevant) software interrupt (see symbol h in Figure 20).

[0028] When it's the turn of the softIRQ, net_rx_action85 calls a polling routine to pluck packets from Ring Buffer72 based on the net_device registered in poll_list86 (see code i in Figure 20), and plucks packets (see code j in Figure 20). At this time, net_rx_action85 continues plucking until poll_list86 is empty. Subsequently, net_rx_action85 notifies netif_receive_skb87 (see symbol k in Figure 20).

[0029] netif_receive_skb87 creates an sk_buff structure, analyzes the contents of the packet, and passes the processing to the subsequent protocol processing unit 74 (see Figure 19) according to the type. In other words, netif_receive_skb87 analyzes the contents of the packet and, when processing according to the contents of the packet,<Protocol layer> The process is then passed to ip_rcv88 (symbol l in Figure 20), and if it is L2, for example, the process is passed to arp_rcv89 (symbol m in Figure 20).

[0030] Figure 21 shows an example of video (30 FPS) data transfer. The workload shown in Figure 21 has a transfer rate of 350 Mbps and performs intermittent data transfer every 30 ms.

[0031] Figure 22 shows the CPU usage rate used by the busy poll thread in the KBP described in Patent Document 1. As shown in Figure 22, in KBP, the kernel thread occupies a CPU core to perform busy polling. Even with intermittent packet reception as shown in Figure 21, KBP always uses the CPU regardless of whether packets have arrived or not, resulting in high power consumption.

[0032] Next, I will explain the DPDK system. [DPDK System Configuration] Figure 23 shows the configuration of the DPDK system that controls the HW110 equipped with accelerator 120. The DPDK system consists of HW110, OS140, DPDK150 (a high-speed data transfer middleware), and data processing APL1, all located on user space160. Data processing APL1 is packet processing that takes place prior to the execution of APL. HW110 communicates with data processing APL1 for sending and receiving data. In the following description, as shown in Figure 23, the data flow in which data processing APL1 receives packets from HW110 is referred to as Rx-side reception, and the data flow in which data processing APL1 sends packets to HW110 is referred to as Tx-side transmission.

[0033] The HW110 includes an accelerator 120 and a NIC 130 (physical NIC) for connecting to a communication network. The accelerator 120 is a computing unit hardware that performs specific calculations at high speed based on input from the CPU. Specifically, the accelerator 120 is a PLD (Programmable Logic Device) such as a GPU (Graphics Processing Unit) or FPGA (Field Programmable Gate Array). In Figure 23, the accelerator 120 includes multiple 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] By offloading part of the data processing APL1's processing to accelerator 120, performance and power efficiency that cannot be achieved with software (CPU processing) alone are realized. In large-scale server clusters, such as data centers that utilize NFV (Network Functions Virtualization) or SDN (Software Defined Networking), it is conceivable that accelerator 120 like the one described above would be applied.

[0035] NIC130 is NIC hardware that implements a network interface and includes Rx queue 131 and Tx queue 132 that hold data in a first-in, first-out list structure. NIC130 is connected to, for example, the opposing device 170 via a communication network to send and receive packets. Note that NIC130 may be, for example, a SmartNIC, which is a NIC with an accelerator. A SmartNIC is a NIC that can reduce the CPU load by offloading resource-intensive processes, such as IP packet processing, which can cause a decrease in processing power.

[0036] DPDK150 is a framework for controlling NICs in user space 160, and specifically consists of high-speed data transfer middleware. DPDK150 has a polling-based receiving mechanism, PMD (Poll Mode Driver) 151 (a driver that can select between polling mode and interrupt mode for data arrival). PMD151 has a dedicated thread that continuously checks for data arrival and processes the reception.

[0037] DPDK150 implements packet processing functionality in user space 160 where APL operates, and enables reduced packet forwarding delay by immediately harvesting packets upon arrival from user space 160 using a polling model. In other words, DPDK150 harvests packets using polling (busy polling of the queue by the CPU), resulting in no waiting and low latency.

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

[0039] By the way, both the interrupt model and the polling model for packet forwarding have the following challenges. The interrupt model uses software interrupt processing to process packets, triggered by the kernel receiving an event (hardware interrupt) from the hardware. Therefore, because the interrupt model relies on interrupt (software interrupt) processing for packet forwarding, it faces challenges such as conflicts with other interrupts and delays if the target CPU is occupied by a higher-priority process. In this case, congestion in interrupt processing further increases the waiting delay. For example, packet forwarding using an interrupt model relies on interrupt processing to forward packets, which causes delays in packet forwarding due to the waiting time for interrupt processing.

[0040] This section provides additional information about the mechanism by which delays occur in interrupt models. In a typical kernel, packet forwarding is handled by a hardware interrupt followed by a software interrupt. When a software interrupt occurs during packet forwarding, the software interrupt process cannot be executed immediately under the following conditions (1) to (3). Therefore, the interrupt process is arbitrated by a scheduler such as ksoftirqd (a kernel thread for each CPU that is executed when the software interrupt load becomes high), and the interrupt process is scheduled, resulting in a wait of the order of milliseconds. (1) When it conflicts with other hardware interrupt handlers (2) When it conflicts with other software interrupt handlers (3) When other processes with higher priority, kernel threads (migration threads, etc.), or the interrupt target CPU are in use. Under the above conditions, the software interrupt processing 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 January 11, 2022], Internet < URL: http: / / http: / / lwn.net / 2002 / 0321 / a / napi-howto.php3 > [Overview of the project] [Problems that the invention aims to solve]

[0043] When a receiving polling thread is deployed within the kernel, as in the server network delay control device (KBP) described in Patent Document 1, it becomes difficult to perform receiving processing that takes into account the characteristics of each application, due to the pursuit of generality. As a result, low latency and power saving in the receiving process may be compromised. For example, the above power-saving server network delay control device has a function to immediately sleep the polling thread when the receiving process is finished and there is no further data arrival (poll_list becomes empty). This function is generally expected to improve power saving. On the other hand, if the application has the characteristic of "receiving data immediately from the kernel without requiring kernel protocol processing", the receiving process is likely to be completed immediately and the poll_list is likely to become empty, so the thread may enter sleep mode even if data is being received continuously. As a result, wake-up due to hardware interrupts may occur frequently, compromising power saving and low latency.

[0044] In light of this background, the present invention was made, and its objective is to reduce power consumption and minimize latency within the server while performing packet forwarding, even for applications with different characteristics. [Means for solving the problem]

[0045] In order to solve the aforementioned problems, A server that performs data processing including polling, the server is equipped with a NIC in hardware, a HardIRQ handler located in the OS, a data arrival monitoring unit in user space that monitors data arrivals, a sleep unit that pauses the data arrival monitoring, and a sleep management unit that resumes the data arrival monitoring, wherein when the sleep unit has paused the data arrival monitoring, the sleep management unit, triggered by the arrival of a packet to the NIC, starts the HardIRQ handler located in the OS, receives a notification from the HardIRQ handler, notifies the data arrival monitoring unit, and resumes the data arrival monitoring. The server was characterized by the following features. [Effects of the Invention]

[0046] According to the present invention, packet forwarding can be performed with reduced power consumption and low latency within the server, even for applications with different characteristics. [Brief explanation of the drawing]

[0047] [Figure 1] This is a schematic diagram of the server-internal delay control system according to the first embodiment of the present invention. [Figure 2] This is a diagram illustrating the operation of a server-internal delay control system according to the first embodiment of the present invention. [Figure 3] This is a flowchart of the transfer process during Polling Thread operation of the server-internal delay control device of the server-internal delay control system according to the first embodiment of the present invention (when the data arrival notification unit does not process packets). [Figure 4] This diagram illustrates the operation of the transfer process (when the data arrival notification unit does not process packets) during the operation of the Polling Thread of the server-internal delay control device of the server-internal delay control system according to the first embodiment of the present invention. [Figure 5] This is a flowchart of the transfer process (when the data arrival notification unit processes packets) during the operation of the Polling Thread of the server-internal delay control device of the server-internal delay control system according to the first embodiment of the present invention. [Figure 6] This diagram illustrates the operation of the transfer process (when the data arrival notification unit processes packets) during the operation of the Polling Thread of the server-internal delay control device of the server-internal delay control system according to the first embodiment of the present invention. [Figure 7] This is a flowchart showing the processing steps from when the Polling Thread of the server-internal delay control device in the server-internal delay control system according to the first embodiment of the present invention wakes up from the sleep state. [Figure 8] This diagram illustrates the operation of the Polling Thread of the server-internal delay control device in the server-internal delay control system according to the first embodiment of the present invention, from the sleep state until it wakes up. [Figure 9] This is a schematic diagram of a server-internal delay control system according to a second embodiment of the present invention. [Figure 10] This is an explanatory diagram illustrating the operation of the characteristic information collection unit of the server-internal delay control device in the server-internal delay control system according to the second embodiment of the present invention. [Figure 11] This is an explanatory diagram illustrating the operation of the logic distribution unit of the server-internal delay control device of the server-internal delay control system according to the second embodiment of the present invention. [Figure 12]This is a flowchart illustrating the process of changing the logic of the data arrival monitoring unit in the server delay control device of the server delay control system according to the second embodiment of the present invention. [Figure 13] This is an explanatory diagram illustrating the operation of logic changes to the data arrival monitoring unit in the server delay control device of the server delay control system according to the second embodiment of the present invention. [Figure 14] This is a flowchart illustrating the process of changing the logic of the data arrival notification unit in the server delay control device of the server delay control system according to the second embodiment of the present invention. [Figure 15] This is an explanatory diagram illustrating the operation of logic changes to the data arrival notification unit in the server delay control device of the server delay control system according to the second embodiment of the present invention. [Figure 16] This is a flowchart illustrating the process of changing the logic to the Sleep management unit in the server-internal delay control device of the server-internal delay control system according to the second embodiment of the present invention. [Figure 17] This is an explanatory diagram illustrating the operation of logic changes to the Sleep management unit in the server delay control device of the server delay control system according to the second embodiment of the present invention. [Figure 18] This is a hardware configuration diagram showing an example of a computer that implements the functions of the in-server delay control device of the in-server delay control system according to the first and second embodiments of the present invention. [Figure 19] This is a schematic diagram of Rx-side packet processing using the New API (NAPI) implemented in Linux kernel 2.5 / 2.6. [Figure 20] Figure 19 shows an overview of Rx-side packet processing by the New API (NAPI) in the area enclosed by the dashed line. [Figure 21] This figure shows an example of video (30 FPS) data transfer. [Figure 22] This figure shows the CPU usage rate used by the busy poll thread in the KBP described in Patent Document 1. [Figure 23] This diagram shows the configuration of a DPDK system that controls hardware equipped with an accelerator. [Modes for carrying out the invention]

[0048] The following describes a server-internal delay control system, etc., in an embodiment for carrying out the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. (First Embodiment) Figure 1 is a schematic diagram of a server-internal delay control system according to the first embodiment of the present invention. The same reference numerals are used for components identical to those in Figure 23. As shown in Figure 1, the server-internal delay control system 1000 executes a data processing APL (Application) 1 (application program; hereinafter referred to as "application" as appropriate) located in the user space 160 (user space) accessible to the user on a server equipped with an OS (e.g., Host OS) 140, and performs packet forwarding between the NIC 130 (device) of the HW 110 connected to the OS and the data processing APL 1. The server-internal delay control system 1000 includes a server-internal delay control device 200 and a data processing APL1 located on the HW110, OS140, and user space160. Data processing APL1 is packet processing that takes place prior to the execution of APL. HW110 communicates with the data processing unit APL1 for data transmission and reception. The HW110 includes a NIC130 (device) for connecting to a communication network. The HW110 may also include an accelerator 120 as shown in Figure 23.

[0049] [Server-based delay control device] The server-internal delay control device 200 is a polling thread located in user space. A key feature is that the polling thread (server-internal delay control device 200) is located in user space rather than within the OS kernel. Because the data reception processing of the polling thread (server-internal delay control device 200) is defined in user space, the method of reception processing can be changed to match the application characteristics (characteristics of the application program).

[0050] The server-internal delay control device 200 includes a data arrival monitoring unit 210, a data arrival notification unit 220, and a sleep management unit 230.

[0051] <Data arrival monitoring unit 210> The data arrival monitoring unit 210 monitors the device's receive queue by polling, and when a packet arrives, it acquires the data and passes it on to the data arrival notification unit 220. Specifically, the data arrival monitoring unit 210 monitors the device's receive queue by polling, and if a packet has arrived, it refers to the packet held in the ring buffer and performs harvesting by deleting the corresponding queue entry from the ring buffer based on the next processing to be performed. In other words, the data arrival monitoring unit 210 monitors the device's receive queue by polling and performs immediate harvesting. The data arrival monitoring unit 210 checks whether data has arrived in the device's receive queue at a predetermined timing based on the characteristics of the application.

[0052] The data arrival monitoring unit 210 checks whether data has arrived in the device's receive queue after a predetermined period of downtime. In other words, the data arrival monitoring unit 210 monitors while reducing the number of CPU cycles by inserting temporary pauses in polling according to the characteristics of the application.

[0053] <Data arrival notification unit 220> The data arrival notification unit 220 notifies the application of the data acquired by the data arrival monitoring unit 210 and passes it on.

[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, and based on the characteristics of the application program, executes the packet processing function, and when the packet processing function is executed, does not notify the application program. Thus, 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 a hardware interrupt and sleeping based on the characteristics of the application. The Sleep management unit 230 causes the Polling Thread to sleep and permits a HW interrupt, or prohibits a HW interrupt and wakes up the Polling Thread. At this time, the timing of sleeping can be controlled according to the characteristics of the application.

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

[0058] During Polling, when starting to sleep, the Sleep management unit 230 stops the Polling Thread, permits a HW interrupt, 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 to control the timing of enabling hardware interrupts and going to sleep, depending on the characteristics of the application. For example, even if the driver's receive queue becomes empty, it can continue polling in the case of an application where packets arrive immediately.

[0060] The Sleep management unit 230 is woken by a hardware interrupt that occurs when a packet arrives during sleep mode, and starts polling while disabling hardware interrupts. At this time, the CPU operating frequency and voltage are reset to higher levels.

[0061] The sleep management unit 230 compares the elapsed time since the packet was not received with a time appropriate for the application's characteristics. If the elapsed time since the packet was not received is greater than or equal to the time appropriate for the application's characteristics, it enables a hardware interrupt and puts the thread to sleep.

[0062] The operation of the server-internal delay control system 1000, configured as described above, will be explained below. [Overall operation of the server-internal delay control system 1000] Figure 2 is a diagram illustrating the operation of the server-internal delay control system 1000 shown in Figure 1. The arrows (symbols) aa to gg in Figure 2 indicate the flow of Rx-side packet processing. When NIC130 receives a packet (or frame) within a frame from the opposing device, it bypasses OS140 and sends the packet to the data arrival monitoring unit 210 of the Polling Thread (server-internal delay control device 200).

[0063] <Operation of the data arrival monitoring unit 210> The data arrival monitoring unit 210 monitors the device's receive queue by polling (Figure 2) <polling>(See symbol aa), when a packet arrives, it is captured and passed to the data arrival notification unit 220 (see symbol bb in Figure 2). When the application's latency requirements are not strict or the packet arrival interval is not short, the number of CPU cycles can be reduced while receiving and monitoring can be performed by pausing the polling process (power saving).

[0064] The data arrival monitoring unit 210 launches a polling thread to monitor packet arrivals and directly monitors the receive queue of the network device. When a packet arrives, it is immediately harvested without waiting, enabling low-latency packet processing ("Feature 1: Low-latency packet forwarding").

[0065] <Operation of the data arrival notification unit 220> The data arrival notification unit 220 notifies the data processing APL (Application) 1 of the data arrival monitoring unit 210 and passes it on (Figure 2) <notify>; Symbol cc reference).

[0066] Here, for an application that processes packets sequentially, it is possible to select an arrival notification method according to the characteristics of the application, such as "notify immediately when data arrives" 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, it is also possible to reduce the overhead of arrival notification and process packets by having a function to 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 application of the arrived data, 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 FIG. 2 <interrupt>(See code dd). When hardwire81 (handler) is started up, the Sleep management unit 230 is woken up by a HW interrupt that occurs when a packet arrives during sleep (Figure 2). <wakeup>(See code ee), Polling starts while HW interrupts are disabled. In other words, the Sleep management unit 230 puts the Polling Thread to sleep when no packets arrive, and when packets arrive again, it is woken up by HardIRQ81 and starts polling.

[0069] The Sleep management unit 230 puts the Polling Thread to sleep and enables hardware interrupts, or disables hardware interrupts and wakes the Polling Thread (Figure 2). <enable disable>(See symbol ff). In this case, the timing of the sleep function can be controlled according to the characteristics of the application.

[0070] The Sleep management unit 230, when polling, stops the polling thread and enables hardware interrupts before starting sleep (Figure 2).<Polling Start / stop> (See code gg). In this case, 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 to control the timing of enabling hardware interrupts and going to sleep, depending on the characteristics of the application. For example, even if the driver's receive queue becomes empty, it can continue polling in the case of an application where packets arrive immediately.

[0072] The Sleep Management Unit 230 puts the Polling Thread to sleep when no packets arrive. This reduces unnecessary CPU usage and saves power. Further power savings can be achieved by lowering the CPU operating voltage and frequency when the system goes to sleep ("Feature 3: Power Saving"). Furthermore, by waking the sleeping Polling Thread with the HardIRQ handler 81 upon packet arrival, it is possible to start it immediately while avoiding softIRQ contention.

[0073] <Method for determining parameters U, T, and K> The method for determining the parameters U, T, and K used in the flowcharts in Figures 3 and 5 below will be explained. The Polling Thread (server-internal delay control device 200) uses the data arrival monitoring interval U (parameter of the data arrival monitoring unit 210), the time T from when a packet is not received until sleep mode is entered (parameter of the sleep management unit 230), and the batch size K of packets to notify or process (parameter of the data arrival notification unit 220). In the first embodiment, parameters U, T, and K are fixed values ​​set in advance by the operator. In the second embodiment described below, parameters U, T, and K are dynamically set via the logic management unit 310 (for the sake of explanation, they are described together here).

[0074] Example of determining the data arrival monitoring interval U There are fixed values ​​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 management unit 310 (described later), there are two examples: Example 1: The data arrival monitoring unit 210 obtains the packet arrival frequency and sets U so that arrival monitoring can be performed at a frequency close to that. Example 2: Obtain the maximum allowable delay from the application or an external controller, and configure U to enable arrival monitoring at a frequency that can maintain that delay.

[0075] Example of determining the time T from when a packet is not received until the system enters Sleep mode. There are fixed values ​​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 management unit 310, there are two examples: Example 1: The Sleep management unit 230 obtains the time from entering sleep mode until waking up, and if this interval is short enough to negatively affect delay time and power saving, it increases T. Example 2: The packet arrival frequency is obtained from the data arrival monitoring unit 210, the application, or an external controller, and if it is high, T is reduced as much as possible to enable Sleep.

[0076] Example of determining the batch size K for notifying or processing packets. Let's discuss the batch size K. That is, when the data arrival monitoring unit 210 has multiple packets accumulated in the Ring_Buffer area, it collects multiple packets together and passes them to the subsequent protocol processing unit (not shown in the diagram). The number of packets collected together is called a quota, and this is called batch processing, and the number of these processes is called the batch size (number of batch processes). There are fixed values ​​set in advance by the operator, and dynamic settings via the logic management unit 310 (described later). In the case of dynamic settings via the logic management unit 310 (described later), the following is an example. Example 1: Obtain batch processing information from the application and set K accordingly.

[0077] Next, the forwarding process during Polling Thread operation will be described with reference to Figures 3 to 6. The forwarding process during Polling Thread operation can be described 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 does process packets (see Figures 5 and 6). Each case will be described separately.

[0078] [Transfer processing during Polling Thread operation (when the data arrival notification unit 220 does not process packets)] <Flowchart> Figure 3 is a flowchart of the transfer process during Polling Thread operation (when the data arrival notification unit 220 does not process packets).

[0079] In step S11, the data arrival monitoring unit 210 checks whether data has arrived in the NIC 130's receive queue at intervals appropriate to the application characteristics. For example, the data arrival monitoring unit 210 pauses for a time U before checking. In step S12, the data arrival monitoring unit 210 determines whether or not data has arrived in the receive queue. If no data has arrived in the receive 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 has not arrived 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 has not arrived 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 operation frequency and operation voltage, puts the Polling Thread to sleep, and ends the processing of this flow.

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

[0088] <Operation Diagram> Figure 4 illustrates the operation of the transfer process during Polling Thread operation (when the data arrival notification unit 220 does not process packets). When NIC130 receives a packet, it copies the packet directly to the Ring Buffer (a buffer in main memory) via DMA (Direct Memory Access) without going through the CPU (Figure 4). <polling>(See symbol aa). This Ring Buffer is pre-configured so that it can be accessed directly from the Polling Thread in User Space 160 without going through the OS kernel.

[0089] NIC130 triggers an interrupt on the CPU running the Polling Thread. The CPU then notifies the Polling Thread to wake up in the context of a hardware interrupt, which wakes up the Sleep Management Unit 230. From this point onward, the Polling Thread operates on the CPU.

[0090] The Sleep Management Unit 230 sets the CPU frequency to a high level and disables interrupts to that CPU (Figure 4). <enable>(See symbol ff). The CPU frequency can also be changed from User Space 160 by configuring the CPUgovernor.

[0091] The Sleep Management Unit 230 instructs the Data Arrival Monitoring Unit 210 to start Polling (Figure 4)<Polling stop> (See code gg). Specifically, the above Polling start instruction involves the Sleep management unit 230 calling a function that handles the processing of the data arrival monitoring unit 210.

[0092] The data arrival monitoring unit 210 performs arrival confirmation on the Ring Buffer area where packets are DMA'd at arrival confirmation intervals determined in advance by the operator, and if a packet has arrived, it transmits the address information (pointer) of that packet to the data arrival notification unit 220 (see symbol bb in Figure 4).

[0093] The data arrival notification unit 220 checks whether the number of pointer information transmitted from the data arrival monitoring unit 210 has reached the batch size for which packets are notified, which has been predetermined by the operator (steps S14 to S15 in Figure 3).

[0094] If the number of transmitted pointer information points reaches the batch size for notifying the determined packets, the process proceeds to the next step. Otherwise, the process returns to packet arrival confirmation by the data arrival monitoring unit 210.

[0095] The data arrival notification unit 220 stores address information in the shared memory of the application and the Polling Thread, creates a thread in which the application runs, and executes processing within that thread (Figure 4). <notify>; see sign cc).

[0096] If the period during which no packets have been received continues for a time predetermined by the operator, the data arrival monitoring unit 210 calls the Sleep management unit 230 (step S12 in Figure 3). The data arrival monitoring unit 210 returns, and processing is returned to the Sleep management unit 230.

[0097] The Sleep management unit 230 reduces the CPU frequency, enables interrupts to the CPU, and puts the Polling Thread into the Sleep state (step S19 in Figure 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 run on the same thread, the processing will be performed within the Polling Thread.

[0099] <Flowchart> Figure 5 is a flowchart of the transfer process during Polling Thread operation (when the data arrival notification unit 220 processes the packets). Steps that perform the same processing as in the flow in Figure 3 are given the same numbers and their explanations are omitted. In step S15, the data arrival notification unit 220 determines whether N ≥ K. If N ≥ K (S15: Yes), the unit proceeds to step S21. In step S21, the data arrival notification unit 220 processes the packet (for example, forwarding it to another server) and returns to step S11. The data arrival notification unit 220 also resets the number of packets that have arrived so far, N, to 0. Because the data arrival notification unit 220 processes the packet, there is no process to notify the application of the data arrival and hand over the data, as shown in step S16 of Figure 3.

[0100] <Operation Diagram> Figure 6 illustrates the operation of the transfer process during Polling Thread operation (when the data arrival notification unit 220 processes packets). Components identical to those in the operation diagram in Figure 4 are given the same numbers and their explanations are omitted.

[0101] The data arrival notification unit 220 processes the packets. The packet processing performed by the data arrival notification unit 220 within the Polling Thread is relatively low-load, such as forwarding packets to another server.

[0102] [Processing for the polling thread to wake up from sleep state] Figure 7 is a flowchart showing the process from when the Polling Thread wakes up from the Sleep state. Figure 8 is an explanatory diagram of its operation. The same numbers are used for components that are identical to those in the explanatory diagram in Figure 2. In step S31, data arrives at NIC130, and an interrupt is sent from NIC130 to the CPU. In step S32, the hardware interrupt context is established in the relevant CPU. In step S33, under the context of a hardware interrupt, the Polling Thread's Sleep management unit 230 is woken up.

[0103] Specifically, as shown in Figure 8, when a packet arrives, NIC130 raises a hardware interrupt (hardIRQ) to hardIRQ81 (handler) (Figure 8) <interrupt>(See code dd). When hardwire81 (handler) is started up, the Sleep management unit 230 is woken up by a HW interrupt that occurs when a packet arrives during sleep (Figure 8). <wakeup>(See code ee), Polling starts while disabling hardware interrupts.

[0104] In step S34, the Sleep management unit disables interrupts from NIC130 (Figure 8). <enable>(See symbol ff), the CPU operating frequency and operating voltage are set to high, and the Polling of the data arrival monitoring unit 210 is started. When Polling is performed, the Sleep management unit 230 stops the Polling Thread and enables HW interrupts when starting Sleep (Figure 8).<Polling Start > ; see sign gg).

[0105] (Second Embodiment) Figure 9 is a schematic diagram of a server-internal delay control system according to a second embodiment of the present invention. Components identical to those in Figure 1 are denoted by the same reference numerals, and the explanation of the redundant parts is omitted. As shown in Figure 9, the server-internal delay control system 1000A includes a server-internal delay control device 300 and a data processing APL1 located on the HW110, OS140, and user space160.

[0106] The server-internal delay control device 300 includes a logic management unit 310 in addition to the data arrival monitoring unit 210, data arrival notification unit 220, and sleep management unit 230 (hereinafter referred to as "each functional unit") of the server-internal delay control device 200 shown in Figure 1. The logic management unit 310 collects application characteristic information and thread processing information, and based on the collected information, modifies the processing logic of at least one of the following functional units: the data arrival monitoring unit 210, the data arrival notification unit 220, and the sleep management unit 230, in the case of an application where the load fluctuates depending on the time of day, and the processing method and processing speed fluctuate accordingly.

[0107] <Logic Management Unit 310> The logic management unit 310 dynamically selects a processing logic and notifies each function unit when multiple processing logics are possible for each functional unit of the server-internal delay control device 200 shown in Figure 1. The logic management unit 310 maintains low latency and low power consumption by changing the processing logic of each functional unit within the Polling Thread to alter the receiving processing method in applications where the load fluctuates depending on the time of day, causing the processing method and processing speed to change.

[0108] The logic management unit 310 consists of two functional units: a characteristic information collection unit 311 and a logic distribution unit 312. The characteristic information collection unit 311 collects characteristics of the application and traffic from the application and the Polling Thread. The characteristic information collection unit 311 collects the information necessary to appropriately determine logic suitable for characteristics that vary over time.

[0109] The logic distribution unit 312 determines the appropriate logic for each functional unit based on the characteristic information of the application and traffic 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 that is appropriate for the time-varying characteristics. The characteristic information collection unit 311 and the logic distribution unit 312 will be described in detail below with reference to the operation diagram.

[0110] <Characteristic Information Collection Unit 311> First, let me explain the characteristic information collection unit 311. Figure 10 is an explanatory diagram of the operation of the characteristic information collection unit 311. The characteristic information collection unit 311 collects characteristic information from applications and polling threads. The characteristic information collection unit 311 collects characteristic information of the application and processing information of the Polling Thread and passes it to the logic distribution unit 312. The characteristic information of the application and processing information of the Polling Thread are information used to determine the logic of each functional unit. The collected information is used to determine the logic appropriate for each functional unit.

[0111] This section describes examples of application characteristic information. An example of application characteristic information is "changes in the application's packet processing method." For example, if the load on the Application Logic increases and the packet processing method is changed from sequential processing to batch processing, the characteristic information collection unit 311 collects that information (see code hh in Figure 10). This information is used, for example, to change the processing logic of the data arrival notification unit 220 from "notifying the application sequentially when data arrives" to "notifying the application after K data have arrived."

[0112] This section describes an example of processing information for a Polling Thread. An example of information processed by a polling thread is "statistical information on the time from when the user enters sleep mode until they wake up." For example, if there is an increase in cases where users wake up immediately after entering Sleep mode, this information is collected (see symbol ii in Figure 10). This information is used, for example, to change the logic by which the Sleep management unit 230 initiates Sleep mode, from "instant Sleep when packets are not received" to "Sleep after a certain period of time has passed since packets were not received."

[0113] As an example of the information used to determine the logic of each functional unit, application characteristic information and Polling Thread processing information were used. However, information can be received from other systems and used to select the logic, rather than being limited to characteristic information from within the same server, such as from the application or Polling Thread. For example, if the server-internal 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 the higher-level controller, the RIC (RAN Intelligent Controller), and use this information to help select the appropriate logic.

[0114] <Logic Distribution Department 312> Next, we will explain the logic distribution unit 312. Figure 11 is an explanatory diagram of the operation of the logic distribution unit 312. 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, thereby changing the logic of each functional unit.

[0115] • Example of data arrival monitoring logic distribution When the application's latency requirements weaken or the data arrival frequency decreases, it may be acceptable to reduce the data arrival monitoring frequency for power saving purposes. In this case, the "busy loop data arrival monitoring" method can be changed to, for example, "data arrival monitoring once every 1 μs" (see the symbol jj in Figure 11).

[0116] • Example of data arrival notification logic delivery When an application's processing changes from sequential to batch processing, it may be better to batch the data arrival notifications as well, for lower latency and power efficiency. In this case, the logic changes from "sequentially notifying the application of data arrival" to "notifying the application of data arrival after K data items have arrived" (see the symbol kk in Figure 11).

[0117] • Example of Sleep start logic delivery If the system frequently wakes up immediately after going to sleep due to an interrupt, the logic is changed from "sleep immediately when no data arrives" to "sleep Tμs after no data arrives" to prevent increased delay and power consumption due to excessive interrupts (see symbol ll in Figure 11).

[0118] The operation of the server-internal delay control system 1000A, configured as described above, will be explained below. [Overall operation of the server-internal delay control system 1000A]

[0119] <Settings> The logic management unit 310 operates on a different CPU than the polling thread. A shared memory exists between each functional unit within the Polling Thread and the logic management unit 310.

[0120] <Operation 1> When NIC130 receives a packet, it copies the packet directly to the Ring Buffer (a buffer in main memory) via DMA (Direct Memory Access), bypassing the CPU. This Ring Buffer is pre-configured to allow direct access from the User Space Polling Thread without going through the OS kernel.

[0121] NIC130 triggers an interrupt on the CPU running the Polling Thread, and that CPU, in the context of a hardware interrupt, notifies the Polling Thread to wake up, which in turn wakes up the Sleep Management Unit 230. From this point onward, a polling thread will run on that CPU.

[0122] The Sleep Management Unit 230 sets the CPU frequency to a high level and disables interrupts to that CPU. The CPU frequency can also be changed from User Space by configuring the CPUgovernor.

[0123] The Sleep management unit 230 records the time from when the user enters sleep mode until they wake up, and stores it in a shared memory 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 that handles the processing of the Data Arrival Monitoring Unit 210). At this time, the Sleep Management Unit 230 reads the time information from when a packet is not received until sleep from the shared memory area with the Logic Management Unit 310, and calls the function that handles the processing of the Data Arrival Monitoring Unit 210, specifying this value as an argument.

[0125] The data arrival monitoring unit 210 refers to the shared memory with the logic management unit 310 and reads the arrival confirmation interval. At this arrival confirmation interval, it checks for arrival in the Ring Buffer area where packets are DMA'd, and if a packet has arrived, it transmits the address information (pointer) of that packet to the data arrival notification unit 220.

[0126] The data arrival notification unit 220 checks whether the number of pointer information transmitted from the data arrival monitoring unit 210 has reached the batch size written in the shared memory with the logic management unit 310. If the number of pointer information has reached the batch size written in the shared memory with the logic management unit 310, the following operation is performed. Otherwise, the process returns to the arrival confirmation operation of the data arrival monitoring unit 210 described above and the loop is executed.

[0127] The data arrival notification unit 220 stores address information in the shared memory of the application and the Polling Thread, creates a thread in which the application runs, and executes processing within that thread. If the operator has configured the application logic (data processing APL1) to run on the same thread, the processing will be performed within the Polling Thread.

[0128] In the above scenario, if the time specified as an argument has elapsed while no packets have arrived, the data arrival monitoring unit 210 calls the Sleep management unit 230. That is, the data arrival monitoring unit 210 returns, and 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 Polling Thread operation to the shared memory with the logic management unit 310.

[0129] The Sleep management unit 230 lowers the CPU frequency, enables interrupts to the CPU, and puts the Polling Thread into a sleep state.

[0130] The application (data processing APL1) writes to the shared memory with the logic management unit 310 as needed when the number of batches processed changes depending on the load. If the application runs in a separate thread from the polling thread, a separate shared memory must be set up in advance between the application and the logic management unit 310.

[0131] <Operation 2> The following processes run on a separate CPU from the Polling Thread and operate temporally independently. The following <Action 2> and the above <Action 1> can occur in parallel. The characteristic information collection unit 311 cycles through and monitors each shared memory with the Polling Thread's functional units, and if a write operation is performed to the shared memory, it executes the following process.

[0132] The data arrival frequency is written to the shared memory with the data arrival monitoring unit 210. If this value is smaller than the current data arrival confirmation interval, the new 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 a new data arrival confirmation interval to the shared memory with the data arrival monitoring unit 210.

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

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

[0136] The time from entering sleep mode to waking up is written to the shared memory with the sleep management unit 230. If this value is smaller than a predetermined threshold (for example, 5 μs) (the threshold varies depending on the system, so prior configuration is required), it is decided to extend the time from when a packet is not received until entering sleep mode by 5 μs, and the logic distribution unit 312 is called (a function corresponding to the logic distribution unit 312 is called).

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

[0138] [Operation of Logic Management Unit 310] Next, we will explain an example of the processing of the logic management unit 310 with reference to the flowcharts and operation diagrams shown in Figures 12 to 17.

[0139] <Example of logic changes to the data arrival monitoring unit 210> First, as an example of processing by the logic management unit 310, we will explain an example of logic modification to the data arrival monitoring unit 210. Figure 12 is a flowchart showing the logic change process for the data arrival monitoring unit 210. Figure 13 is an explanatory diagram of its operation. Components identical to those in Figure 11 are numbered the same way. In the flow shown in Figure 12, in step S41, the data arrival monitoring unit 210 acquires the packet arrival frequency and periodically notifies the characteristic information collection unit 311 (see the symbol mm in Figure 13). For example, the data arrival monitoring unit 210 transmits the packet arrival frequency to the characteristic information collection unit 311 at the time when polling is put to sleep.

[0140] In step S42, the characteristic information collection unit 311 compares the packet arrival frequency with the current arrival monitoring interval. If packet arrival frequency < 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, widen it by 1 μs) and transmits the logic change to the logic distribution unit 312 (see the code nn in Figure 13).

[0142] In step S45, the logic distribution unit 312 distributes the logic to the data arrival monitoring unit 210, widening the arrival monitoring interval and ending 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), in step S46 the characteristic information collection unit 311 decides to narrow the arrival monitoring interval and transmits the logic change to the logic distribution unit 312. For example, the characteristic information collection unit 311 transmits that the arrival monitoring interval should be narrowed by 1 μs (see the code nn in Figure 13).

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

[0145] <Example of logic change to data arrival notification unit 220> Next, as an example of processing by the logic management unit 310, we will describe an example of logic modification to the data arrival notification unit 220. Figure 14 is a flowchart showing the process of changing the logic of the data arrival notification unit 220. Figure 15 is a diagram illustrating its operation. Components identical to those in Figure 11 are numbered the same way. In the flow shown in Figure 14, if the data processing APL1 (application) changes the number of batches in step S51, it notifies the logic management unit 310 of that change (see symbol oo in Figure 15).

[0146] In step S52, the characteristic information collection unit 311 decides to notify the data arrival with the changed batch processing number and transmits the logic change to the logic distribution unit 312.

[0147] In step S53, the logic distribution unit 312 distributes the number of batch processes to the data arrival notification unit 220 (see reference symbol pp in FIG. 15), causing it to 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 logic change to the Sleep management unit 230 will be described. FIG. 16 is a flowchart of the processing of 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 that information to the characteristic information collection unit 311 (see reference symbol 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, assume an average time of 5 μs from when entering Sleep until being woken up.

[0150] In step S63, the characteristic information collection unit 311 discriminates whether the average time from when entering Sleep until being woken up is 5 μs. When the average time from when 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 symbol rr in FIG. 17).

[0151] In step S65, the logic distribution unit 312 distributes logic to the data arrival notification unit 220, changing the time from when a packet is not received until the unit enters Sleep mode, and then terminates the processing of this flow.

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

[0153] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls the various parts of the server-internal delay control devices 200 and 300 shown in Figures 1 and 9. The ROM 902 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0154] The CPU 901 controls input devices 910, such as a mouse or keyboard, and output devices 911, such as a display, via the input / output interface 905. The CPU 901 acquires data from the input devices 910 via the input / output interface 905 and outputs the generated data to the output devices 911. In addition to the CPU 901, a GPU (Graphics Processing Unit) or the like may also be used as a processor.

[0155] The HDD 904 stores programs executed by the CPU 901 and data used by such programs. The communication I / F 906 receives data from other devices via a communication network (e.g., 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 processing 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), PD (Phase change rewritable Disk), a magneto-optical recording medium such as a MO (Magneto Optical disk), a magnetic recording medium, a conductor memory tape medium, or a semiconductor memory, etc.

[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 processing from the recording medium 912. Additionally, the CPU 901 may read a program related to the target processing 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 a host in a VM (Virtual Machine) configuration and a Polling Thread arranged in a guest. By doing so, in a virtual server configuration system using VMs, packet forwarding can be performed with reduced latency within the server, without modifying the APL, on either the Host OS or the Guest OS.

[0159] <Example of application to container configuration> The present invention can also be applied to polling threads deployed in a container configuration. In systems with virtual server configurations such as containers, it is possible to reduce latency within the server and perform packet forwarding without modifying the application.

[0160] <Example of application to bare-metal configuration (non-virtualized configuration)> This invention can be applied to non-virtualized systems, such as bare-metal configurations. In non-virtualized systems, packet forwarding can be performed with reduced latency within the server without modifying the application.

[0161] <Scale in / out> When dealing with high traffic volumes and using multiple NIC devices or NIC ports, running multiple polling threads in association with these devices allows for scaling in / out of polling threads while controlling the frequency of hardware interrupts.

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

[0163] In this way, the server-internal delay control device 200 stops the software interrupt (softIRQ) for packet processing, which is the main cause of network delays. The data arrival monitoring unit 210 of the server-internal delay control device 200 executes a thread to monitor packet arrivals and processes packets using the polling model (without softIRQ) when a packet arrives. The Sleep management unit 230 then puts the thread (Polling Thread) to sleep if no packets arrive for a predetermined period of time, so the thread (Polling Thread) sleeps when no packets arrive. The Sleep management unit 230 wakes the thread from sleep using a hardware interrupt (hardIRQ) when a packet arrives. Furthermore, the Sleep management unit 230 controls the timing of sleeping by allowing hardware interrupts (hardIRQ) based on the characteristics of the application program. This will produce the following effects (1) to (4).

[0164] (1) A polling model is implemented that disables software interrupts (softIRQs) that occur when packets arrive, which are the cause of delays. In other words, unlike the existing NAPI technology, the server-internal delay control system 1000 implements a polling model instead of an interrupt model, which is the main cause of network delays. When packets arrive, they are harvested immediately without waiting, so low-latency packet processing can be achieved ("Achieving Low Latency with Polling Model").

[0165] (2) The Polling Thread in the server's delay control device 200 monitors packet arrivals in polling mode. The Polling Thread, which monitors packet arrivals, sleeps when no packets arrive. When no packets arrive, the CPU is not used by sleeping, resulting in power savings ("Achieving reduction of unnecessary CPU usage and power savings through Polling Thread sleep management").

[0166] (3) Furthermore, the reception processing method 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 the application program").

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

[0168] Thus, the server-internal delay control device 200 (see Figure 1) can achieve both low latency and low power consumption by managing the sleep state of the Polling Thread that performs packet forwarding processing when a Polling Thread exists in user space. Furthermore, it can achieve both low latency and low power consumption even for applications with different application program characteristics.

[0169] In the server-internal delay control device 200, the Sleep management unit 230 compares the elapsed time since the packet became undelivered with a predetermined time suitable for the characteristics of the application program. If the elapsed time since the packet became undelivered is greater than or equal to the time suitable for the characteristics of the application program, it enables a hardware interrupt and puts the thread to sleep.

[0170] In this way, the Sleep Management Unit 230 controls the timing of enabling hardware interrupts and going to sleep according to the characteristics of the application program. For example, during polling, the Sleep Management Unit 230 can continue polling even if the driver's receive queue becomes empty, in the case of application programs where packets arrive immediately. This enables further reduction in latency and power consumption according to the characteristics of the application program and traffic characteristics.

[0171] In the server-internal delay control device 200, the data arrival monitoring unit 210 is characterized by checking whether data has arrived in the device's receive queue at a predetermined timing based on the characteristics of the application program.

[0172] By doing so, the frequency of polling can be controlled according to the characteristics of the application program and traffic information, thereby achieving further low latency and power savings tailored to the characteristics of the application program and traffic.

[0173] In the server-internal delay control device 200, the data arrival monitoring unit 210 checks whether data has arrived in the device's receive queue after a predetermined period of downtime.

[0174] By doing so, the data arrival monitoring unit 210 can reduce the number of CPU cycles while performing reception monitoring and thus save power by inserting a pause in polling (for example, checking whether data has arrived in the device's receive queue after a predetermined pause) when the delay requirements of the application program are not strict or the packet arrival interval is not short.

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

[0176] By doing so, the arrival notification method can be selected according to the characteristics of the application program, and further reductions in latency can be achieved according to the characteristics of the application program.

[0177] In the server-internal 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 when the packet processing function is executed, it does not notify the application program.

[0178] By doing this, if the application program is simple, it can reduce the overhead of arrival notifications and process packets by incorporating a packet processing function instead of sending notifications. This allows for further reduction of latency depending on the characteristics of the application program.

[0179] The server-internal delay control device 300 (see Figure 9) according to the second embodiment is characterized by having a logic management unit 310 that collects characteristic information of an application program and processing information of threads, and, based on the collected information, modifies the processing logic of at least one of the functional units among the data arrival monitoring unit 210, data arrival notification unit 220, and sleep management unit 230 in the case of an application program in which the load fluctuates depending on the time of day and the processing method and processing speed fluctuate.

[0180] In this way, the logic management unit 310 dynamically determines the processing logic of each Polling Thread function unit (data arrival monitoring unit 210, data arrival notification unit 220, sleep management unit 230) according to the characteristics of the application program and the processing of the thread, and distributes it to each function unit. As a result, even for applications whose characteristics change dynamically, the processing logic of each function unit is operated according to the changing characteristics, thereby maintaining low latency and low power consumption in the reception process.

[0181] Furthermore, among the processes described in each of the above embodiments, all or part of the processes described as being performed automatically may be performed manually, or all or part of the processes described as being performed manually may be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings may be changed at will unless otherwise specified. Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0182] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software that allows the processor to interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in 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, an SD (Secure Digital) card, or an optical disc. [Explanation of symbols]

[0183] 1. Data Processing APL (Application Program) 10 HW 70 Guest OS 72 Ring Buffer 74 Protocol Processing Unit 110 HW 130 NICs (Physical NICs) (Devices) 140 OS 160 user space 200,300 Server-based delay control devices (Polling Threads) 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 Department 311 Characteristic Information Collection Department 312 Logic Distribution Department 1000 Server-In-Server Delay Control System< / enable> < / wakeup> < / interrupt> < / notify> < / enable> < / polling> < / enable> < / wakeup> < / interrupt> < / notify> < / polling>

Claims

1. A server that performs data processing including polling, The aforementioned server, The hardware is equipped with a NIC. Equipped with a HardIRQ handler located in the OS, The user space includes a data arrival monitoring unit that monitors data arrivals. A sleep unit that pauses monitoring of the arrival of the aforementioned data, The system includes a sleep management unit that restarts monitoring of the arrival of the aforementioned data, When the sleep unit has suspended monitoring for data arrival, The aforementioned sleep management unit, The arrival of a packet to the aforementioned NIC triggers the activation of the HardIRQ handler located in the aforementioned OS. Upon receiving notification from the HardIRQ handler, the data arrival monitoring unit is notified, and the monitoring of data arrival is resumed. A server characterized by the following features.

2. A program for causing a computer to function as the server described in claim 1.

Images