Servers and Programs

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 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, container, etc.) environment, so that it can be used as needed like a component to improve operability. This form is called SFC (Service Function Chaining) and 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) with the KVM module incorporated 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 inside 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) for register control necessary for interrupt handling from the hardware to the Guest OS and 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] [Packet forwarding using an interrupt model (example of a general-purpose VM configuration)] Figure 9 illustrates packet forwarding using an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and VM configuration. HW10 has a NIC (Network Interface Card) 11 (physical NIC) (interface unit) and communicates with packet processing APL (Application) 1 on user space 60 for sending and receiving data via a virtual communication path established by Host OS 20, KVM 30 (a hypervisor that builds virtual machines), virtual machines (VM1, VM2) 40, and Guest OS 50. In the following description, as shown by the thick arrow in Figure 9, the data flow in which packet processing APL1 receives packets from HW10 is referred to as Rx-side reception, and the data flow in which packet processing APL1 sends packets to HW10 is referred to as Tx-side transmission.

[0008] Host OS20 has kernel21, Ring Buffer22, and Driver23. Kernel21 has a kernel thread vhost-net module221, a tap device222, and a virtual switch(br)223.

[0009] The tap device 222 is a kernel device for the virtual network and is supported by software. Virtual machine (VM1) 40 can communicate with Guest OS 50 and Host OS 20 via a virtual switch (br) 223 created on the virtual bridge (bridge). The tap device 222 is the device that connects to the virtual NIC (vNIC) of Guest OS 50, which is created on this virtual bridge.

[0010] Host OS20 copies configuration information (such as the size of the shared buffer queue, the number of queues, identifiers, and the starting address information for accessing the ring buffer) built within the virtual machine of Guest OS50 to the vhost-net module 221, and builds the endpoint information on the virtual machine side within Host OS20. This vhost-net module 221 is a kernel-level backend for virtio networking, and virtualization overhead can be reduced by moving the virtio packet processing task from the user area (user space) to the vhost-net module 221 in kernel21.

[0011] Guest OS50 consists of Guest OS (Guest1) installed on virtual machine (VM1) and Guest OS (Guest2) installed on virtual machine (VM2), and Guest OS50 (Guest1,Guest2) runs within virtual machines (VM1,VM2)40. Taking Guest1 as an example of Guest OS50, Guest OS50 (Guest1) has kernel51, Ring Buffer52, and Driver53, and Driver53 includes virtio-driver531.

[0012] Specifically, within the virtual machine, there are virtio devices for the console, file input / output, and network communication, each acting as a PCI (Peripheral Component Interconnect) device (the console is called virtio-console, file input / output is called virtio-blk, and network is called virtio-net, and the corresponding OS drivers for these devices are defined in the virtio queue). When the Guest OS starts, two endpoints for data transfer (sending and receiving endpoints) are created between the Guest OS and the other side, establishing a parent-child relationship for data transmission and reception. In most cases, the parent-child relationship consists of the virtual machine (child side) and the Guest OS (parent side).

[0013] The child side exists as configuration information for devices within the virtual machine, requesting from the parent side the size of each data area, the number of endpoint combinations required, and the type of device. The parent side, in accordance with the child side's request, allocates and secures memory for a shared buffer queue to store and transfer the necessary data, and returns its address to the child side so that the child side can access it. All operations on the shared buffer queue required for data transfer are common in virtio and are executed with the agreement of both the parent and child sides. 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 queue shared by both sides simply by providing the address to the child side.

[0014] In virtio, the shared buffer queues are designed for unidirectional communication. For example, a virtual network device called a virtio-net device consists of three Ring Buffer 52s: one for sending, one for receiving, and one for control. Communication between parent and child devices is achieved through writing to the shared buffer queue and notifying the other party of buffer updates. After writing to the Ring Buffer 52, the other party is notified. Upon receiving the notification, the other party uses virtio's common operations to check which shared buffer queue contains how much new data and retrieves the new buffer area. This completes the transfer of data from parent to child or from child to parent.

[0015] As described above, by sharing the Ring Buffer 52 for data exchange and the operation method for each ring buffer (common in virtio) between the parent and child devices, communication between Guest OS 50 and the outside world is achieved without the need for hardware emulation. This makes it possible to send and receive data between Guest OS 50 and the outside world at a much faster speed compared to conventional hardware emulation.

[0016] When Guest OS50 within a virtual machine communicates with the outside world, the child OS must connect to the outside world and act as a relay between the outside world and the parent OS to send and receive data. For example, communication between Guest OS50 and Host OS20 is one such example. In this case, assuming Host OS20 is the outside world, there are two existing communication methods.

[0017] The first method (hereinafter referred to as external communication method 1) involves constructing a child endpoint within the virtual machine and connecting the communication endpoint (usually called a tap / tun device) provided by the Host OS20 to the virtual machine for communication between the Guest OS50 and the virtual machine. This connection establishes the following connection and enables communication from the Guest OS50 to the Host OS20.

[0018] In this scenario, Guest OS50 operates in a user-space memory area with different privileges than the kernel space memory area where the tap driver and Host OS20 run. Therefore, communication from Guest OS50 to Host OS20 requires at least one memory copy.

[0019] The second method (hereinafter referred to as external communication method 2) uses a technology called vhost-net to solve this problem. With vhost-net, the configuration information of the parent side (size of the shared buffer queue, number of queues, identifier, starting address information for accessing the ring buffer, etc.) that has been built within the virtual machine is copied to the vhost-net module 221 inside the Host OS 20, and the information of the child side endpoint is built inside the host. This construction makes it possible to directly perform operations on the shared buffer queue between the Guest OS 50 and the Host OS 20. As a result, the number of copies required is effectively zero, and compared to virtio-net, the number of copies is one less, resulting in faster data transfer compared to external communication method 1.

[0020] In this way, by reducing the number of memory copies related to virtio-net between Host OS20 and Guest OS50 connected via virtio, packet forwarding processing can be sped up.

[0021] Furthermore, with kernel v4.10 (2017.2~) and later, the tap interface specifications have been changed, and packets inserted from a tap device are now processed within the same context as the packet copy operation to the tap device. As a result, software interrupts (softIRQs) no longer occur.

[0022] [Packet forwarding using a 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 the standard for connecting VMs. However, because this method has significant communication latency, faster methods have been proposed. For example, methods using special hardware called SR-IOV (Single Root I / O Virtualization) and software-based methods using the high-speed packet processing library Intel DPDK (Intel Data Plane Development Kit) (hereinafter referred to as DPDK) have been proposed (see Non-Patent Literature 1).

[0023] DPDK is a framework for controlling NICs (Network Interface Cards) in user space, a task traditionally handled by the Linux kernel. The biggest difference from the Linux kernel's processing is its polling-based receiving mechanism called PMD (Pull Mode Driver). Normally, the Linux kernel triggers an interrupt upon data arrival at the NIC, which then initiates the receiving process. In contrast, PMD uses a dedicated thread to continuously check for data arrival and perform receiving processing. By eliminating overhead such as context switching and interrupts, it enables high-speed packet processing. DPDK significantly improves packet processing performance and throughput, freeing up more time for data plane application processing.

[0024] DPDK exclusively uses computer resources such as the CPU (Central Processing Unit) and NIC. Therefore, it is difficult to apply to applications that require flexible module-based switching, such as SFCs. SPP (Soft Patch Panel) is an application that mitigates this limitation. SPP eliminates packet copying at the virtualization layer by providing shared memory between VMs, allowing each VM to directly access the same memory space. Furthermore, it uses DPDK to accelerate packet exchange between the physical NIC and shared memory. SPP can software-change the input and output destinations of packets by controlling the memory exchange references of each VM. Through this process, SPP enables dynamic connection switching between VMs and between VMs and physical NICs.

[0025] Figure 10 illustrates packet forwarding using the polling model in the OvS-DPDK (Open vSwitch with DPDK) configuration. Components identical to those in Figure 9 are denoted by the same reference numerals, and explanations of these redundant parts are omitted. As shown in FIG. 10, the Host OS 20 includes OvS-DPDK 70 which is software for packet processing. OvS-DPDK 70 has 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). Also, the packet processing APL1A includes a dpdk (PMD) 2 which is a functional unit for performing 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. 9 by equipping it with the dpdk (PMD) 2.

[0026] Packet transfer by the polling model enables path operation through a GUI in the SPP that performs high-speed packet copying between the Host OS 20 and the Guest OS 50, and between Guest OS 50s, with zero copy via shared memory as an extension of DPDK.

[0027] [Rx-side Packet Processing by New API (NAPI)] FIG. 11 is a schematic diagram of Rx-side packet processing by the New API (NAPI) implemented from 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 arranged in the user space 60 that can be used by a user on a server equipped with an OS 70 (for example, the Host OS), and performs packet transfer between the NIC 11 of the HW 10 connected to the OS 70 and the packet processing APL1.

[0028] The OS 70 has a kernel 71, a Ring Buffer 72, and a Driver 73, and the kernel 71 has a protocol processing unit 74. Kernel71 is a core function of the OS70 (e.g., Host OS), which monitors hardware and manages the execution status of programs in terms of processes. Here, Kernel71 responds to requests from the packet processing APL1 and conveys requests from the HW10 to the packet processing APL1. Kernel71 processes requests from the packet processing APL1 through system calls (where a "user program operating in non-privileged mode" requests processing from a "kernel operating in privileged mode"). Kernel71 transmits packets to the packet processing APL1 via Socket75. Kernel71 receives packets from the packet processing APL1 via Socket75.

[0029] Ring Buffer72 is managed by Kernel71 and exists in the memory space of the server. Ring Buffer72 is a buffer of a certain size that stores messages output by Kernel71 as logs, and when the upper limit size is exceeded, it is overwritten from the beginning.

[0030] Driver73 is a device driver for Kernel71 to monitor hardware. Note that Driver73 depends on Kernel71, and if the created (built) kernel source changes, it becomes a different thing. In this case, the corresponding driver source needs to be obtained, rebuilt on the OS using the driver, and the driver is created.

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

[0032] 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, packet processing APL1 can call system calls such as read() and write() on kernel71.

[0033] 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 11, packet forwarding using the interrupt model involves waiting for interrupt processing (see symbol c in Figure 11), which increases the delay in packet forwarding.

[0034] The following describes the overview of packet processing on the NAPI Rx side. [Rx-side packet processing configuration using New API (NAPI)] Figure 12 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 11. <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 occurs on NIC11 and executes the requested processing (hardware interrupt); and netif_rx82, which is a software interrupt processing function unit.

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

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

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

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

[0039] 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 e in Figure 12), and netif_rx82 executes the following process so that Kernel71 can recognize the packet. Note that hardIRQ81, enclosed in an ellipse in Figure 12, represents the handler, not the functional part.

[0040] netif_rx82 is the function that actually performs the processing. When hardIRQ81 (handler) is activated (see symbol f in Figure 12), it saves information about the net device (net_device), which indicates which device the hardware interrupt from NIC11 is from—one of the pieces of information inside the hardware interrupt (hardIRQ)—in poll_list86, and registers queue plucking (referencing the contents of packets accumulated in the buffer and deleting the corresponding queue entry from the buffer, taking into account the next processing to be performed) (see symbol g in Figure 12). Specifically, when netif_rx82 receives that packets have been packed into Ring Buffer72, it uses the NIC11 driver to register subsequent queue plucking in poll_list86 (see symbol g in Figure 12). As a result, poll_list86 contains queue plucking information due to packets being packed into Ring Buffer72.

[0041] Thus, Figure 12<Device driver> In this scenario, when NIC11 receives a packet, it copies the arriving packet to Ring Buffer72 via DMA transfer. NIC11 also raises hardIRQ81 (a handler), and netif_rx82 registers net_device in poll_list86, scheduling a software interrupt (softIRQ). Up to this point, Figure 12<Device driver> Hardware interrupt processing in this case will be stopped.

[0042] Subsequently, netif_rx82 uses the information (specifically pointers) in the queue stored in poll_list86 to raise a software interrupt (softIRQ) to softIRQ83 (handler) (see code h in Figure 12) to pluck the data stored in Ring Buffer72, and notifies do_softirq84, the software interrupt control unit (see code i in Figure 12).

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

[0044] 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 k in Figure 12), and plucks packets (see code l in Figure 12). At this time, net_rx_action85 continues plucking until poll_list86 is empty. Subsequently, net_rx_action85 notifies netif_receive_skb87 (see symbol m in Figure 12).

[0045] 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 11) 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 n in Figure 12), and if it is L2, for example, the process is passed to arp_rcv89 (symbol o in Figure 12).

[0046] Non-patent document 3 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. [Prior art documents] [Non-patent literature]

[0047] [Non-Patent Document 1] “Developer Quick Start Guide Learn How To Get Involved With DPDK,” Intel, [online], [Accessed March 5, 2021], Internet <URL: https: / / www.dpdk.org / > [Non-Patent Document 2] New API (NAPI), [online], [Searched 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. [Overview of the project] [Problems that the invention aims to solve]

[0048] However, 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, which is performed by the kernel upon 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, as shown in Figure 9, packet forwarding using an interrupt model involves packet forwarding via interrupt processing (see symbols a and b in Figure 9), which results in delays due to waiting for interrupt processing.

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

[0050] Similarly, packet processing using the New API (NAPI) also results in network delays on the order of milliseconds due to contention in interrupt handling (softIRQ), as shown in the dashed box p in Figure 12.

[0051] On the other hand, the polling model occupies the CPU to poll the communication queue and immediately captures packets upon arrival. While the polling model can reduce forwarding delay, it requires modifications to the APL because it necessitates incorporating polling functionality into the APL itself. For example, as shown in Figure 10, packet forwarding using a 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 OS50 section, and thus requires modification of the packet processing APL1.

[0052] Furthermore, the KBP described in Non-Patent Document 3 can suppress softIRQs and achieve low-latency packet processing by constantly monitoring packet arrivals using a polling model within the kernel. However, a challenge arises in that the kernel thread that constantly monitors packet arrival occupies a CPU core and always uses CPU time, resulting in high power consumption. Refer to Figures 13 and 14 to explain the relationship between workload and CPU utilization.

[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 performs intermittent data transfer every 30 ms.

[0054] Figure 14 shows the CPU usage rate used by the busy poll thread in the KBP described in Non-Patent Document 3. As shown in Figure 14, in KBP, the kernel thread occupies a CPU core to perform busy polling. Even with intermittent packet reception as shown in Figure 13, KBP always uses the CPU regardless of whether packets have arrived or not, which presents the challenge of high power consumption.

[0055] In light of this background, the present invention was made, and its objective is to reduce power consumption, minimize latency within the server, and perform packet forwarding without modifying the APL. [Means for solving the problem]

[0056] To solve the aforementioned problems, a server that performs packet processing including polling within the kernel, wherein the server includes a packet arrival monitoring unit that monitors the arrival of packets, Polling only It includes a sleep management unit that puts threads to sleep, The server starts the polling-dedicated thread that performs polling processing within the kernel, and the packet arrival monitoring unit monitors packet arrivals using the polling-dedicated thread, rather than the execution context of a software interrupt. The aforementioned sleep management unit, By the aforementioned polling-dedicated thread packet Depending on whether or not it has arrived, the dedicated polling service will be used. The server is characterized by its ability to put threads to sleep. [Effects of the Invention]

[0057] According to the present invention, packet forwarding can be performed with reduced latency within the server without modifying the APL, while also reducing power consumption. [Brief explanation of the drawing]

[0058] [Figure 1] This is a schematic diagram of a server-internal delay control system according to an embodiment of the present invention. [Figure 2] This figure illustrates the details of Rx-side packet processing using the New API (NAPI) in a server-internal delay control system according to an embodiment of the present invention. [Figure 3]This figure shows an example of polling thread operation in a server-internal delay control system according to an embodiment of the present invention. [Figure 4] This flowchart shows the Rx-side operation and power saving management process of the server-internal delay control device of the server-internal delay control system according to an embodiment of the present invention. [Figure 5] This flowchart shows the CPU frequency / CPU idle setting process for power saving of the in-server delay control device of the in-server delay control system according to an embodiment of the present invention. [Figure 6] This hardware configuration diagram shows an example of a computer that implements the functions of an in-server delay control device in an in-server delay control system according to an embodiment of the present invention. [Figure 7] This figure shows an example of applying an in-server delay control system to the interrupt model in a server virtualization environment using a general-purpose Linux kernel and VM configuration. [Figure 8] This figure shows an example of applying an in-server delay control system to the interrupt model in a containerized server virtualization environment. [Figure 9] This diagram illustrates packet forwarding using an interrupt model in a server virtualization environment with a general-purpose Linux kernel and VM configuration. [Figure 10] This diagram illustrates packet forwarding using a polling model in the OvS-DPDK configuration. [Figure 11] This is a schematic diagram of Rx-side packet processing using the New API (NAPI) implemented in Linux kernel 2.5 / 2.6. [Figure 12] Figure 11 shows an overview of Rx-side packet processing by the New API (NAPI) in the area enclosed by the dashed line. [Figure 13] This figure shows an example of video (30 FPS) data transfer. [Figure 14] This figure shows the CPU usage rate used by the busy poll thread in the KBP described in Non-Patent Document 3. [Modes for carrying out the invention]

[0059] 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. [overview] Figure 1 is a schematic diagram of a server-based delay control system according to an embodiment of the present invention. This embodiment is an example applied to Rx-side packet processing using the New API (NAPI) implemented in Linux kernel 2.5 / 2.6. Components identical to those in Figure 11 are denoted by the same reference numerals. As shown in Figure 1, the server-internal delay control system 1000 executes a packet processing APL1 located in the user space 60 available to the user on a server equipped with OS 70 (e.g., Host OS), and performs packet forwarding between the NIC 11 of the HW 10 connected to OS 70 and the packet processing APL1.

[0060] OS70 includes kernel171, ring buffer72, and driver73, and kernel171 includes server-internal delay control device100 and protocol processing unit74.

[0061] In this embodiment, kernel 171 is given a new number to distinguish it from kernel 71 shown in Figure 11, because it includes an in-server delay control device 100. Kernel 171 has the same functionality as kernel 71 shown in Figure 11, except that it has an in-server delay control device 100 installed. However, kernel 171 can be implemented without modifying (rebuilding) the existing kernel 71 (see Figure 11) by using livepatch (described later).

[0062] kernel171 is a core component of OS70 (e.g., the Host OS), managing hardware monitoring and program execution status on a process-by-process basis. Here, kernel171 responds to requests from packet processing APL1 and also relays requests from HW10 to packet processing APL1. kernel171 processes requests from packet processing APL1 via system calls. kernel171 sends packets to packet processing APL1 via Socket75. Kernel71 receives packets from packet processing APL1 via Socket75.

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

[0064] Driver73 is a device driver used in kernel171 to monitor hardware.

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

[0066] Socket 75 is the interface that kernel 171 uses for inter-process communication. Socket 75 has a socket buffer and does not frequently perform data copying operations.

[0067] <Server-based delay control device> The server-internal delay control device 100 includes a packet arrival monitoring unit 110, a packet harvesting unit 120, a sleep management unit 130, and a CPU frequency / CPU idle setting unit 140 (CPU frequency setting unit, CPU idle setting unit).

[0068] The packet arrival monitoring unit 110 is a thread that monitors whether packets have arrived. The packet arrival monitoring unit 110 monitors (polls) poll_list 186 (see Figure 2).

[0069] The packet arrival monitoring unit 110 obtains pointer information and net_device information indicating the presence of packets in Ring_Buffer 72 (see Figure 2) from poll_list 186, and transmits this information (pointer information and net_device information) to the packet harvesting unit 120. If there is information for multiple packets in poll_list 186, the unit transmits the information for each packet.

[0070] If a packet has arrived, the packet harvesting unit 120 refers to the packet held in Ring Buffer 72 and performs harvesting by deleting the corresponding queue entry from Ring Buffer 72 based on the next processing to be performed (hereinafter, this may simply be referred to as harvesting packets from Ring Buffer 72). Based on the received information, the packet harvesting unit 120 retrieves the packet from Ring Buffer 72 and transmits the packet to netif_receive_skb87.

[0071] The sleep management unit 130 puts a polling thread to sleep if no packets arrive for a predetermined period of time, and wakes the polling thread from sleep via a hardware interrupt (hardIRQ) when a packet arrives (details below).

[0072] The CPU frequency / CPU idle setting unit 140 lowers the CPU operating frequency of the CPU core used by the polling thread while the system is asleep. The CPU frequency / CPU idle setting unit 140 also sets the CPU idle state of the CPU core used by this polling thread to power-saving mode while the system is asleep (details below).

[0073] Figure 2 is a diagram illustrating the details of Rx-side packet processing using the New API (NAPI) of the server-internal delay control system 1000 shown in Figure 1. Components identical to those in Figures 1 and 12 are denoted by 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 occurs on NIC11 and executes the requested processing (hardware interrupt); and netif_rx182, which is a software interrupt processing function unit.

[0074] <Networking layer> The networking layer includes poll_list186, which registers net device information indicating which device the hardware interrupt from NIC11 originates from; packet arrival monitoring unit 110; netif_receive_skb87, which creates an sk_buff structure (kernel171 is a structure indicating the packet state) for socket communication where no interrupts occur, and Ring Buffer72, for packets that have been picked up from the queue.

[0075] <Protocol layer> The protocol layer contains packet processing functions such as ip_rcv88 and arp_rcv89. Note that protocol processing is also performed by functions other than ip_rcv88 and arp_rcv89.

[0076] The above netif_rx182, netif_receive_skb87, ip_rcv88, and arp_rcv89 are program components (function names) called for packet processing within Kernel 171.

[0077] The operation of the server-internal delay control system 1000 will be described below. [Rx-side packet processing operation according to the present invention] The arrows (signs) d~g and k~o in Figure 2 indicate the packet processing flow on the Rx side. When NIC11 receives a packet (or frame) within a frame from the peer device, it copies the arriving packet to Ring Buffer72 via DMA transfer without using the CPU (see symbol d in Figure 2). This Ring Buffer72 is located in the server's memory space and is managed by Kernel171 (see Figure 1).

[0078] When a packet arrives, NIC11 raises a hardware interrupt (hardIRQ) to hardIRQ81 (handler) (see code e in Figure 2), and netif_rx182 performs the following processing, allowing Kernel171 to recognize the packet.

[0079] When the hardwire81 (handler) is activated (see symbol f in Figure 2), netif_rx182 saves information about the net device (net_device), which indicates which device the hardware interrupt from NIC11 is from—one of the pieces of information inside the hardware interrupt (hardIRQ)—into poll_list186, and registers queue plucking information (see symbol g in Figure 2). Specifically, when netif_rx182 receives a packet in Ring Buffer72, it uses the NIC11 driver to register subsequent queue plucking in poll_list186 (see symbol g in Figure 2). As a result, poll_list186 registers the queue plucking caused by the packet being packed into Ring Buffer72.

[0080] netif_rx182 registers net_devices in poll_list186, but unlike netif_rx82 in Figure 12, it does not schedule software interrupts (softIRQs). In other words, netif_rx182 differs from netif_rx82 in Figure 12 in that it does not schedule software interrupts (softIRQs).

[0081] Furthermore, netif_rx182 performs a sleep wake-up operation to call the sleeping polling thread (see reference numeral p in Figure 2). This embodiment adds this polling thread wake-up operation (sleep wake-up) to the KBP described in Non-Patent Document 3. Up to this point, Figure 2<Device driver> Hardware interrupt processing in this case will be stopped.

[0082] In this embodiment, as shown in Figure 12<Networking layer> In this configuration, softIRQ83 and do_softirq84 are removed, and consequently, netif_rx82, as shown in Figure 12, no longer sends a notification to start softIRQ83 (handler) (see symbol h in Figure 12).

[0083] In this embodiment, the server-internal delay control system 1000 removes softIRQ83 and do_softirq84 shown in Figure 12, and instead shows the one shown in Figure 2.<Networking layer> A server-internal delay control device 100 is installed in the memory space within the server.

[0084] As shown in Figure 2<Networking layer> In this process, the packet arrival monitoring unit 110 of the server-internal delay control device 100 monitors (polling) poll_list 186 (see symbol k in Figure 2) to confirm whether or not a packet has arrived.

[0085] The packet arrival monitoring unit 110 obtains pointer information and net_device information indicating the presence of packets in Ring_Buffer 72 from poll_list 186 and transmits this information (pointer information and net_device information) to the packet harvesting unit 120 (see symbol q in Figure 2). If there is information for multiple packets in poll_list 186, the unit transmits the information for each packet.

[0086] The packet harvesting unit 120 of the server's delay control device 100 harvests packets from the Ring Buffer 72 if a packet has arrived (see reference numeral l in Figure 2). The packet harvesting unit 120 extracts packets from Ring_Buffer 72 based on the received information and transmits them to netif_receive_skb 87 (see symbol m in Figure 2).

[0087] In this way, the server-internal delay control system 1000 stops the softIRQ for packet processing, which is the main cause of network delay, and the packet arrival monitoring unit 110 of the server-internal delay control device 100 executes a polling thread to monitor packet arrival. Then, the packet harvesting unit 120 processes the packet using the polling model (without softIRQ) when a packet arrives.

[0088] In other words, the polling thread in the server's delay control device 100 operates as a kernel thread and monitors packet arrivals in polling mode. The packet arrival monitoring unit 110 monitors poll_list 186. The packet harvesting unit 120 retrieves packets from Ring Buffer 72 upon arrival and forwards them to netif_receive_skb 87.

[0089] When a packet arrives, a polling thread is triggered by a hardware interrupt handler, avoiding softIRQ contention and enabling immediate packet forwarding. In other words, by keeping the packet arrival monitoring function on standby as a kernel thread and triggering it with a hardware interrupt, it is possible to achieve lower latency than packet forwarding processing using software interrupts such as NAPI.

[0090] The kernel thread that monitors packet arrivals can sleep when no packets are arriving. The polling thread described above sleeps depending on whether a packet has arrived, and when a packet arrives, it is woken up by hardIRQ81. Specifically, the sleep management unit 130 of the server's delay control device 100 puts the polling thread to sleep depending on whether a packet has arrived, that is, if no packets have arrived for a certain period of time. The sleep management unit 130 wakes the polling thread up by hardIRQ81 when a packet arrives. This avoids softIRQ contention and achieves low latency.

[0091] The CPU frequency / CPU idle setting unit 140 of the server's internal delay control device 100 changes the CPU operating frequency and idle settings depending on whether a packet has arrived or not. Specifically, the CPU frequency / CPU idle setting unit 140 lowers the CPU frequency when the server is asleep and increases the CPU frequency (returns the CPU operating frequency to its original value) when the server is started again. In addition, the CPU frequency / CPU idle setting unit 140 changes the CPU idle setting to power saving when the server is asleep. Power saving is achieved by lowering the CPU operating frequency and changing the CPU idle setting to power saving when the server is asleep.

[0092] 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 11) 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 forwarded to ip_rcv88, and if it's L2, for example, the process is forwarded to arp_rcv89.

[0093] Figure 3 shows an example of the operation of the polling thread of the server's delay control device 100. The vertical axis shows the CPU utilization rate [%] of the CPU core used by the polling thread, and the horizontal axis shows time. Figure 3 shows an example of the polling thread operation due to packet arrival, corresponding to the data transfer example of video (30 FPS) where packets are received intermittently, as shown in Figure 13. As shown in Figure 3, the sleep management unit 130 of the server's delay control device 100 puts the polling thread to sleep if no packets arrive for a certain period of time (more specifically, if no further packets arrive after a fixed period predetermined by the maintenance / operator has elapsed since the arrival of a packet) (see symbol s in Figure 3). The sleep management unit 130 then activates the polling thread upon hardIRQ81 of a packet arrival (see symbol t in Figure 3). During sleep mode, the kernel thread does not exclusively use the CPU core. Therefore, in addition to being used by the polling thread, the CPU usage of the CPU core may fluctuate due to timer interrupts for system stability or migration threads for error handling (see symbol u in Figure 3).

[0094] [Registration process using live patch] Next, we will explain the registration process using live patch. The server-internal delay control system 1000 (see Figure 1) is implemented in kernel 171 of OS70 shown in Figure 1, which includes a server-internal delay control device 100. kernel 171 can be implemented without modifying (rebuilding) the existing kernel 71 (see Figure 11) by using livepatch. The following describes livepatch applied to kernel 171.

[0095] livepatch is a kernel patching feature applied to the Linux® kernel. Using livepatch, modifications can be applied instantly to the kernel space without restarting the system. In other words, (1) livepatch suppresses the softIRQ scheduling function of netif_rx182 (see Figure 2).

[0096] (2) livepatch starts a thread (packet arrival monitoring unit 110, specifically isol_net_rx) to monitor packet arrivals. When starting, the thread (packet arrival monitoring unit 110) occupies a CPU core to prevent interference from other processes or kernel threads with busy polls (see code k in Figure 2). For this purpose, 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 poll_list186 (see Figure 2) is assigned to monitor them. This enables scaling out according to traffic flow (traffic volume). Subsequently, the packet processing operations shown in Figure 2 are executed.

[0097] [Operation flow of Rx-side packet processing of server-internal delay control device 100] Figure 4 is a flowchart showing the Rx-side operation and power saving management processes of the server-internal delay control device 100 (see Figure 2). The Rx-side operation will be explained with reference to Figure 2. While the polling thread is running, this operation flow is executed in a loop. In step S1, the packet arrival monitoring unit 110 (see Figure 2) of the server's delay control device 100 exclusively monitors (poll) poll_list 186 (see Figure 2) using the CPU (see code k in Figure 2) to check whether packets have arrived.

[0098] In step S2, the packet arrival monitoring unit 110 (see Figure 2) determines whether or not there is pointer information in the poll list 186 that indicates the arrival of a packet. If poll list186 contains pointer information indicating packet arrival (S2:Yes), proceed to step S3. If poll list186 does not contain pointer information indicating packet arrival (S2:No), return to step S1.

[0099] In step S3, the packet arrival monitoring unit 110 obtains pointer information and NET_DEVICE information from poll_list 186 indicating the presence of packets in Ring_Buffer 72 (see Figure 2), and transmits this information (pointer information and NET_DEVICE information) to the packet harvesting unit 120 (see symbol q in Figure 2). If there is information for multiple packets in poll_list 186, the unit transmits the information for each packet.

[0100] In step S4, the packet harvesting unit 120 (see Figure 2) of the server's delay control device 100, if a packet has arrived, refers to the packet held in the Ring Buffer 72 and performs harvesting by deleting 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 harvesting unit 120 extracts a packet from Ring_Buffer 72 based on the received information and transmits the packet to netif_receive_skb 87 (see symbol m in Figure 2).

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

[0103] In step S8, the CPU frequency / CPU idle setting unit 140 lowers the operating frequency of the CPU core used by the polling thread and completes the processing of this flow. The CPU frequency / CPU idle setting unit 140 also enables CPU idle settings if possible.

[0104] Figure 5 is a flowchart showing the CPU frequency / CPU idle setting process for power saving in the server's delay control device 100. In step S11, the hardware interrupt processing unit (netif_rx182 in Figure 2), which is activated when a packet arrives, starts the polling thread (server-internal delay control device 100 in Figure 2) when the packet arrives. If the polling thread is already running, it continues as is. The sleep management unit 130 cancels sleep based on the hardIRQ when the 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 (returning the CPU core operating frequency to its original value) and terminates the processing of this flow. At this point, if the CPU idle setting has also been changed, the CPU frequency / CPU idle setting unit 140 also returns it to its original value.

[0106] <Additional Features> To prevent missing packets from poll_list186, you can periodically start a polling thread to check for incoming packets from poll_list186. This approach prevents packets from remaining in poll_list186 in the event of timing issues, such as simultaneous packet arrival via NIC11 and the polling thread going to sleep.

[0107] [Differences between this embodiment and existing technology] Next, we will explain the differences between this embodiment and existing technology (see Figure 12).

[0108] <Background> Generally, hardware interrupts (hardIRQs) have high priority and require interrupting the CPU's processing to process the hardIRQ with the highest priority. This results in significant overhead. Therefore, the design philosophy is to use hardIRQs only to signal packet arrival, with packet processing handled by softIRQs (known as the "kernel principle"). However, softIRQs can compete with other softIRQs, leading to delays (a cause of latency). The reason conventional technologies use an interrupt model is that, in the past, CPU resources were limited (or, to operate on devices with few CPU cores, such as single-board computers like the Raspberry Pi), so the design philosophy was 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, resulting in waiting time. Furthermore, ksoftirqd, the scheduler that schedules softIRQs, does not have a function to assign priorities according to the type of softIRQ, and therefore cannot prevent delays caused by this conflict.

[0109] <Existing technology (see Figure 12)> As shown in Figure 12, kernel71 (Figure 11) receives notification of packet arrival from NIC11 via hardIRQ81 (see code h in Figure 12) and schedules softIRQ83 for packet processing (see dashed line p in Figure 12). If this conflicts with other interrupt processing, a wait occurs, resulting in a network delay of the order of milliseconds.

[0110] <Server-based delay control system 1000 (see Figure 2)> Implementation of the packet arrival monitoring unit 110 and the packet harvesting unit 120 As shown in Figure 2, the server-internal delay control system 1000 is<Networking layer> In this configuration, netif_rx182 registers net_devices in poll_list186, but unlike the existing netif_rx82 (see Figure 12), it does not perform software interrupt (softIRQ) scheduling ("Change 1").

[0111] As shown in Figure 2, the server-internal delay control system 1000 is<Networking layer> A server-internal delay control device 100 is installed in the memory space within the server ("Change 2"). The packet arrival monitoring unit 110 of the server-internal delay control device 100 constantly monitors poll_list 186 (busy poll) (see code k in Figure 2) to check whether packets have arrived.

[0112] The packet arrival monitoring unit 110 obtains pointer information indicating the presence of a packet in Ring_Buffer 72 and NET_DEVICE information from poll_list 186, and transmits this information (pointer information and NET_DEVICE information) to the packet harvesting unit 120 (see symbol q in Figure 2).

[0113] The packet harvesting unit 120 of the server's delay control device 100 harvests packets from the Ring Buffer 72 if a packet has arrived (see reference numeral l in Figure 2).

[0114] The packet harvesting unit 120 extracts packets from Ring_Buffer 72 based on the received information and transmits them to netif_receive_skb 87 (see symbol m in Figure 2).

[0115] The effects of the above "Change 1" are as follows: First, in this embodiment, the notification of packet arrival via hardware interrupts (hardIRQ) follows NAPI. While softIRQ is convenient in terms of effectively utilizing CPU resources, it is not suitable from the perspective of immediate packet forwarding. Therefore, a novel aspect of this embodiment is that the softIRQ function is disabled and a polling model is implemented within the kernel. Specifically, this is shown by the fact that netif_rx182, as shown in Figure 2, does not notify the launch of softIRQ83 (handler) (see symbol h in Figure 12), as netif_rx82, as shown in Figure 12.

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

[0117] The effects of the above "Change 2" are as follows: In this embodiment, a dedicated polling thread (packet arrival monitoring unit 110 of the server-internal delay control device 100) is started within kernel 171 as shown in Figure 1, and the packet harvesting unit 120 of the server-internal delay control device 100 processes packets using the polling model (without softIRQ) upon arrival. This eliminates the need for APL modification; in other words, it becomes possible to use the existing POSIX socket API.

[0118] Furthermore, to prevent the aforementioned thread from having its CPU time stolen by other softIRQs, as described in [Registration via live patch] above, the thread is given exclusive CPU cores and high priority settings when it starts up, thus preventing interference with polling.

[0119] As described above, the server-internal delay control device 100 achieves low-latency packet forwarding by including a packet arrival monitoring unit 110 and a packet harvesting unit 120. Specifically, it stops software interrupts (softIRQ) upon packet arrival and implements a polling model within the kernel. A new kernel thread is created to monitor packet arrivals and monitors packet arrivals to poll_list186. As a result, packets are harvested immediately upon arrival without waiting, enabling low-latency packet processing.

[0120] Implementation of sleep management unit 130 and CPU frequency / CPU idle setting unit 140 The server-internal delay control device 100 further includes a sleep management unit 130 and a CPU frequency / CPU idle setting unit 140 to achieve power savings in addition to the low-latency packet processing described above. Specifically, the kernel thread that monitors packet arrival can sleep when no packets are arriving. The sleeping thread is woken up by the hardIRQ handler when a packet arrives, allowing for immediate startup while avoiding softIRQ contention. Power consumption is further reduced by adjusting the CPU operating frequency and CPU idle state in accordance with the above sleep state.

[0121] <Detailed operation of the sleep management unit 130 and the CPU frequency / CPU idle setting unit 140 (see Figure 2)> As shown in Figure 2, netif_rx182 is activated when the polling thread is sleeping upon packet arrival (see symbol p in Figure 2). If the polling thread is already running, it simply terminates the hardware interrupt handler without performing any specific action.

[0122] The CPU frequency / CPU idle setting unit 140 of the polling thread (server-internal 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 (returning the CPU core's operating frequency to its original value). Here, the kernel can change the operating frequency of the CPU cores through the governor setting, and the CPU frequency / CPU idle setting unit 140 can set a higher CPU operating frequency using the governor setting, etc. However, the CPU idle setting is CPU model dependent. Note that if the CPU core has enabled the CPU idle setting, it can also be disabled.

[0123] The packet arrival monitoring unit 110 checks whether a packet pointer is stored in poll_list186. If a pointer is stored, it transmits the corresponding pointer information and device driver information to the packet harvesting unit 120.

[0124] While the polling thread is running, the above operations are executed in a loop. Furthermore, the packet arrival check interval within this loop can be increased or decreased depending on the frequency of packet arrivals. For example, the number of packets arriving N per single unit of time T can be counted, and the check frequency can be set to N / T [packets / second] or higher. This adjustment can further reduce CPU usage.

[0125] The packet harvesting unit 120 harvests packets from the Ring Buffer 72 based on the received pointer information and device driver information. It then transmits the corresponding data to the netif_receive_skb87 (packet structure management unit) shown in Figure 2. netif_receive_skb87 creates the structures necessary for packet processing (such as the sk_buff structure) from the received data. The process then continues with protocol processing by the kernel.

[0126] When the sleep management unit 130 checks the packet pointers in the poll_list 186, it receives information from the packet arrival monitoring unit 110 about whether packets in poll_list 186 have arrived. Based on this packet arrival information, if the sleep management unit 130 determines that no packets have arrived for a certain period of time, it transmits this information to the CPU frequency / CPU idle setting unit 140.

[0127] The CPU frequency / CPU idle setting unit 140 receives a notification from the sleep management unit 130 when no packets arrive for a certain period of time, and sets the CPU operating frequency of the CPU core used by the polling thread to a lower value. At this time, the CPU frequency / CPU idle setting unit 140 enables the CPU idle setting if it is possible to do so (however, this is CPU model dependent).

[0128] The sleep management unit 130 puts the polling thread into sleep mode (puts it to sleep) after the CPU frequency / CPU idle setting unit 140 has finished setting it. Note that the process of lowering the CPU frequency setting and the process of putting the system into sleep mode may be executed simultaneously. Alternatively, the system may be put into sleep mode only after confirming that packet forwarding is complete.

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

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

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

[0132] HDD904 stores programs executed by CPU901 and data used by those programs. Communication I / F906 receives data from other devices via a communication network (e.g., NW(Network)920) and outputs it to CPU901, and also transmits data generated by CPU901 to other devices via the communication network.

[0133] The media interface 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 the program related to the desired processing from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded program. The recording medium 912 can be an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical Disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.

[0134] For example, when the computer 900 functions as the server internal delay control device 100 configured as one device according to the present embodiment, the CPU 901 of the computer 900 realizes the functions of the server internal 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 processing from the recording medium 912. Additionally, the CPU 901 may read the program related to the target processing from another device via the communication network (NW920).

[0135] [Applicable Example] The server internal delay control device 100 may be any server internal 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 a server virtualization environment. Therefore, the server internal 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 server internal delay control system 1000A is applied to the interrupt model in a server virtualization environment of a general-purpose Linux kernel (registered trademark) and a VM configuration. The same reference numerals are assigned to the same components as in FIGS. 1 and 9. As shown in FIG. 7, in the server internal delay control system 1000A, the server internal delay control device 100 is arranged in the Kernel 171 of the Guest OS 70, and the server internal 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 includes Kernel91, a Ring Buffer22 managed by Kernel91 in the memory space of the server equipped with HostOS90, poll_list186 (Figure 2) which registers information about network devices indicating which device the hardware interrupt (hardIRQ) from NIC11 belongs to, a kernel thread vhost-net module221, a tap device222 which is a virtual interface created by Kernel91, and a virtual switch (br)223.

[0138] Kernel91 includes an in-server delay control device 100. Kernel91 transmits packets to virtual machine 30 via tap device 222.

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

[0140] Kernel171 includes a server-internal delay control device 100 and a protocol processing unit 74 that performs protocol processing on packets that have been pruned. Kernel171 transmits packets to packet processing APL1 via protocol processing unit 74.

[0141] By doing so, in a virtual server configuration system using VMs, packet forwarding can be performed with reduced latency within the server, regardless of whether the HostOS90 or GuestOS70 operating system is used, without modifying the APL.

[0142] <Example of application to container configuration> Figure 8 shows an example of applying the server-internal delay control system 1000B to the interrupt model in a containerized server virtualization environment. The same reference numerals are used for components identical to those in Figure 1. As shown in Figure 8, the server-internal delay control system 1000B includes a Guest OS 180 and a container configuration in which the OS is replaced by Container 210. Container 210 has a vNIC (virtual NIC) 211. The server-internal delay control device 100 is located within the Kernel 181 of the Guest OS 180.

[0143] In systems with virtual server configurations such as containers, packet forwarding can be performed with reduced latency within the server without modifying the APL (Application Program Line).

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

[0145] <Advanced Technology> This invention enables scaling out to handle network load by increasing the number of CPUs allocated to a packet arrival monitoring thread in conjunction with RSS (Receive-Side Scaling), which allows multiple CPUs to process inbound network traffic when the number of traffic flows increases.

[0146] [effect] As explained above, the OS (OS70) includes a kernel (Kernel171), a ring buffer (Ring Buffer72) managed by the kernel in the memory space of the server equipped with the OS, and a poll list (poll_list186) that registers network device information indicating which device a hardware interrupt (hardIRQ) from the interface unit (NIC11) belongs to. The kernel also includes an in-server delay control device 100 that starts a thread to monitor packet arrivals using a polling model. The in-server delay control device 100 includes a packet arrival monitoring unit 110 that monitors the poll list (polling), a packet harvesting unit 120 that, if a packet has arrived, 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, and a sleep management unit 130 that puts the polling thread to sleep if no packets arrive for a predetermined period of time, and wakes the polling thread from sleep when a packet arrives due to a hardware interrupt (hardIRQ).

[0147] In this way, the server-internal delay control device 100 stops the software interrupt (softIRQ) for packet processing, which is the main cause of network delays. The packet arrival monitoring unit 110 of the server-internal delay control device 100 executes a thread to monitor packet arrivals, and the packet harvesting unit 120 processes packets using the polling model (without softIRQ) when they arrive. The sleep management unit 130 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 130 wakes the thread from sleep using a hardware interrupt (hardIRQ) when a packet arrives. This will produce the following effects (1) to (4).

[0148] (1) Software interrupts (softIRQ) that cause delays when packets arrive are stopped, and a polling model is implemented within the kernel (Kernel171). 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.

[0149] (2) The polling thread in the server's 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 when no packets arrive. When no packets arrive, the CPU is not used by sleeping, so power saving effects can be obtained.

[0150] When a packet arrives, the polling thread, which is currently sleeping, is woken (released from sleep) by the hardIRQ handler that receives the packet. By waking the sleep in the hardIRQ handler, the polling thread can be started immediately while avoiding softIRQ contention. Here, the key feature is that the sleep release is triggered by the hardIRQ handler, not by a timer. If the traffic load is known in advance, for example, if a 30ms sleep is known as shown in the workload transfer rate in Figure 13, the hardIRQ handler can be configured to wake the thread at this timing.

[0151] In this way, the server-internal delay control device 100 can achieve both low latency and low power consumption by managing the sleep state of the polling thread that performs packet forwarding processing.

[0152] (3) The APL does not need to be equipped with functions for high-speed packet forwarding; the APL only needs to interact with the existing POSIX socket API of the kernel (Kernel171). In other words, unlike the existing DPDK technology, the server-internal delay control system 1000 implements the polling model within the kernel, so no modification of the APL is required. Specifically, as shown in Figure 10, the packet processing APL1A (see Figure 10) does not need to be equipped with functions for high-speed packet forwarding (see dpdk(PMD)2 in Figure 10), and the packet processing APL1 (see Figure 1) of the server-internal delay control system 1000 only needs to interact with the existing POSIX socket API of the kernel (without modifying the kernel's protocol stack). For this reason, it can be implemented without modifying the APL.

[0153] (4) For similar reasons, it is possible to achieve this without having to create a custom kernel.

[0154] Furthermore, the Guest OS (GuestOS70) running within the virtual machine includes a kernel (Kernel171), a ring buffer (Ring Buffer72) managed by the kernel in the memory space of the server housing the Guest OS, a poll list (poll_list186) that registers network device information indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC11) belongs to, and a protocol processing unit 74 that performs protocol processing on packets that have been harvested. The kernel also includes an in-server delay control device 100 that starts a thread to monitor packet arrivals using a polling model. The in-server delay control device 100 includes a packet arrival monitoring unit 110 that monitors the poll list (polling), a packet harvesting unit 120 that, if a packet has arrived, 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, puts the polling thread to sleep if no packets arrive for a predetermined period of time, and when a packet arrives, this thread (polling The system is characterized by comprising a sleep management unit 130 that wakes the system from sleep mode by a hardware interrupt (hardIRQ) of the thread.

[0155] By doing so, in a virtual server configuration system using VMs, it is possible to reduce power consumption and minimize latency within the server while forwarding packets to servers equipped with Guest OS (GuestOS70) without modifying the APL.

[0156] Furthermore, the Host OS (HostOS90), on which virtual machines and external processes formed outside the virtual machines can run, comprises a kernel (Kernel91), a ring buffer (Ring Buffer22) managed by the kernel in the memory space of the server equipped with the Host OS, a poll list (poll_list186) that registers information about the network device indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC11) belongs to, and a tap device 222 which is a virtual interface created by the kernel (Kernel91). Within the kernel, there is a server-internal delay control device 100 that starts a thread to monitor packet arrivals using a polling model. The server-internal delay control device 100 includes a packet arrival monitoring unit 110 that monitors the poll list (polling), a packet harvesting unit 120 that, if a packet has arrived, refers to the packet held in the ring buffer (Ring Buffer72) and performs harvesting by deleting the corresponding queue entry from the ring buffer (Ring Buffer72) based on the next processing to be performed, and if a packet does not arrive for a predetermined period of time, the thread (polling The system is characterized by comprising a sleep management unit 130 that puts a polling thread into sleep mode and wakes it up when a packet arrives via a hardware interrupt (hardIRQ) of the polling thread.

[0157] By doing so, in a virtual server configuration system using VMs, it is possible to reduce power consumption and minimize latency within the server while performing packet forwarding for servers equipped with a kernel (Kernel171) and a host OS (HostOS90), without modifying the APL.

[0158] The server-internal delay control device 100 is characterized by including 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 threads to a lower value during sleep mode.

[0159] In this way, the server's internal delay control device 100 dynamically changes the CPU operating frequency in accordance with traffic. That is, if the CPU is not used due to sleep mode, the CPU operating frequency during sleep mode is set lower, thereby further enhancing power saving effects.

[0160] The server-internal delay control device 100 is characterized by including 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 so, the server's internal delay control device 100 can further enhance power saving by dynamically changing the CPU idle state (power saving function depending on the CPU model, such as changing the operating voltage) in accordance with traffic.

[0162] The server-internal delay control device 100 is characterized in that the kernel (Kernel 171) has a patch (livepatch) that can change the processing operation while the kernel (Kernel 171) is running.

[0163] By doing so, the server-internal delay control device 100 can change its processing operation while (Kernel 171) is running using livepatch, thus eliminating the need to modify the kernel. Therefore, the server-internal delay control device 100 does not need to be redeveloped every time there is a security update to the kernel, for example; it only needs to change its processing operation when there are changes to related kernel functions.

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

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

[0166] 1. Packet Processing APL (Application Program) 10 HW 11. NIC (Physical NIC) (Interface Section) 70 OS 74 Protocol Processing Unit 60 user space 72 Ring Buffer 90 Host OS (OS) 91,171,181 Kernel 100 Server-internal delay control device (polling thread) 110 Packet Arrival Monitoring Unit 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-based delay control system

Claims

1. A server that performs packet processing, including polling, within the kernel, The aforementioned server, A packet arrival monitoring unit that monitors the arrival of packets, It includes a sleep management unit that puts a dedicated polling thread to sleep, The aforementioned server, The polling-dedicated thread that executes the polling process within the kernel is started, The packet arrival monitoring unit monitors packet arrivals not in the execution context of a software interrupt, but through the dedicated polling thread. The sleep management unit puts the polling thread to sleep depending on whether or not a packet has arrived via the polling thread. A server characterized by the following features.

2. During the aforementioned sleep period, the system includes a CPU frequency setting unit that sets the CPU operating frequency of the CPU core used by the polling-dedicated thread to a lower value. The server according to feature 1.

3. During the aforementioned sleep period, the system includes a CPU idle setting unit that sets the CPU idle state of the CPU core used by the polling-dedicated thread to power-saving mode. The server according to feature 1.

4. A server that performs packet processing, including polling, within the kernel, The aforementioned server, A packet arrival monitoring unit that monitors the arrival of packets, It includes a sleep management unit that puts a dedicated polling thread to sleep, The aforementioned server, The polling-dedicated thread that executes the polling process within the kernel is started, The packet arrival monitoring unit monitors packet arrivals not in the execution context of a software interrupt, but through the dedicated polling thread. The sleep management unit, when the polling-dedicated thread is in a sleep state, wakes up the polling-dedicated thread via a hardware interrupt when the packet arrival monitoring unit confirms the arrival of a packet, thereby waking up the polling-dedicated thread and releasing it from sleep state. A server characterized by the following features.

5. When the sleep state is released, the system includes a CPU frequency setting unit that sets the CPU operating frequency of the CPU core used by the polling-dedicated thread to a higher frequency than the CPU operating frequency in the sleep state. The server according to feature 4.

6. When the sleep state is released, the system includes a CPU idle setting unit that releases the power saving mode set as the CPU idle state for the CPU core used by the polling-dedicated thread. The server according to feature 4.

7. A program for causing a computer to function as a server according to any one of claims 1 to 6.

Images