Server and program

Abstract

To perform packet transfer with a reduced delay in a server without modifying an APL while reducing power consumption.SOLUTION: An OS 70 has a ring buffer 72 and a poll list 186. A kernel 171 includes a server delay control device 100 that spawns a thread for monitoring packet arrivals using a polling model. The server delay control device includes: a packet arrival monitoring section 110 that monitors the poll list 186; a packet dequeuing section 120 that refers to a packet held in the ring buffer 72 when the packet has arrived and executes dequeuing to remove a corresponding queue entry from the ring buffer 72 on the basis of processing to be performed next; and a sleep management section 130 that causes the thread to sleep when there is no packet arrival over a predetermined period, and cancels the sleep by hardware interruption of the thread when a packet arrives.SELECTED DRAWING: Figure 1

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 (typically Ethernet 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 performed 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, by 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 by queue operations alone, without performing hardware emulation.

[0007] [Packet forwarding using the interrupt model (example of a generic VM configuration)] FIG. 9 is a diagram for explaining packet transfer according to an interrupt model in a server virtualization environment having a generic Linux kernel (registered trademark) and a VM configuration. The HW10 has a NIC (Network Interface Card) 11 (physical NIC) (interface unit), and transmits and receives data between the HW10 and a packet processing APL (Application) 1 on a user space 60 via a virtual communication path constructed by the Host OS 20, the KVM 30 which is a hypervisor that constructs virtual machines, the virtual machines (VM1, VM2) 40, and the Guest OS 50. In the following description, as shown by the thick arrows in Fig. 9, the data flow in which the packet processing APL1 receives packets from the HW10 is referred to as Rx side reception, and the data flow in which the packet processing APL1 transmits packets to the HW10 is referred to as Tx side transmission.

[0008] The host OS 20 includes a kernel 21, a ring buffer 22, and a driver 23. The kernel 21 includes a vhost-net module 221, which is a kernel thread, a tap device 222, and a virtual switch (br) 223.

[0009] The tap device 222 is a kernel device of a virtual network and is supported by software. The virtual machine (VM1) 40 allows communication between the Guest OS 50 and the Host OS 20 via a virtual switch (br) 223 created in a virtual bridge. The tap device 222 is a device connected to a virtual NIC (vNIC) of the Guest OS 50 created in this virtual bridge.

[0010] The Host OS 20 copies the configuration information (size of the shared buffer queue, number of queues, identifier, top address information for accessing the ring buffer, etc.) constructed within the virtual machine of the Guest OS 50 to the vhost-net module 221, and constructs the endpoint information on the virtual machine side within the Host OS 20. This vhost-net module 221 is a kernel-level backend for virtio networking, and by transferring the virtio packet processing task from the user area (user space) to the vhost-net module 221 of the kernel 21, the virtualization overhead can be reduced.

[0011] The Guest OS 50 includes a Guest OS (Guest 1) installed on a virtual machine (VM1) and a Guest OS (Guest 2) installed on a virtual machine (VM2), and the Guest OS 50 (Guest 1, Guest 2) run in the virtual machines (VM1, VM2) 40. Taking Guest 1 as an example of the Guest OS 50, the Guest OS 50 (Guest 1) includes a kernel 51, a ring buffer 52, and a driver 53, and the driver 53 includes a virtio-driver 531.

[0012] Specifically, within the virtual machine there are virtio devices for the console, file I / O, and network communication as PCI (Peripheral Component Interconnect) devices (the console is virtio-console, file I / O is virtio-blk, and the network is virtio-net, and the corresponding drivers that the OS has are defined in the virtio queue), and when the Guest OS starts up, two data transfer endpoints (sending and receiving endpoints) are created between the Guest OS and the other side, establishing a parent-child relationship for sending and receiving data. In many cases, the parent-child relationship is configured between the virtual machine (child side) and the Guest OS (parent side).

[0013] The child side exists as device configuration information within the virtual machine, and requests the parent side for the size of each data area, the number of endpoint combinations required, and the device type. In accordance with the child side's request, the parent side allocates and secures memory for a shared buffer queue to store and transfer the required amount of data, and returns the address to the child side so that the child can access it. In Virtio, all shared buffer queue operations required for data transfer are common, and are executed with both the parent and child sides having agreed upon them. Furthermore, the size of the shared buffer queue is also agreed upon by both sides (i.e. it is determined for each device). This makes it possible for both the parent and child sides to operate the shared queue simply by communicating the address to the child side.

[0014] The shared buffer queues prepared in virtio are prepared for single direction use, so for example, a virtual network device called a virtio-net device consists of three Ring Buffers 52: one for sending, one for receiving, and one for control. Communication between parent and child is achieved by writing to the shared buffer queue and notifying the buffer update, and after writing to the Ring Buffer 52, the other side is notified. When the other side receives the notification, it uses virtio's common operations to check how much new data is in which shared buffer queue, and extracts new buffer space. This completes the transfer of data from parent to child or from child to parent.

[0015] As described above, the parent and child share the Ring Buffer 52 for data exchange with each other and the operation method for each ring buffer (common to virtio), thereby realizing communication between the Guest OS 50 and the outside world without the need for hardware emulation. This makes it possible to send and receive data between the Guest OS 50 and the outside world at high speeds compared to conventional hardware emulation.

[0016] When Guest OS50 in a virtual machine communicates with the outside, the child side must connect to the outside and act as a relay between the outside and the parent side to send and receive data. One example is communication between Guest OS50 and Host OS20. Here, if the outside is the Host OS20, there are two existing communication methods.

[0017] The first method (hereinafter referred to as external communication method 1) establishes a child endpoint within the virtual machine, and connects within the virtual machine the communication between Guest OS 50 and the virtual machine and the communication endpoint (usually called a tap / tun device) provided by Host OS 20. This connection establishes the following connection, realizing communication from Guest OS 50 to Host OS 20.

[0018] At this time, the Guest OS 50 runs in a memory area that is a user space with different privileges from the memory area called the kernel space in which the tap driver and the Host OS 20 run. For this reason, communication from the Guest OS 50 to the Host OS 20 requires at least one memory copy.

[0019] The second method (hereafter referred to as external communication method 2) is a technology called vhost-net that solves this problem. In vhost-net, the parent configuration information (size of the shared buffer queue, number of queues, identifier, top address information for accessing the ring buffer, etc.) once constructed within the virtual machine is copied to the vhost-net module 221 inside the Host OS 20, and the child end point information is constructed within the host. This construction makes it possible to directly operate the shared buffer queue between the Guest OS 50 and the Host OS 20. This effectively eliminates the need for copying, and since there is one less copy time compared to virtio-net, faster data transfer can be achieved compared to external communication method 1.

[0020] In this way, by reducing the number of memory copies related to virtio-net in the Host OS 20 and the Guest OS 50 connected by virtio, the packet transfer process can be accelerated.

[0021] In addition, since kernel v4.10 (2017.2~), the specifications of the tap interface have been changed so that packets inserted from the tap device are completed within the same context as the process that copied the packet to the tap device. This has eliminated the occurrence of software interrupts (softIRQs).

[0022] [Packet forwarding using the polling model (DPDK example)] The method of connecting and coordinating multiple virtual machines is called Inter-VM Communication, and in large-scale environments such as data centers, virtual switches have been used as a standard method for connecting VMs. However, this method has a large communication delay, so new faster methods have been proposed. For example, a method that uses special hardware called SR-IOV (Single Root I / O Virtualization) and a software method that uses Intel DPDK (Intel Data Plane Development Kit) (hereinafter referred to as DPDK), a high-speed packet processing library, have been proposed (see Non-Patent Document 1).

[0023] DPDK is a framework for controlling NICs (Network Interface Cards), which was previously handled by the Linux kernel (registered trademark), in user space. The biggest difference with the processing in the Linux kernel is that it has a polling-based reception mechanism called PMD (Pull Mode Driver). Normally, in the Linux kernel, an interrupt occurs when data arrives at the NIC, which triggers the reception process. On the other hand, in PMD, a dedicated thread continuously checks whether data has arrived and performs the reception process. By eliminating overhead such as context switches and interrupts, high-speed packet processing can be achieved. DPDK significantly improves the performance and throughput of packet processing, making it possible to secure more time for data plane application processing.

[0024] DPDK exclusively uses computer resources such as CPU (Central Processing Unit) and NIC. For this reason, it is difficult to apply to applications that require flexible reconnection on a module basis, like SFC. There is an application called SPP (Soft Patch Panel) that alleviates this problem. SPP provides shared memory between VMs and configures each VM to directly reference the same memory space, thereby eliminating packet copying in the virtualization layer. In addition, DPDK is used to speed up packet exchange between physical NICs and shared memory. SPP can change the input and output destinations of packets in software by controlling the reference destination of memory exchange for each VM. Through this process, SPP realizes dynamic connection switching between VMs and between VMs and physical NICs.

[0025] Fig. 10 is a diagram for explaining packet forwarding by a polling model in the configuration of OvS-DPDK (Open vSwitch with DPDK). The same components as those in Fig. 9 are given the same reference numerals and the description of the overlapping parts is omitted. As shown in FIG. 10, the host OS 20 includes an OvS-DPDK 70, which is software for packet processing. The OvS-DPDK 70 includes a vhost-user 71, which is a functional unit for connecting to a virtual machine (here, VM1), and a dpdk (PMD) 72, which is a functional unit for connecting to a NIC (DPDK) 11 (physical NIC). 9. The packet processing APL1A also includes a dpdk(PMD)2 which is a functional unit that performs polling in the Guest OS 50 section. That is, the packet processing APL1A is an APL obtained by modifying the packet processing APL1 in FIG.

[0026] Packet forwarding using the polling model is an extension of DPDK, and enables route operations using a GUI in SPP, which performs high-speed packet copying between Host OS 20 and Guest OS 50, and between Guest OS 50, with zero copy via shared memory.

[0027] [Rx side packet processing using New API (NAPI)] 11 is a schematic diagram of Rx-side packet processing by New API (NAPI) implemented in Linux kernel 2.5 / 2.6 (see Non-Patent Document 2). The same components as those in FIG. 9 are denoted by the same reference numerals. As shown in FIG. 11, the New API (NAPI) executes a packet 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 packet processing APL1 and a NIC 11 of HW 10 connected to the OS70.

[0028] 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 manages hardware monitoring and program execution status on a process-by-process basis. Here, kernel 71 responds to requests from packet processing APL1 and conveys requests from HW 10 to packet processing APL1. Kernel 71 processes requests from packet 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 packet processing APL 1 via the Socket 75. The Kernel 71 receives a packet from the packet processing APL 1 via the Socket 75.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] Socket75 is an interface that kernel71 uses for inter-process communication. Socket75 has a socket buffer and does not require frequent data copying. The flow of 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, packet processing APL1 becomes able to call system calls such as read() and write() on kernel71.

[0033] 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 11, packet transfer using the interrupt model transfers packets using interrupt processing (see symbol c in Figure 11), which creates a wait for the interrupt processing and increases the delay in packet transfer.

[0034] The following provides an overview of packet processing on the NAPI Rx side. [Rx side packet processing configuration using New API (NAPI)] FIG. 12 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 12, 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.

[0035] <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.

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

[0037] 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.

[0038] [Rx side packet processing operation using New API (NAPI)] The arrows (symbols) d to o in FIG. 12 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 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 d in FIG. 12). This Ring Buffer 72 is a memory space in the server, and is managed by the Kernel 71 (see FIG. 11).

[0039] 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 e in FIG. 12), and netif_rx 82 executes the following process, which allows the Kernel 71 to recognize the packet. Note that hardIRQ 81, shown in an oval in FIG. 12, indicates a handler rather than a functional unit.

[0040] Netif_rx82 is a function that actually performs processing. When hardIRQ81 (handler) is started (see symbol f in FIG. 12), it saves information on the net device (net_device) that indicates which device the hardware interrupt from NIC11 is from, which is one of the pieces of information on the contents of the hardware interrupt (hardIRQ), in poll_list86, and registers queue pruning (referring to the contents of the packets stored in the buffer, deleting the corresponding queue entry from the buffer in consideration of the processing of the packets to be performed next) (see symbol g in FIG. 12). Specifically, when packets are stuffed into the Ring Buffer72, netif_rx82 uses the driver of NIC11 to register future queue pruning in poll_list86 (see symbol g in FIG. 12). As a result, queue pruning information resulting from the packing of packets into the Ring Buffer72 is registered in poll_list86.

[0041] In this way, in Fig.<Device driver> In the above, when the NIC 11 receives a packet, it uses DMA transfer to copy the packet that has arrived to the Ring Buffer 72. In addition, the NIC 11 raises 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 12.<Device driver> Processing of hardware interrupts in stops.

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

[0043] 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_softirq84f notifies net_rx_action85, which actually processes the software interrupt, of the current (corresponding) software interrupt request (see symbol j in Figure 12).

[0044] 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 k in FIG. 12), and reaps the packets (see symbol l in FIG. 12). 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 m in FIG. 12).

[0045] 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. 11) 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 o in FIG. 12).

[0046] Non-Patent Document 3 describes a server network delay control device (KBP: Kernel Busy Poll). KBP constantly monitors packet arrivals using a polling model within the kernel. This suppresses softIRQ and achieves low-latency packet processing. [Prior art documents] [Non-patent literature]

[0047] [Non-Patent Document 1] “Developer Quick Start Guide Learn How To Get Involved With DPDK,” Intel, [online], [Retrieved March 5, 2021], Internet 〈 URL : https: / / www.dpdk.org / 〉 [Non-Patent Document 2] New API (NAPI), [online], [searched on March 5, 2021], Internet <URL: http: / / http: / / lwn.net / 2002 / 0321 / a / napi-howto.php3> [Non-Patent Document 3] Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, “KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server”, IEEE CCNC 2021. Summary of the Invention [Problem to be solved by the invention]

[0048] However, 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, as shown in FIG. 9, packet transfer according to the interrupt model transfers packets by interrupt processing (see symbols a and b in FIG. 9), which causes waiting for the interrupt processing, resulting in large delays in packet transfer.

[0049] 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.

[0050] Similarly, in packet processing using the New API (NAPI), as shown in the dotted-line box p in FIG. 12, a network delay on the order of ms occurs due to contention in interrupt processing (softIRQ).

[0051] On the other hand, the polling model occupies the CPU to poll the communication queue and immediately harvests packets when they arrive. Although the polling model can reduce transfer delays, it requires APL to be equipped with a polling function, so APL needs to be modified. For example, as shown in FIG. 10, packet transfer according to the polling model requires the packet processing APL1 to be equipped with a dpdk(PMD) 72, which is a functional unit that performs polling in the Guest OS 50 section, and therefore requires modification of the packet processing APL1.

[0052] Moreover, the KBP described in Non-Patent Document 3 constantly monitors packet arrivals using a polling model within the kernel, thereby suppressing softIRQ and achieving low-latency packet processing. However, the kernel thread that constantly monitors packet arrivals occupies a CPU core and constantly uses CPU time, which causes a problem of high power consumption. The relationship between workload and CPU utilization will be explained with reference to Figs. 13 and 14.

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

[0054] FIG. 14 is a diagram showing the CPU utilization rate used by the busy poll thread in the KBP described in Non-Patent Document 3. In FIG. As shown in Fig. 14, 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. 13, KBP has a problem of high power consumption because the CPU is always used regardless of whether packets arrive or not.

[0055] The present invention has been made in consideration of this background, and an object of the present invention is to perform packet transfer by reducing delays within a server without modifying the APL, while reducing power consumption. [Means for solving the problem]

[0056] In order to solve the above-mentioned problems, an intra-server delay control device is provided, in which an OS has a kernel, a ring buffer managed by the kernel in a memory space in a server having the OS, and a poll list that registers information on network devices indicating which device a hardware interrupt from an interface unit is for, and the intra-server delay control device is provided in the kernel, which launches a thread that monitors packet arrivals using a polling model, and the intra-server delay control device is characterized in that it comprises a packet arrival monitoring unit that monitors the poll list, a packet reaping unit that, if a packet has arrived, refers to the packet held in the ring buffer and performs reaping to delete the corresponding queue entry from the ring buffer based on the next processing to be performed, and a sleep management unit that puts the thread to sleep if a packet does not arrive for a specified period, and wakes up the sleep of the thread by a hardware interrupt when a packet arrives. Effect of the Invention

[0057] According to the present invention, it is possible to transfer packets with reduced delay within a server while reducing power consumption and without modifying the APL. [Brief description of the drawings]

[0058] [Figure 1] 1 is a schematic configuration diagram of an intra-server delay control system according to an embodiment of the present invention. [Diagram 2] 1 is a diagram illustrating details of Rx-side packet processing by a New API (NAPI) of the intra-server delay control system according to an embodiment of the present invention. FIG. [Diagram 3] FIG. 11 is a diagram illustrating an example of a polling thread operation of the intra-server delay control system according to the embodiment of the present invention. [Figure 4] 4 is a flowchart showing the Rx side operation and power saving management process of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention. [Diagram 5] 4 is a flowchart showing a CPU frequency / CPU idle setting process for power saving of an intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention. [Figure 6] 1 is a hardware configuration diagram showing an example of a computer that realizes the functions of an intra-server delay control device of an intra-server delay control system according to an embodiment of the present invention. FIG. [Figure 7] This is a diagram showing an example of applying an in-server delay control system to an interrupt model in a server virtualization environment with a generic Linux kernel and VM configuration. [Figure 8] FIG. 13 is a diagram illustrating an example of applying an intra-server delay control system to an interrupt model in a server virtualization environment with a container configuration. [Figure 9] 1 is a diagram for explaining packet forwarding based on an interrupt model in a server virtualization environment having a generic Linux kernel and a VM configuration. [Figure 10] FIG. 1 is a diagram illustrating packet forwarding according to a polling model in the configuration of OvS-DPDK. [Figure 11] 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 12]12 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. 11. FIG. [Figure 13] FIG. 1 is a diagram showing an example of video (30 FPS) data transfer. [Figure 14] FIG. 13 is a diagram showing the CPU utilization rate used by a busy poll thread in the KBP described in Non-Patent Document 3. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0059] 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. [overview] Fig. 1 is a schematic diagram of a server delay control system according to an embodiment of the present invention. This embodiment is an example of application to Rx-side packet processing using New API (NAPI) implemented in Linux kernel 2.5 / 2.6. The same components as those in Fig. 11 are given the same reference numerals. As shown in FIG. 1, the intra-server delay control system 1000 executes a packet processing APL1 placed in a user space 60 available to a user on a server equipped with an OS70 (e.g., a Host OS), and transfers packets between a NIC 11 of HW 10 connected to the OS70 and the packet processing APL1.

[0060] The OS 70 includes a kernel 171 , a ring buffer 72 , and a driver 73 , and the kernel 171 includes an intra-server delay control device 100 and a protocol processing unit 74 .

[0061] In this embodiment, since the kernel 171 includes the intra-server delay control device 100, a new number is assigned to distinguish it from the kernel 71 shown in Fig. 11. The kernel 171 has the same functions as the kernel 71 shown in Fig. 11, except that the intra-server delay control device 100 is installed. However, the kernel 171 can be realized by using livepatch (described later) without modifying (building a new) the existing kernel 71 (see Fig. 11).

[0062] The kernel 171 is a core function of the OS 70 (for example, the host OS) and monitors hardware and manages the execution status of programs on a process-by-process basis. Here, the kernel 171 responds to requests from the packet processing APL1 and conveys requests from the HW 10 to the packet processing APL1. The kernel 171 processes requests from the packet processing APL1 via a system call. The kernel 171 transmits a packet to the packet processing APL 1 via the socket 75. The kernel 71 receives a packet from the packet processing APL 1 via the socket 75.

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

[0064] Driver73 is a device driver that monitors hardware in kernel171.

[0065] The protocol processing unit 74 performs protocol processing of L2 / L3 / L4 defined by the OSI reference model.

[0066] Socket 75 is an interface for inter-process communication by kernel 171. Socket 75 has a socket buffer and does not frequently copy data.

[0067] <Internal server delay control device> The intra-server delay control device 100 includes a packet arrival monitor 110, a packet harvester 120, a sleep manager 130, and a CPU frequency / CPU idle setting unit 140 (CPU frequency setting unit, CPU idle setting unit).

[0068] The packet arrival monitor 110 is a thread for monitoring whether a packet has arrived or not. The packet arrival monitor 110 monitors (polls) the poll_list 186 (see FIG. 2).

[0069] The packet arrival monitoring unit 110 obtains the pointer information indicating that a packet exists in the Ring_Buffer 72 (see FIG. 2) and the net_device information from the poll_list 186, and transmits the information (pointer information and net_device information) to the packet harvesting unit 120. Here, if multiple packet information exists in the poll_list 186, the multiple pieces of information are transmitted.

[0070] If a packet has arrived, the packet reaper 120 refers to the packet held in the Ring Buffer 72, and executes reaping to delete the corresponding queue entry from the Ring Buffer 72 based on the next process (hereinafter, this may simply be referred to as reaping packets from the Ring Buffer 72). The packet reaper 120 extracts the packet from the Ring Buffer 72 based on the received information, and transmits the packet to netif_receive_skb 87.

[0071] The sleep management unit 130 puts a 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 (details will be described later).

[0072] During sleep, the CPU frequency / CPU idle setting unit 140 sets the CPU operating frequency of the CPU core used by the thread (polling thread) to a low value. During sleep, the CPU frequency / CPU idle setting unit 140 sets the CPU idle state of the CPU core used by this thread (polling thread) to a power saving mode (described in detail later).

[0073] Fig. 2 is a diagram for explaining details of Rx side packet processing by New API (NAPI) of the intra-server delay control system 1000 in Fig. 1. The same components as those in Fig. 1 and Fig. 12 are given the same reference numerals. <Device driver> As shown in Figure 2, the device driver includes NIC11, 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_rx182, which is a processing function for software interrupts.

[0074] <Networking layer> The networking layer includes a poll_list 186 which registers information on the net device (net_device) indicating which device the hardware interrupt from the NIC 11 is for, a packet arrival monitor 110, a netif_receive_skb 87 which creates an sk_buff structure (a structure in which the kernel 171 indicates the state of a packet) for socket communication without interrupts for packets pruned from the queue, and a Ring Buffer 72.

[0075] <Protocol layer> In the protocol layer, packet processing functional units such as ip_rcv 88 and arp_rcv 89 are arranged. Note that there are other protocol processes in addition to ip_rcv 88 and arp_rcv 89.

[0076] The above netif_rx 182, netif_receive_skb 87, ip_rcv 88, and arp_rcv 89 are program components (function names) called within the Kernel 171 for packet processing.

[0077] The operation of the intra-server delay control system 1000 will now be described. [Rx side packet processing operation according to the present invention] The arrows (symbols) d to g and ko to o in FIG. 2 indicate the flow of packet processing on the Rx side. When the NIC 11 receives a packet (or frame) from the other device in a frame, it copies the arriving packet to the Ring Buffer 72 by DMA transfer without using the CPU (see symbol d in Figure 2). This Ring Buffer 72 is a memory space in the server, and is managed by the Kernel 171 (see Figure 1).

[0078] When a packet arrives, the NIC 11 raises a hardware interrupt (hardIRQ) to the hardIRQ 81 (handler) (see symbol e in FIG. 2), and the netif_rx 182 executes the following process, whereby the Kernel 171 recognizes the packet.

[0079] When hardwire 81 (handler) is started (see symbol f in Figure 2), netif_rx 182 saves net device (net_device) information, which is one of the pieces of information contained in the hardware interrupt (hardIRQ) and indicates which device the hardware interrupt from NIC 11 belongs to, in poll_list 186, and registers queue pruning information (see symbol g in Figure 2). Specifically, upon receipt of packets being stuffed into the Ring Buffer 72, netif_rx 182 uses the driver of NIC 11 to register future queue pruning in poll_list 186 (see symbol g in Figure 2). As a result, queue pruning due to packets being stuffed into the Ring Buffer 72 is registered in poll_list 186.

[0080] Netif_rx 182 registers net_device in poll_list 186, but does not schedule software interrupts (softIRQ), unlike netif_rx 82 in Fig. 12. That is, netif_rx 182 differs from netif_rx 82 in Fig. 12 in that it does not schedule software interrupts (softIRQ).

[0081] Also, the netif_rx 182 performs sleep release to wake up the sleeping polling thread (see symbol p in FIG. 2). In this embodiment, this polling thread wake-up process (sleep release) is added to the KBP described in Non-Patent Document 3. So far, we have completed the steps in Figure 2.<Device driver> Processing of hardware interrupts in stops.

[0082] In this embodiment, the<Networking layer> 12. In this embodiment, softIRQ 83 and do_softirq 84 are deleted, and accordingly, netif_rx 82 shown in FIG. 12 does not notify softIRQ 83 (handler) to start up (see symbol h in FIG. 12).

[0083] In this embodiment, the intra-server delay control system 1000 deletes the softIRQ 83 and do_softirq 84 shown in FIG. 12 and instead uses the<Networking layer> An intra-server delay control device 100 is provided in a memory space in the server.

[0084] As shown in Figure 2<Networking layer> In this case, the packet arrival monitor 110 of the intra-server delay control device 100 monitors (polls) the poll_list 186 (see symbol k in FIG. 2) and checks whether a packet has arrived.

[0085] The packet arrival monitoring unit 110 obtains the pointer information indicating that a packet exists in the Ring_Buffer 72 and the net_device information from the poll_list 186, and transmits the information (pointer information and net_device information) to the packet harvesting unit 120 (see symbol q in FIG. 2). Here, if multiple packet information exists in the poll_list 186, the multiple pieces of information are transmitted.

[0086] If a packet has arrived, the packet reaper 120 of the intra-server delay control device 100 retrieves the packet from the Ring Buffer 72 (see symbol l in FIG. 2). The packet harvester 120 extracts the packet from the Ring_Buffer 72 based on the received information, and transmits the packet to the netif_receive_skb 87 (see symbol m in FIG. 2).

[0087] In this way, the intra-server delay control system 1000 stops the softIRQ of packet processing, which is the main cause of network delays, and executes a polling thread in which the packet arrival monitor 110 of the intra-server delay control device 100 monitors packet arrivals. Then, the packet reaper 120 processes packets using a polling model (without softIRQ) when the packets arrive.

[0088] That is, the polling thread in the intra-server delay control device 100 operates as a kernel thread and monitors packet arrival in polling mode. The packet arrival monitor 110 monitors the poll_list 186. The packet harvester 120 retrieves the packet from the Ring Buffer 72 when the packet arrives, and transfers the packet to the netif_receive_skb 87.

[0089] When a packet arrives, the polling thread is started by the hardware interrupt handler, which avoids softIRQ contention and enables immediate packet transfer processing. In other words, by putting the packet arrival monitoring function on hold as a kernel thread and waking it up with a hardware interrupt, it is possible to achieve lower latency than packet transfer processing using soft interrupts such as NAPI.

[0090] The kernel thread that monitors packet arrival is allowed to sleep while no packets arrive. The polling thread goes to sleep depending on whether a packet has arrived, and is released from sleep by hardIRQ 81 when a packet has arrived. Specifically, the sleep management unit 130 of the intra-server delay control device 100 puts the polling thread to sleep depending on whether a packet has arrived, that is, if no packet has arrived for a certain period of time. The sleep management unit 130 releases sleep by hardIRQ 81 when a packet has arrived. This avoids softIRQ contention and achieves low delay.

[0091] The CPU frequency / CPU idle setting unit 140 of the intra-server delay control device 100 changes the CPU operating frequency and idle setting depending on whether a packet has arrived. Specifically, the CPU frequency / CPU idle setting unit 140 lowers the CPU frequency during sleep, and raises the CPU frequency when started up again (returning the CPU operating frequency to its original state). The CPU frequency / CPU idle setting unit 140 also changes the CPU idle setting to power saving during sleep. By lowering the CPU operating frequency during sleep and changing the CPU idle setting to power saving, power saving is also achieved.

[0092] 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. 11) 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 processing is passed to arp_rcv89.

[0093] Fig. 3 is a diagram showing an example of the operation of a polling thread in the intra-server delay control device 100. The vertical axis indicates the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis indicates time. Fig. 3 shows an example of the operation of a polling thread due to the arrival of packets corresponding to the data transfer example of a video (30 FPS) in which packets are received intermittently shown in Fig. 13. As shown in Fig. 3, the sleep management unit 130 of the intra-server delay control device 100 puts the polling thread to sleep if no packet arrives for a certain period of time (more specifically, if a next packet does not arrive even after a fixed value (certain period) predetermined by the maintenance / operator has elapsed since the arrival of a certain packet) (see symbol s in Fig. 3).Then, the sleep management unit 130 starts the polling thread with hard IRQ 81 when a packet arrives (see symbol t in Fig. 3). During sleep, the kernel thread does not have exclusive use of the CPU core. Therefore, in addition to the polling thread, timer interrupts for stable system operation may enter the corresponding CPU core, and a migration thread for error processing, etc. may enter the corresponding CPU core, which may cause the CPU usage of the CPU core used by the polling thread to fluctuate (see symbol u in Figure 3).

[0094] [Registration by live patch] Next, the registration operation by live patch will be described. In the intra-server delay control system 1000 (see FIG. 1), the kernel 171 of the OS 70 shown in FIG. 1 includes the intra-server delay control device 100. By using livepatch, the kernel 171 can be realized without modifying (newly building) the existing kernel 71 (see FIG. 11). The livepatch applied to the kernel 171 will be described below.

[0095] livepatch is a kernel patch function applied to the Linux (registered trademark) kernel. By using livepatch, you can instantly apply modifications to the kernel space without rebooting the system. That is, (1)Livepatch suppresses the softIRQ scheduling function of netif_rx182 (see Figure 2).

[0096] (2) Livepatch starts a thread (packet arrival monitor 110, specifically isol_net_rx) that monitors packet arrivals. When starting up, the thread (packet arrival monitor 110) occupies a CPU core exclusively to prevent other processes or kernel threads from being interrupted by busy poll (see symbol k in Figure 2). For this reason, the thread is assigned a high priority setting such as a real-time process. Depending on the number of traffic flows (or traffic volume), threads are started on multiple CPU cores and a poll_list 186 (see Figure 2) to monitor is assigned. This makes it possible to scale out according to the traffic flow (traffic volume). Thereafter, the packet processing operation shown in FIG. 2 is executed.

[0097] [Rx side packet processing operation flow of the server delay control device 100] 4 is a flowchart showing the Rx side operation and power saving management process of the intra-server delay control device 100 (see FIG. 2). The Rx side operation will be described with reference to FIG. While the polling thread is running, this operation flow is executed in a loop. In step S1, the packet arrival monitor 110 (see FIG. 2) of the intra-server delay control device 100 monitors (polls) the poll_list 186 (see FIG. 2) by exclusively using the CPU (see symbol k in FIG. 2) to check whether a packet has arrived.

[0098] In step S2, the packet arrival monitor 110 (see FIG. 2) determines whether or not the poll list 186 contains pointer information indicating a packet arrival. If there is pointer information in poll list 186 indicating that a packet has arrived (S2: Yes), the process proceeds to step S3, and if there is no pointer information in poll list 186 indicating that a packet has arrived (S2: No), the process returns to step S1.

[0099] In step S3, the packet arrival monitor 110 obtains the pointer information indicating that a packet exists in the Ring_Buffer 72 (see FIG. 2) and the NET_DEVICE information from the poll_list 186, and transmits the information (pointer information and NET_DEVICE information) to the packet harvester 120 (see symbol q in FIG. 2). Here, if multiple packet information exists in the poll_list 186, the multiple pieces of information are transmitted.

[0100] In step S4, if a packet has arrived, the packet reaping unit 120 (see Figure 2) of the intra-server delay control device 100 refers to the packet stored in the Ring Buffer 72, and performs reaping to delete the corresponding queue entry from the Ring Buffer 72 based on the next processing to be performed (see symbol l in Figure 2).

[0101] In step S5, the packet harvester 120 extracts the packet from the Ring_Buffer 72 based on the received information, and transmits the packet to the netif_receive_skb 87 (see symbol m in FIG. 2).

[0102] In step S6, the sleep management unit 130 of the intra-server delay control device 100 determines that no packets have been stored in the poll_list 186 (no packets have arrived) even after a certain period of time has elapsed. If no packets are stored in poll_list 186 after a certain period of time has elapsed (S6: Yes), sleep management unit 130 puts the polling thread into sleep (sleeps) in step S7. If packets are stored in poll_list 186 (S6: No), the process returns to step S1.

[0103] In step S8, the CPU frequency / CPU idle setting unit 140 sets the operating frequency of the CPU core used by the polling thread to a low value, and then ends the process of this flow. If the CPU frequency / CPU idle setting unit 140 can also set a CPU idle setting, it enables it.

[0104] FIG. 5 is a flowchart showing a CPU frequency / CPU idle setting process for power saving of the intra-server delay control device 100. As shown in FIG. In step S11, the hard interrupt processing unit (netif_rx 182 in FIG. 2), which is started when a packet arrives, starts a polling thread (internal delay control device 100 in FIG. 2) when a packet arrives. If the polling thread is already running, it continues as is. The sleep management unit 130 cancels sleep by a hardIRQ when a packet arrives.

[0105] In step S12, the CPU frequency / CPU idle setting unit 140 sets the operating frequency of the CPU core used by the polling thread to a higher frequency (returns the operating frequency of the CPU core to its original frequency), and ends the process of this flow. Here, if the CPU frequency / CPU idle setting unit 140 has also changed the CPU idle setting, it returns it to its original frequency.

[0106] <Additional features> In order to prevent packets from being missed from the poll_list 186, a polling thread may be periodically started to check whether or not packets from the poll_list 186 have arrived. By doing so, it is possible to prevent packets from remaining in poll_list 186 if there is a timing problem such as the arrival of a packet by NIC 11 and the sleep of the polling thread occurring at the same time.

[0107] [Difference between this embodiment and existing technology] Next, the difference between this embodiment and the existing technology (see FIG. 12) will be described.

[0108] <Background> Generally, hardware interrupts (hardIRQs) have a high priority, and the processing of the relevant CPU must be interrupted so that hardIRQ processing can be given top priority. This creates a large overhead. For this reason, the design philosophy is that hardIRQs only notify the arrival of packets, and packet processing is handled by softIRQs (this is called the "kernel principle"). However, softIRQs compete with other softIRQs, causing events that require waiting (which causes delays). The reason why conventional technology uses the interrupt model is that in the past, CPU resources were limited (or devices with few CPU cores, such as single board computers like the Raspberry Pi, were designed to share one CPU core with other processes). In this case, processing is performed by switching CPU time between normal processing and interrupt processing. Even with the above interrupt processing, softIRQs will compete, causing wait times. In addition, ksoftirqd, the scheduler that schedules softIRQs, does not have the functionality to assign priorities according to the type of softIRQ, and so cannot suppress delays caused by this contention.

[0109] <Existing technology (see Fig. 12)> As shown in Fig. 12, the kernel 71 (Fig. 11) receives notification of the arrival of a packet from the NIC 11 via hardIRQ 81 (see symbol h in Fig. 12), and schedules softIRQ 83 for packet processing (see dashed box p in Fig. 12). At this time, if there is a conflict with other interrupt processing, a wait will occur, causing a network delay on the order of ms.

[0110] <In-server delay control system 1000 (see FIG. 2)> Implementation of the packet arrival monitor 110 and the packet harvester 120 As shown in FIG. 2, the intra-server delay control system 1000 includes:<Networking layer> In this embodiment, netif_rx 182 registers net_device in poll_list 186, but unlike netif_rx 82 in the existing technology (see FIG. 12), it does not schedule software interrupts (softIRQ) ("Change 1").

[0111] As shown in FIG. 2, the intra-server delay control system 1000 includes:<Networking layer> An intra-server delay control device 100 is provided in the memory space in the server ("Modification 2"). The packet arrival monitor 110 of the intra-server delay control device 100 constantly monitors (busy polls) the poll_list 186 (see symbol k in FIG. 2) to check whether a packet has arrived.

[0112] The packet arrival monitor 110 obtains pointer information indicating that a packet exists in the Ring_Buffer 72 and NET_DEVICE information from the poll_list 186, and transmits the information (pointer information and NET_DEVICE information) to the packet harvester 120 (see symbol q in FIG. 2).

[0113] If a packet has arrived, the packet reaper 120 of the intra-server delay control device 100 retrieves the packet from the Ring Buffer 72 (see symbol l in FIG. 2).

[0114] The packet harvester 120 extracts the packet from the Ring_Buffer 72 based on the received information, and transmits the packet to the netif_receive_skb 87 (see symbol m in FIG. 2).

[0115] The effects of the above "Change 1" are as follows: First, in this embodiment, the notification of packet arrival by hardware interrupt (hardIRQ) follows NAPI. SoftIRQ is convenient in terms of effective use of CPU resources, but is not suitable from the viewpoint of immediate packet transfer. Therefore, in this embodiment, the function of softIRQ is stopped and a polling model is realized in the kernel, which is new. Specifically, this is shown in that netif_rx182 shown in FIG. 2 does not notify (see symbol h in FIG. 12) to start up softIRQ83 (handler) like netif_rx82 shown in FIG. 12.

[0116] Regarding the polling model, there is an existing technology called DPDK, which performs polling from user space (see Figure 10). However, since DPDK performs polling from APL, it requires modifications to APL.

[0117] The effects of the above "Change 2" are as follows: In this embodiment, a polling-only thread (the packet arrival monitor 110 of the intra-server delay control device 100) is started in the kernel 171 shown in Fig. 1, and the packet harvester 120 of the intra-server delay control device 100 processes the packet by a polling model (without softIRQ) when the packet arrives. This makes it unnecessary to modify the APL, in other words, it becomes possible to use the existing POSIX socket API.

[0118] Also, to prevent the aforementioned thread from stealing CPU time from other softIRQs, as mentioned above in [Registration by live patch], the thread occupies a CPU core when it is started and is set to high priority so that it does not interfere with polling.

[0119] As described above, the intra-server delay control device 100 realizes low-delay packet transfer by including the packet arrival monitor 110 and the packet reaper 120. That is, the software interrupt (softIRQ) is stopped when a packet arrives, and a polling model is realized within the kernel. A kernel thread that monitors packet arrival is newly created, and packet arrival in poll_list 186 is monitored. As a result, when a packet arrives, it is immediately reaped without waiting, thereby realizing low-delay packet processing.

[0120] - Implementation of the sleep management unit 130 and the CPU frequency / CPU idle setting unit 140 The intra-server delay control device 100 further includes a sleep management unit 130 and a CPU frequency / CPU idle setting unit 140, thereby achieving power saving in addition to the above-mentioned low-latency packet processing. That is, the kernel thread that monitors packet arrivals is allowed to sleep while no packets arrive. A sleeping thread is woken up by a hardIRQ handler when a packet arrives, thereby immediately starting the thread while avoiding softIRQ contention. Further power consumption reduction is achieved by adjusting the CPU operating frequency and CPU idle state in accordance with the above-mentioned sleep.

[0121] <Detailed Operation of the Sleep Management Unit 130 and the CPU Frequency / CPU Idle Setting Unit 140 (see FIG. 2)> The netif_rx182 shown in Figure 2 is started if the polling thread is sleeping when a packet arrives (see symbol p in Figure 2). If the polling thread is already running, it does nothing in particular and ends the hardware interrupt handler.

[0122] The CPU frequency / CPU idle setting unit 140 of the polling thread (intra-server delay control device 100) started by the hardware interrupt handler sets the CPU operating frequency of the CPU core used by the polling thread to a higher value (returns the operating frequency of the CPU core to its original value). Here, the kernel can change the operating frequency of the CPU core by the governor setting, and the CPU frequency / CPU idle setting unit 140 can set the CPU operating frequency high by using the governor setting, etc. However, the CPU idle setting depends on the CPU model. If the CPU core has enabled the CPU idle setting, it can also be disabled.

[0123] The packet arrival monitor 110 checks whether a packet pointer is stored in the poll_list 186. If a pointer is stored, the packet arrival monitor 110 transmits the corresponding pointer information and device driver information to the packet harvester 120.

[0124] While the polling thread is running, the above operations are executed in a loop. The packet arrival confirmation interval by this loop can be increased or decreased depending on the frequency of packet arrival. For example, the number of packets arriving per unit time T can be counted, N, and the confirmation frequency can be set to N / T [times / second] or more. This increase or decrease can further reduce CPU usage.

[0125] Based on the received pointer information and device driver information, the packet reaping unit 120 retrieves packets from the Ring Buffer 72. After that, it transmits the relevant data to the netif_receive_skb 87 (packet structure management unit) shown in FIG. netif_receive_skb87 creates structures (such as sk_buff structure) necessary for packet processing from the received data. From here on, the protocol processing is carried out by the kernel.

[0126] In checking the pointer of the packet in the poll_list 186, the sleep management unit 130 receives information on the arrival or non-arrival of a packet in the poll_list 186 from the packet arrival monitoring unit 110. If the sleep management unit 130 determines based on this information on the arrival or non-arrival of a packet that no packet has arrived for a certain period of time, it notifies the CPU frequency / CPU idle setting unit 140 that no packet has arrived for the certain period of time.

[0127] When no packets arrive for a certain period of time, the CPU frequency / CPU idle setting unit 140 receives a notification from the sleep management unit 130 and sets a lower CPU operating frequency of the CPU core used by the polling thread. At this time, the CPU frequency / CPU idle setting unit 140 enables the CPU idle setting if possible (however, this depends on the CPU model).

[0128] After the CPU frequency / CPU idle setting unit 140 has completed the setting, the sleep management unit 130 puts the polling thread into a sleep state (puts it to sleep). The process of lowering the CPU frequency setting and the process of entering the sleep state may be executed simultaneously. Also, the process may go to sleep after confirming that the packet transfer process is completed.

[0129] [Hardware configuration] The intra-server delay control device 100 according to this embodiment is realized by a computer 900 having a configuration as shown in FIG. FIG. 6 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the intra-server delay control device 100. 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 .

[0130] The CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and controls each part of the intra-server delay control device 100 shown in Fig. 1. 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.

[0131] 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.

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

[0133] 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 a 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 Disc), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0134] For example, when the computer 900 functions as the in-server delay control device 100 configured as one device according to this embodiment, the CPU 901 of the computer 900 realizes the functions of the in-server delay control device 100 by executing the program loaded on the RAM 903. Also, the HDD 904 stores the data in the RAM 903. The CPU 901 reads and executes the program related to the target process from the recording medium 912. Additionally, the CPU 901 may read the program related to the target process from another device via the communication network (NW 920).

[0135] [Application Example] The in-server delay control device 100 only needs to be an in-server delay control device that starts a thread for monitoring packet arrival using the polling model in the Kernel, and the OS is not limited. Also, it is not limited to being under the server virtualization environment. Therefore, the in-server delay control system 1000 can be applied to each configuration shown in FIGS. 7 and 8.

[0136] <Example of Application to VM Configuration> FIG. 7 is a diagram showing an example in which the in-server delay control system 1000A is applied to the interrupt model in a general-purpose Linux kernel (registered trademark) and server virtualization environment with a VM configuration. The same reference numerals are given to the same components as in FIGS. 1 and 9. As shown in FIG. 7, in the in-server delay control system 1000A, the in-server delay control device 100 is arranged in the Kernel 171 of the Guest OS 70, and the in-server delay control device 100 is arranged in the Kernel 91 of the Host OS 90.

[0137] Specifically, the server includes a Host OS 90 in which a virtual machine and an external process formed outside the virtual machine can operate, and a Guest OS 70 that operates inside the virtual machine. HostOS90 comprises a Kernel91, a Ring Buffer22 managed by the Kernel91 in the memory space of a server equipped with the HostOS90, a poll_list186 (Figure 2) that registers information about network devices indicating which device the hardware interrupt (hardIRQ) from the NIC11 belongs to, a vhost-net module 221 which is a kernel thread, a tap device 222 which is a virtual interface created by the Kernel91, and a virtual switch (br) 223.

[0138] The kernel 91 includes an intra-server delay control device 100 . The kernel 91 transmits the packet to the virtual machine 30 via the tap device 222 .

[0139] On the other hand, GuestOS70 comprises Kernel171, Ring Buffer52 managed by Kernel171 in the memory space of the server having GuestOS70, poll_list186 (Figure 2) which registers information on network devices indicating which device the hardware interrupt (hardIRQ) from NIC11 belongs to, and Socket75 which is an interface for Kernel171 to perform inter-process communication.

[0140] The kernel 171 includes an intra-server delay control device 100 and a protocol processing unit 74 that performs protocol processing of the reaped packet. The kernel 171 transmits the packet to the packet processing APL 1 via the protocol processing unit 74 .

[0141] By doing so, in a system with a virtual server configuration of VMs, in both the HostOS 90 and the GuestOS 70, it is possible to perform packet transfer with reduced delay within the server without modifying the APL.

[0142] <Example of application to container configuration> 8 is a diagram showing an example in which an intra-server delay control system 1000B is applied to an interrupt model in a server virtualization environment with a container configuration. The same components as those in FIG. 1 are denoted by the same reference numerals. 8, the intra-server delay control system 1000B includes a Guest OS 180 and a container configuration in which the OS is replaced with a Container 210. The Container 210 includes a vNIC (virtual NIC) 211. The intra-server delay control device 100 is disposed in a Kernel 181 of the Guest OS 180.

[0143] In systems with virtual server configurations such as containers, packet transfer can be performed with reduced latency within the server without modifying the APL.

[0144] <Example of application to paired metal configuration (non-virtualized configuration)> The present invention can be applied to systems with a non-virtualized configuration, such as a paired metal configuration. In a non-virtualized system, it is possible to transfer packets with reduced latency within the server without modifying APL3.

[0145] <Extension Technology> When the number of traffic flows increases, the present invention works in conjunction with RSS (Receive-Side Scaling), which can process inbound network traffic using multiple CPUs, to increase the number of CPUs assigned to the packet arrival monitoring thread, making it possible to scale out in response to network load.

[0146] [effect] As described above, the OS (OS70) has a kernel (Kernel171), a ring buffer (Ring Buffer72) managed by the kernel in the memory space in the server having the OS, and a poll list (poll_list186) that registers information on network devices indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC11) belongs to. The kernel is provided with an intra-server delay control device 100 that starts a thread that monitors packet arrivals using a polling model. The intra-server delay control device 100 has a packet arrival monitoring unit 110 that monitors (polling) the poll list, a packet reaping unit 120 that, if a packet has arrived, refers to the packet held in the ring buffer and performs reaping by deleting the corresponding queue entry from the ring buffer based on the next processing to be performed, and a sleep management unit 130 that puts the thread (polling thread) to sleep if no packet arrives for a specified period of time, and wakes up the thread (polling thread) from sleep mode when a packet arrives using a hardware interrupt (hardIRQ) of this thread.

[0147] In this way, the intra-server delay control device 100 stops software interrupts (softIRQ) for packet processing, which is the main cause of network delays, and the intra-server delay control device 100's packet arrival monitor 110 executes a thread that monitors packet arrivals, and the packet harvester 120 processes packets using a polling model (without softIRQ) when packets arrive. If no packets arrive for a specified period of time, the sleep management unit 130 puts the thread (polling thread) to sleep, so that the thread (polling thread) goes to sleep when no packets have arrived. The sleep management unit 130 releases sleep using a hardware interrupt (hardIRQ) when a packet arrives. This provides the following advantages (1) to (4).

[0148] (1) Software interrupts (softIRQs) that cause delays when packets arrive are stopped, and a polling model is implemented in the kernel (Kernel 171). In other words, unlike the existing technology NAPI, the intra-server delay control system 1000 implements a polling model rather than an interrupt model that is the main cause of network delays. When a packet arrives, it is immediately harvested without waiting, making it possible to implement low-delay packet processing.

[0149] (2) The polling thread in the intra-server delay control device 100 operates as a kernel thread and monitors packet arrivals in polling mode. The kernel thread (polling thread) that monitors packet arrivals sleeps while no packets have arrived. When no packets have arrived, the CPU is not used due to the sleep, which results in power saving effects.

[0150] Then, when a packet arrives, the polling thread that was sleeping is woken up (woke from sleep) by the hardIRQ handler when the packet arrives. By waking up from sleep by the hardIRQ handler, it is possible to immediately start the polling thread while avoiding softIRQ contention. A distinctive feature of this method is that sleep is not woken up by a timer, but by the hardIRQ handler. Note that if the traffic load is known in advance, for example, if a 30 ms sleep is known as the workload transfer rate shown in Figure 13, then the hardIRQ handler may be woken up at this timing.

[0151] In this way, the intra-server delay control device 100 can achieve both low delay and power saving by performing sleep management of the polling thread that performs packet forwarding processing.

[0152] (3) It is not necessary to provide the APL with a function for high-speed packet forwarding, and the APL only needs to interwork with the existing POSIX socket API of the kernel (Kernel 171). That is, unlike the existing technology DPDK, the intra-server delay control system 1000 realizes a polling model in the kernel, and therefore no modification of the APL is required. Specifically, as shown in FIG. 10, it is not necessary to provide the packet processing APL 1A (see FIG. 10) with a function for high-speed packet forwarding (see dpdk (PMD) 2 in FIG. 10), and the packet processing APL 1 (see FIG. 1) of this intra-server delay control system 1000 only needs to interwork with the existing POSIX socket API of the kernel (no modification is made to the kernel protocol stack). For this reason, it is possible to realize the system without modifying the APL.

[0153] (4) For the same reason, this can be achieved without the need to create a custom kernel.

[0154] Furthermore, a Guest OS (Guest OS 70) running within the virtual machine has a kernel (Kernel 171), a ring buffer (Ring Buffer 72) managed by the kernel in a memory space within the server having the Guest OS, a poll list (poll_list 186) for registering information on network devices indicating which device a hardware interrupt (hardIRQ) from the interface unit (NIC 11) belongs to, and a protocol processing unit 74 for performing protocol processing of a packet for which reaping has been executed. The kernel is provided with an intra-server delay control device 100 for starting up a thread for monitoring arrival of a packet using a polling model. The intra-server delay control device 100 has a packet arrival monitoring unit 110 for monitoring (polling) the poll list, a packet reaping unit 120 for reaping a packet that has arrived and that refers to the packet held in the ring buffer and deletes the entry of the corresponding queue from the ring buffer based on the next process to be performed, and a polling thread for putting the thread to sleep if a packet has not arrived for a predetermined period of time, and for starting up the thread when a packet has arrived. and a sleep management unit 130 that performs sleep release by a hardware interrupt (hardIRQ) of the CPU 110.

[0155] By doing this, in a system with a VM virtual server configuration, for a server equipped with a Guest OS (Guest OS 70), it is possible to reduce power consumption while minimizing delays within the server and perform packet transfer without modifying the APL.

[0156] A Host OS (HostOS90) on which a virtual machine and an external process formed outside the virtual machine can operate includes a kernel (Kernel91), a ring buffer (Ring Buffer22) managed by the kernel in a memory space in a server having the Host OS, a poll list (poll_list186) for registering information on a network device indicating which device a hardware interrupt (hardIRQ) from an interface unit (NIC11) belongs to, and a tap device 222 which is a virtual interface created by the kernel (Kernel91). The kernel includes an intra-server delay control device 100 which starts a thread (thread) for monitoring arrival of packets using a polling model. The intra-server delay control device 100 includes a packet arrival monitoring unit 110 which monitors (polling) the poll list, a packet reaping unit 120 which, if a packet has arrived, refers to the packet held in the ring buffer (Ring Buffer72) and executes reaping to delete the entry of the corresponding queue from the ring buffer (Ring Buffer72) based on the next process, and, if a packet has not arrived for a predetermined period of time, starts a thread (polling and a sleep management unit 130 that puts a polling thread into sleep and, when a packet arrives, wakes up the thread by a hardware interrupt (hardIRQ).

[0157] By doing this, in a system with a VM virtual server configuration, for a server equipped with a kernel (Kernel 171) and a Host OS (Host OS 90), it is possible to reduce power consumption while minimizing delays within the server and perform packet transfer without modifying the APL.

[0158] The intra-server delay control device 100 is characterized by comprising a CPU frequency setting unit (CPU frequency / CPU idle setting unit 140) that sets the CPU operating frequency of the CPU core used by the thread to a low value during sleep.

[0159] In this way, the intra-server delay control device 100 dynamically varies the CPU operating frequency in accordance with the traffic; in other words, if the CPU is not used due to sleep, the CPU operating frequency during sleep can be set low, thereby further enhancing the power saving effect.

[0160] The intra-server delay control device 100 is characterized by comprising a CPU idle setting unit (CPU frequency / CPU idle setting unit 140) that sets the CPU idle state of the CPU core used by the thread to a power saving mode during sleep.

[0161] By doing this, the server delay control device 100 can dynamically change the CPU idle state (power saving function according to the CPU model, such as changing the operating voltage) in accordance with the traffic, thereby further enhancing the power saving effect.

[0162] In the intra-server delay control device 100, the kernel (Kernel 171) is characterized by having a patch (livepatch) capable of changing the processing operation while the kernel (Kernel 171) is running.

[0163] In this way, the intra-server delay control device 100 can change the processing operation while the kernel 171 is running using livepatch, so there is no need to modify the kernel. Therefore, the intra-server delay control device 100 does not need to be redeveloped every time a kernel security update is performed, for example, and the processing operation needs to be changed only when a change is made to a related kernel function.

[0164] In addition, among the processes described in 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.

[0165] 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]

[0166] 1 Packet processing APL (application) 10 HW 11 NIC (physical NIC) (interface part) 70 OS 74 Protocol Processing Unit 60 user space 72 Ring Buffer 90 Host OS (OS) 91,171,181 Kernel 100 Server delay control device (polling thread) 110 Packet arrival monitor 120 Packet Harvesting Unit 130 sleep management department 140 CPU frequency / CPU idle setting section (CPU frequency setting section, CPU idle setting section) 180 Guest OS (OS) 186 poll_list 210 Container 1000, 1000A, 1000B Server Delay Control System

Claims

1. A server-internal delay control device, The OS, The kernel, a ring buffer managed by the kernel in a memory space in the server having the OS; a poll list for registering information on a network device indicating which device a hardware interrupt from the interface unit belongs to; The server delay control device includes a thread in the kernel that uses a polling model to monitor packet arrivals, The server internal delay control device includes: A packet arrival monitor that monitors the poll list; a packet reaping unit that, when a packet has arrived, refers to the packet held in the ring buffer and executes reaping to delete the corresponding queue entry from the ring buffer based on the next process; 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. A server-internal delay control device, The guest OS running in the virtual machine The kernel, a ring buffer managed by the kernel in a memory space in the server having the Guest OS; a poll list for registering information on a network device that indicates which device a hardware interrupt from the interface unit belongs to; a protocol processing unit that performs protocol processing of the reaped packet, The server delay control device includes a thread in the kernel that uses a polling model to monitor packet arrivals, The server internal delay control device includes: A packet arrival monitor that monitors the poll list; a packet reaping unit that, when a packet has arrived, refers to the packet held in the ring buffer and executes the reaping to delete the corresponding queue entry from the ring buffer based on the next process; 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:

3. A server-internal delay control device, A host OS in which a virtual machine and an external process formed outside the virtual machine can operate, The kernel, a ring buffer managed by the kernel in a memory space in the server having the Host OS; a poll list for registering information on a network device that indicates which device a hardware interrupt from the interface unit belongs to; a tap device that is a virtual interface created by the kernel; The server delay control device includes a thread in the kernel that uses a polling model to monitor packet arrivals, The server delay control device includes: A packet arrival monitor that monitors the poll list; a packet reaping unit that, when a packet has arrived, refers to the packet held in the ring buffer and executes reaping to delete the corresponding queue entry from the ring buffer based on the next process; 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:

4. A CPU frequency setting unit is provided for setting a lower CPU operating frequency of a CPU core used by the thread during the sleep state. The server delay control device according to any one of claims 1 to 3.

5. a CPU idle setting unit that sets the CPU idle state of the CPU core used by the thread to a power saving mode during the sleep mode; The server delay control device according to any one of claims 1 to 3.

6. The kernel has a patch that can change the processing operation while the kernel is running. The server delay control device according to any one of claims 1 to 3.

7. A method for controlling delay in a server of an intra-server delay control device, comprising: The OS, The kernel, a ring buffer managed by the kernel in a memory space in the server having the OS; a poll list for registering information on a network device indicating which device a hardware interrupt from the interface unit belongs to; a server-internal delay control device that starts a thread in the kernel to monitor packet arrival using a polling model; The server delay control device includes: monitoring the poll list; a step of executing pruning for deleting a corresponding queue entry from the ring buffer based on a next process, by referring to the packet held in the ring buffer when a packet has arrived; 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. The OS, The kernel, a ring buffer managed by the kernel in a memory space in the server having the OS; a poll list for registering information on a network device indicating which device a hardware interrupt from the interface unit belongs to; The kernel includes an intra-server delay control device that starts a thread that monitors packet arrival using a polling model, and the computer as the intra-server delay control device includes: a packet arrival monitoring procedure for monitoring the poll list; a packet pruning step of, if a packet has arrived, referencing the packet held in the ring buffer and deleting the corresponding queue entry from the ring buffer based on the next process; a sleep management procedure for 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 program for executing the above.

Images