In-server delay control device, in-server delay control method, and program
By configuring polling threads in the server kernel space, dynamically switching the sleep control mode and continuous busy polling mode according to the frequency of service inflow, the problems of packet transmission delay and power consumption are solved, and the effects of low latency and power saving are achieved.
Patent Information
- Application Number
- CN202280095899.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-12
- Publication Date
- 2024-12-20
AI Technical Summary
The prior art has delay problems in packet transmission, especially in the interrupt model and polling model, the packet transmission delay is large, and the polling model leads to an increase in power consumption.
Using an in-server delay control device, it is configured in the kernel space of the OS. It uses a polling model to monitor the threads arriving in data packets. The thread has a sleep control mode and a continuous busy polling mode, and dynamically switches the working mode according to the frequency of business inflow. Hardware interrupts monitor packet arrivals to reduce latency and power consumption.
It realizes the balance of low latency and power saving when the frequency of service inflow is high. By dynamically switching the working mode, the frequency of sleep and sleep cancellation is reduced, power consumption is reduced, and delay increases are avoided.
Smart Images

Figure CN119173855A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a server internal delay control device, a server internal delay control method and a program. Background Art
[0002] With the development of virtualization technology based on NFV (Network Functions Virtualization), a system is built and operated for each service. In addition, according to the above-mentioned system-based approach, the service function is divided into reusable module units and operated on an independent virtual machine (VM: Virtual Machine, container, etc.) environment. Thus, the method called SFC (Service Function Chaining) is gradually becoming mainstream, which is used as needed like a component and improves operability.
[0003] As a technology for forming a virtual machine, a hypervisor environment composed of Linux (registered trademark) and KVM (kernel-based virtual machine) is known. In this environment, a host operating system (Host OS, the OS installed on a physical server is referred to as the host operating system) embedded with a KVM module operates as a hypervisor in a memory area different from a user space, called a kernel space. In this environment, a virtual machine operates in a user space, and a guest operating system (Guest OS, the OS installed on a virtual machine is referred to as a guest operating system) operates in the virtual machine.
[0004] The virtual machine for the child operating system is different from the physical server for the parent operating system. All the HW (hardware) of the network equipment (such as Ethernet card devices) performs the register control required for interrupt processing from HW to the child operating system and writing from the child operating system to the hardware. In such register control, notifications and processing that should have been performed by physical hardware are simulated in software simulation, so the performance is generally lower than that of the parent operating system environment.
[0005] In the case of such performance degradation, there is a technology that reduces HW imitation and improves communication performance and versatility through a high-speed and unified interface, especially for the child operating system to the parent operating system and external processes existing outside the virtual machine. As such technology, virtio, a device abstraction technology or paravirtualization technology, has been developed and has been embedded in many general-purpose OSs, including Linux and FreeBSD (registered trademark), and is currently being used.
[0006] In virtio, for data input and output such as console, file input and output, and network communication, as a one-way transport for transmitting data, the data exchange performed by queues designed as a ring buffer is defined through queue operations. Then, by using the technical specifications of virtio queues, by preparing the number and size of queues suitable for each device when the guest operating system is started, it is possible to realize communication between the guest operating system and the outside of the virtual machine without performing hardware emulation but only through queue operations.
[0007] [Data packet transmission based on polling model (DPDK example)]
[0008] The method of connecting and cooperating multiple virtual machines is called Inter-VM Communication. In large-scale environments such as data centers, virtual switches have been used as a standard to connect VMs. However, since this method has a large communication delay, a new method with higher speed has been proposed. For example, a method using special hardware called SR-IOV (Single Root I / O Virtualization) and a method based on software using Intel DPDK (Intel Data Plane Development Kit) (hereinafter referred to as DPDK) as a high-speed packet processing library have been proposed.
[0009] DPDK is a framework for controlling NIC (Network Interface Card) in user space, which was previously performed by Linux kernel (registered trademark). The biggest difference from the processing in Linux kernel is that it has a polling-based receiving mechanism called PMD (Pull Mode Driver). Usually, in Linux kernel, an interrupt occurs in response to the arrival of data to NIC, and reception processing is performed based on this. On the other hand, PMD continuously confirms the arrival of data and performs reception processing by a dedicated thread. By eliminating the overhead of context switching, interrupts, etc., high-speed packet processing is possible. DPDK greatly improves the performance and throughput of packet processing, and can ensure more time for data plane / application processing.
[0010] DPDK occupies computer resources such as CPU (Central Processing Unit) and NIC. Therefore, it is difficult to apply it to applications that require flexible switching in modules like SFC. SPP (Soft Patch Panel) is an application used to alleviate this situation. SPP is set up so that each VM can directly refer to the same memory space structure by preparing shared memory between VMs, thereby omitting the copying of data packets in the virtualization layer. In addition, DPDK is used to achieve high speed in the exchange of data packets between the physical NIC and the shared memory. SPP can change the input destination and output destination of the data packet by software by controlling the reference destination of the memory exchange of each VM. Through this process, SPP realizes dynamic connection switching between VMs and between VM and physical NIC.
[0011] [Rx-side packet processing based on New API (NAPI)]
[0012] Fig.18 This is a schematic diagram of Rx-side packet processing based on the New API (NAPI) implemented by Linux kernel 2.5 / 2.6 (see Non-Patent Document 1).
[0013] like Fig.18 As shown, on a server having OS70 (e.g., a parent operating system), a packet processing APL1 configured in a user space 60 available to a user is executed, and a New API (NAPI) performs packet transmission between the NIC11 of the HW10 connected to OS70 and the packet processing APL1.
[0014] The OS 70 includes a kernel 71 , a ring buffer 72 , and a driver 73 . The kernel 71 includes a protocol processing unit 74 .
[0015] The kernel 71 is a core function of the OS 70 (e.g., the mother operating system), and manages the monitoring of the hardware and the execution status of the program in units of processes. Here, the kernel 71 can respond to requests from the packet processing APL1, and can communicate requests from the HW 10 to the packet processing APL1. The kernel 71 processes the request from the packet processing APL1 via a system call ("a user program operating in non-privileged mode" entrusts "a kernel operating in privileged mode" to perform processing).
[0016] The kernel 71 delivers the packet to the packet processing APL1 via the socket 75. The kernel 71 receives the packet from the packet processing APL1 via the socket 75.
[0017] The ring buffer 72 is managed by the kernel 71 and is located in the memory space of the server. The ring buffer 72 is a fixed-size buffer that stores messages output by the kernel 71 as logs, and is overwritten from the beginning when the upper limit size is exceeded.
[0018] The driver 73 is a device driver for monitoring hardware by the kernel 71. It should be noted that the driver 73 depends on the kernel 71, and if the created (built) kernel source code changes, it will become another driver. In this case, the corresponding driver / source code is obtained, and the driver is rebuilt on the OS using the driver to create the driver.
[0019] The protocol processing unit 74 performs protocol processing of L2 (data link layer) / L3 (network layer) / L4 (transport layer) defined by the OSI (Open Systems Interconnection) reference model.
[0020] Socket 75 is an interface for inter-process communication of kernel 71. Socket 75 has a socket buffer, and data copy processing does not occur frequently. The process until communication is established via socket 75 is as follows: 1. The server side creates a socket file for receiving clients. 2. Name the receiving socket file. 3. Create a socket / queue. 4. Accept the first connection from the client that enters the socket / queue. 5. Create a socket file on the client side. 6. Send a connection request from the client side to the server. 7. On the server side, a connection socket file is created separately from the receiving socket file. As a result of establishing communication, the packet processing APL1 can call system calls such as read() and write() to the kernel 71.
[0021] In the above configuration, the kernel 71 receives the notification of packet arrival from the NIC 11 through a hardware interrupt (hardIRQ) and schedules a software interrupt (softIRQ) for packet processing.
[0022] The New API (NAPI) implemented by Linux kernel 2.5 / 2.6 processes data packets through software interrupts (softIRQ) after hardware interrupts (hardIRQ) when data packets arrive. Fig.18 As shown, packet transmission based on the interrupt model is handled by interrupts (refer to Fig.18 The data packet is transmitted by the reference numeral a), so a waiting for interrupt processing occurs, and the delay of the data packet transmission becomes large.
[0023] The following is an overview of packet processing on the NAPI Rx side.
[0024] [Rx-side packet processing structure based on New API (NAPI)]
[0025] Fig.19 Yes Fig.18 A diagram illustrating an overview of Rx-side packet processing based on the New API (NAPI), with the portion enclosed by a dotted line.
[0026] <Device Driver>
[0027] like Fig.19 As shown, the device driver is configured with: NIC11 (physical NIC), which is a network interface card; hardIRQ81, which is a handler that is called by the occurrence of a processing request of NIC11 and executes the requested processing (hardware interrupt); and netif_rx82, which is a processing function unit of a software interrupt.
[0028] <Network Layer>
[0029] The network layer is configured with: softIRQ83, which is called by the occurrence of the processing request of netif_rx82 and performs the processing of the request (software interrupt); and do_softirq84, which is the control function unit of the entity that performs the software interrupt (softIRQ). In addition, it is configured with: net_rx_action85, which is the packet processing function unit executed in response to the software interrupt (softIRQ); poll_list86, which registers the information of the network device (net_device) indicating which device the hardware interrupt from NIC11 is the interrupt of; netif_receive_skb87, which creates the sk_buff structure (a structure used to make the kernel 71 aware of what the packet is); and the ring buffer 72.
[0030] <Protocol Layer>
[0031] The protocol layer is configured with ip_rcv88, arp_rcv89, etc. as packet processing functional units.
[0032] The above-mentioned netif_rx82, do_softirq84, net_rx_action85, netif_receive_skb87, ip_rcv88, and arp_rcv89 are components (names of functions) of a program for packet processing in the kernel 71.
[0033] [Rx-side packet processing actions based on New API (NAPI)]
[0034] Fig.19Arrows (reference numerals) b to m indicate the flow of packet processing on the Rx side.
[0035] When receiving a packet (or frame) in a frame from a counterpart device, the hardware function unit 11a of the NIC 11 (hereinafter referred to as the NIC 11) copies the received packet to the ring buffer 72 by DMA (Direct Memory Access) transfer without using the CPU (see Fig.19 The memory space of the ring buffer 72 in the server is occupied by the kernel 71 (refer to Fig.18 ) for management.
[0036] However, the kernel 71 cannot know the data packet simply by copying the data packet arriving to the ring buffer 72 through the NIC 11. Therefore, when the data packet arrives, the NIC 11 reports the hardware interrupt (hardIRQ) to the hardIRQ 81 (refer to Fig.19 The following processing is performed by netif_rx82, so that the kernel 71 knows the data packet. It should be noted that, Fig.19 The hardIRQ81 enclosed by an oval represents a handler rather than a functional unit.
[0037] netif_rx82 is the function that actually does the processing. When hardIRQ81 (handler) is started (see Fig.19 The reference symbol d) stores the network device (net_device) information indicating which device the hardware interrupt from NIC 11 is interrupting as one of the information of the hardware interrupt (hardIRQ) in poll_list 86. Then, netif_rx 82 registers the extraction of the queue (referring to the content of the data packet retained in the buffer, and considering the processing to be performed next for the processing of the data packet, the corresponding queue entry is deleted from the buffer) (referring to Fig.19 Specifically, in response to the data packet being inserted into the ring buffer 72, netif_rx 82 uses the driver of NIC 11 to register the subsequent cutout of the queue in poll_list 86. Thus, the cutout information based on the queue in which the data packet is inserted into the ring buffer 72 is registered in poll_list 86.
[0038] So, in Fig.19 In the <device driver>, when a data packet is received, the NIC 11 copies the arrived data packet to the ring buffer 72 through DMA transfer. In addition, the NIC 11 starts the hardIRQ 81 (handler), and the netif_rx 82 registers the net_device in the poll_list 86, and schedules the software interrupt (softIRQ).
[0039] So far, Fig.19 The processing of a hardware interrupt in <device driver> stopped.
[0040] After that, netif_rx82 uses the queue entry information (specifically, pointer) accumulated in poll_list86 to report the data stored in the ring buffer 72 to softIRQ83 (handler) via software interrupt (softIRQ) (see Fig.19 f), notifies do_softirq84 (refer to Fig.19 denoted by reference numeral g).
[0041] do_softirq84 is a software interrupt control function unit that defines various functions of software interrupts (there are many types of data packet processing, and interrupt processing is one of them. It defines interrupt processing). Based on this definition, do_softirq84 notifies net_rx_action85, which actually performs software interrupt processing, of the (corresponding) software interrupt delegation (see Fig.19 Reference numeral h).
[0042] When it is the softIRQ's turn, net_rx_action85 is based on the net_device registered in poll_list86 (refer to Fig.19 , calling a polling routine for cutting a data packet from the ring buffer 72, cutting a data packet (refer to Fig.19 At this time, net_rx_action85 continues to harvest until poll_list86 becomes empty.
[0043] After this, net_rx_action85 notifies netif_receive_skb87 (refer to Fig.19 Reference numeral k).
[0044] netif_receive_skb87 creates a sk_buff structure, parses the contents of the data packet, and transfers the processing to the next level protocol processing unit 74 according to the type (see Fig.18 ). That is, netif_receive_skb87 parses the contents of the data packet, and when processing is performed according to the contents of the data packet, it hands over the processing to ip_rcv88 of the <protocol layer> ( Fig.19 If it is L2, the processing is handed over to arp_rcv89 ( Fig.19 denoted by the reference numeral m).
[0045] Patent Document 1 describes a network delay control device (KBP: Kernel Busy Poll) in a server. KBP continuously monitors the arrival of data packets in the kernel through a polling model, thereby suppressing softIRQ and achieving low-delay data packet processing.
[0046] Prior art literature
[0047] Patent Literature
[0048] Patent Document 1: International Publication No. 2021 / 130828
[0049] Non-patent literature
[0050] Non-patent document 1: New API (NAPI), [online], [retrieved on April 4, 2004], Internet 〈URL: http: / / http: / / lwn.net / 2002 / 0321 / a / napi-howto.php3〉 Summary of the invention
[0051] Problems to be solved by the invention
[0052] However, there are the following problems with respect to either of the packet transmission based on the interrupt model and the polling model.
[0053] In the interrupt model, the kernel that receives an event (hardware interrupt) from the HW transmits the data packet through software interrupt processing for processing the data packet. Therefore, the interrupt model has the following problems: Since the data packet is transmitted through interrupt (software interrupt) processing, if there is a conflict with other interrupts or the interrupt target CPU is used by a process with a higher priority, waiting occurs, and the delay of data packet transmission becomes larger. In this case, when the interrupt processing is crowded, the waiting delay becomes larger.
[0054] Supplement the mechanism for delays in the interrupt model.
[0055] In general, the kernel processes packet transmission after hardware interrupt processing and then passes it through software interrupt processing.
[0056] When a software interrupt occurs during packet transmission, the software interrupt cannot be executed immediately under the following conditions (1) to (3). Therefore, the interrupt is scheduled by a scheduler such as ksoftirqd (a kernel thread for each CPU that is executed when the software interrupt load increases), resulting in a wait of the order of ms.
[0057] (1) Conflict with other hardware interrupt processing
[0058] (2) Conflicts with other software interrupt handlers
[0059] (3) When other processes or kernel threads (migration threads, etc.) with higher priority are using the interrupt target CPU
[0060] In the above conditions, the software interrupt processing cannot be executed immediately.
[0061] In addition, the same is true for data packet processing based on New API (NAPI), such as Fig.19 As shown in the dashed box n, due to the conflict of interrupt processing (softIRQ), a NW delay of the order of ms occurs.
[0062] On the other hand, if the technology described in Patent Document 1 is used, software interrupts can be suppressed by continuously monitoring the arrival of data packets, thereby achieving low-latency data packet capture. However, in order to monitor the arrival of data packets, the CPU core is occupied and CPU time is used, so power consumption increases. That is, since the kernel thread that continuously monitors the arrival of data packets occupies the CPU core and always uses CPU time, there is a problem of increased power consumption. Fig. 20 and Fig.21 , explaining the relationship between workload and CPU usage.
[0063] Fig. 20 This is an example of video (30FPS) data transmission. Fig. 20 The workload shown is a data transfer rate of 350 Mbps with intermittent data transfer every 30 ms.
[0064] Fig.21 This is a diagram showing the CPU usage rate used by the busy polling thread in the KBP described in Patent Document 1.
[0065] like Fig.21 As shown, in KBP, kernel threads perform busy polling and thus occupy the CPU core. Fig. 20 The intermittent packet reception shown in the figure always uses the CPU in KBP regardless of whether a packet arrives or not, so there is a problem of increased power consumption.
[0066] The present invention has been made in view of such a background, and an object of the present invention is to suppress the sleep and sleep release actions when the traffic inflow frequency is "dense", thereby achieving low latency and power saving.
[0067] Solutions for solving problems
[0068] In order to solve the above-mentioned problem, a delay control device in a server is adopted, which is configured in the kernel space of the OS and starts a thread which monitors the arrival of data packets using a polling model. The delay control device in the server is characterized in that the working modes of the thread include: a sleep control mode which can put the thread to sleep; and a continuous busy polling mode which causes the thread to perform continuous busy polling. The delay control device in the server comprises: a service frequency measuring unit which measures the service inflow frequency; a mode switching control unit which switches the working mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the service inflow frequency measured by the service frequency measuring unit; and a data packet arrival monitoring unit which, in the case of the continuous busy polling mode, monitors a polling list which registers information of a network device which indicates which device the hardware interrupt from the interface unit is from, and confirms whether a data packet has arrived.
[0069] Effects of the Invention
[0070] According to the present invention, it is possible to suppress sleep and sleep release operations when the traffic inflow frequency is "dense", thereby achieving low latency and power saving. BRIEF DESCRIPTION OF THE DRAWINGS
[0071] Figure 1 This is a schematic diagram of the structure of a delay control system within a server according to an embodiment of the present invention.
[0072] Figure 2 It is configured in kernel space Figure 1 An example of the structure of a polling thread (delay control device within the server).
[0073] Figure 3 It is configured in user space Figure 1 An example of the structure of a polling thread (delay control device within the server).
[0074] Figure 4 Yes Figure 1 A diagram illustrating the configuration of the business frequency measuring unit of the polling thread (delay control device within the server).
[0075] Figure 5 This is a diagram showing an example of the polling thread operation when the traffic inflow frequency of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention is “sparse”.
[0076] Figure 6 This is an example of data transmission when the traffic inflow frequency of the server delay control system according to the embodiment of the present invention is "high".
[0077] Figure 7 Yes means Figure 6FIG. 1 is a diagram of an example of polling thread operation in a data transmission example when the traffic inflow frequency is “dense”.
[0078] Figure 8 This is a diagram for explaining the operation mode switching point of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
[0079] Fig. 9 This is a diagram showing an example of the switching determination logic of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention in the form of a table.
[0080] Fig.10 This is a flowchart showing NIC and HW interrupt processing of an intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
[0081] Fig.11 This is a flowchart showing the operation mode switching process of the mode switching control unit of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
[0082] Fig.12 This is a flowchart showing the operation mode switching process of the polling thread of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
[0083] Fig.13 This is a hardware configuration diagram showing an example of a computer that realizes the function of an intra-server delay control device of an intra-server delay control system according to an embodiment of the present invention.
[0084] Fig.14 This diagram shows an example of applying a server internal delay control system in which a polling thread is arranged in the kernel to an interrupt model in a server virtualization environment composed of a general-purpose Linux kernel (registered trademark) and VMs.
[0085] Fig.15 This is a diagram showing an example of applying a server internal delay control system in which a polling thread is arranged in a kernel to an interrupt model in a server virtualization environment composed of containers.
[0086] Fig.16 This diagram shows an example of applying a server internal delay control system in which a polling thread is arranged in a user space to an interrupt model in a server virtualization environment composed of a general-purpose Linux kernel (registered trademark) and VMs.
[0087] Fig.17 This is a diagram showing an example of applying a server internal delay control system in which a polling thread is configured in a user space to an interrupt model in a server virtualization environment composed of containers.
[0088] Fig.18 This is a schematic diagram of the Rx-side packet processing based on the New API (NAPI) implemented by Linux kernel 2.5 / 2.6.
[0089] Fig.19 Yes Fig.18 A diagram illustrating an overview of Rx-side packet processing based on the New API (NAPI), with the portion enclosed by a dotted line.
[0090] Fig. 20 This is a diagram showing an example of data transmission of video (30FPS).
[0091] Fig.21 This is a diagram showing the CPU usage rate used by the busy polling thread in the KBP described in Patent Document 1. DETAILED DESCRIPTION
[0092] Hereinafter, a server internal delay control system and the like in a mode for implementing the present invention (hereinafter referred to as “the present embodiment”) will be described with reference to the drawings.
[0093] [summary]
[0094] Figure 1 This is a schematic diagram of a server delay control system according to an embodiment of the present invention. This embodiment is an example of Rx-side packet processing based on New API (NAPI) implemented by Linux kernel 2.5 / 2.6. Fig.18 The same components are denoted by the same reference numerals.
[0095] like Figure 1 As shown, the server delay control system 1000 executes a packet processing APL1 configured in a user space available to users on a server having an OS (eg, a parent operating system), and performs packet transmission between a NIC 11 of HW connected to the OS and the packet processing APL1.
[0096] The server-internal delay control system 1000 comprises: NIC11 (physical NIC), which is a network interface card; hardIRQ81, which is a handler that is called when a processing request is generated by NIC11 and executes the requested processing (hardware interrupt); HW interrupt processing unit 182, which is a processing function unit of HW interrupt; receiving list 186; ring buffer 72; polling thread (server-internal delay control device 100); and protocol processing unit 74.
[0097] The ring buffer 72 is managed by the kernel in the memory space of the server. The ring buffer 72 is a fixed-size buffer that stores messages output by the kernel as logs, and is overwritten from the beginning when the upper limit size is exceeded.
[0098] The protocol processing unit 74 is Ethernet, IP, TCP / UDP, etc. The protocol processing unit 74 performs, for example, L2 / L3 / L4 protocol processing defined by the OSI reference model.
[0099] <Delay control device within the server>
[0100] The server internal delay control device 100 is a polling thread arranged in either the kernel space or the user space.
[0101] The server delay control device 100 includes a packet arrival monitoring unit 110, a packet extraction unit 120, a sleep management unit 130, a CPU frequency / CPU idle setting unit 140, a mode switching control unit 150, and a service frequency measurement unit 160. Figure 1 In the embodiment, the packet arrival monitoring unit 110 includes a traffic frequency measuring unit 160 .
[0102] The packet arrival monitoring unit 110 is a thread for monitoring whether a packet has arrived. The packet arrival monitoring unit 110 monitors (polls) the reception list 186 .
[0103] The packet arrival monitoring unit 110 obtains the pointer information and net_device information of the packet existing in the ring buffer 72 from the reception list 186, and passes the information (pointer information and net_device information) to the packet cutting unit 120. Here, when there are multiple packet information in the reception list 186, the information of multiple packets is passed.
[0104] When a packet arrives, the packet extraction unit 120 refers to the packet stored in the ring buffer 72 and performs extraction (hereinafter, sometimes simply referred to as extracting a packet from the ring buffer 72) to delete the entry of the corresponding queue from the ring buffer 72 based on the next processing to be performed. The packet extraction unit 120 takes out the packet from the ring buffer 72 based on the received information and passes the packet to the protocol processing unit 74.
[0105] When a plurality of data packets are accumulated in the ring buffer 72, the packet cutting unit 120 cuts the plurality of data packets collectively and transmits them to the subsequent protocol processing unit 74. It should be noted that the number of packets cut collectively is called a quota, which is also often referred to as batch processing. As for the protocol processing unit 74, since the protocol processing also processes a plurality of data packets collectively, it is high-speed.
[0106] The sleep management unit 130 puts a thread (polling thread) to sleep if a data packet does not arrive within a predetermined period of time, and releases the thread (polling thread) from sleep by a hardware interrupt (hardIRQ) when a data packet arrives (details will be described later).
[0107] 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 lower level during sleep. The CPU frequency / CPU idle setting unit 140 sets the CPU idle state of the CPU core used by the thread (polling thread) to a power saving mode during sleep (details will be described later).
[0108] The mode switching control unit 150 switches the working mode of the polling thread to one of the sleep control mode and the continuous busy polling mode based on the service inflow frequency measured by the service frequency measuring unit 160. For example, the mode switching control unit 150 performs mode switching control based on the service inflow frequency information measured by the service frequency measuring unit 160, and switches the working mode of the polling thread to the "sleep control mode (a mode that allows the polling thread to sleep)" when the service inflow frequency (data packet inflow frequency) is low, and switches the working mode of the polling thread to the "continuous busy polling mode (a mode that allows the polling thread to perform continuous busy polling)" when the service inflow frequency is high.
[0109] Here, the working mode of the polling thread is one of the "sleep control mode" and the "continuous busy polling mode". If it is not the "sleep control mode", it is switched to the "continuous busy polling mode". In addition, if it is not the "continuous busy polling mode", it is switched to the "sleep control mode".
[0110] In addition, the above-mentioned “low business inflow frequency” means that if the business inflow frequency is “sparse” ( Fig. 20 ), the packet inflow frequency is less than the threshold T( Figure 8 ), the above-mentioned “high business inflow frequency” means that if the business inflow frequency is “dense” ( Figure 6 ), the traffic inflow frequency is the threshold value T( Figure 8 )The above situation (described later).
[0111] The traffic frequency measuring unit 160 measures the traffic inflow frequency and transmits the traffic inflow frequency to the mode switching control unit 150. The traffic frequency measuring unit 160 may measure the traffic frequency by approximating the traffic frequency using the number of HW interruptions (recorded as statistical information in the kernel) or the like.
[0112] <Configuration of the delay control device in the server>
[0113] Figure 2 and Figure 3 Yes Figure 1 A diagram illustrating the configuration of the polling thread (delay control device 100 within the server).
[0114] Kernel space configuration of polling threads
[0115] Figure 2 It is configured in kernel space Figure 1 An example of the configuration of a polling thread (delay control device 100 within the server).
[0116] At once Figure 2 As for the server delay control system 1000 shown, a polling thread (server delay control device 100) and a protocol processing unit 74 are configured in the kernel space. The polling thread (server delay control device 100) operates in the kernel space. The server delay control system 1000 executes the packet processing APL1 configured in the user space on a server equipped with an OS, and performs packet transmission between the NIC 11 of the HW and the packet processing APL1 via a device driver connected to the OS.
[0117] It should be noted that if Figure 2 As shown, the device driver is configured with: hardIRQ 81, HW interrupt processing unit 182, reception list 186, and ring buffer 72.
[0118] A device driver is a driver for monitoring hardware.
[0119] In the method of configuring the polling thread in the kernel, the mode switching control unit 150 of the server delay control device 100 wakes up the thread periodically when it is in sleep mode or wakes up the thread just before the arrival of the data packet according to the data packet arrival timing. The mode switching control unit 150 manages HW interrupts, controls the sleep of the polling thread and the enable / disable of HW interrupts for hardIRQ81 (refer to Figure 2 xx).
[0120] The present invention can be applied to a situation where a polling thread exists inside a kernel, such as NAPI and KBP.
[0121] Userspace configuration of polling threads
[0122] Figure 3 It is configured in user space Figure 1 An example of the configuration of a polling thread (delay control device 100 within the server).
[0123] At once Figure 3In the illustrated server delay control system 1000, a polling thread (server delay control device 100) and a protocol processing unit 74 are arranged in the user space. The polling thread (server delay control device 100) operates in the user space, not in the kernel space.
[0124] At once Figure 3 In the server delay control system 1000 shown, the polling thread (server delay control device 100) bypasses the kernel space and performs packet transmission between the device driver and the NIC 11 and the packet processing APL 1.
[0125] In the method of configuring the polling thread in the user space, the mode switching control unit 150 of the server delay control device 100 wakes up the thread periodically when it is in sleep mode or wakes up the thread just before the arrival of the data packet according to the data packet arrival timing. The mode switching control unit 150 manages HW interrupts and controls the sleep mode of the polling thread and the enable / disable of HW interrupts for the HW interrupt processing unit 182 (see Figure 3 yy).
[0126] The present invention can be applied to a situation where a polling thread exists in the user space, such as DPDK.
[0127] <Configuration of the Traffic Frequency Measurement Unit 160>
[0128] Figure 4 Yes Figure 1 FIG. 2 is a diagram for explaining the configuration of the business frequency measuring unit 160 of the polling thread (delay control device 100 within the server).
[0129] like Figure 4 As shown, the service frequency measuring unit 160 of the server delay control device 100 may be configured as a thread independent of the packet arrival monitoring unit 110 to measure the service frequency. In this case, the service frequency measuring unit 160 cannot directly measure the service frequency, but can measure the service frequency by approximating the service frequency using the number of HW interrupts (recorded in the kernel as statistical information) or the like.
[0130] The following describes the operation of the server delay control system 1000 configured as described above.
[0131] The present invention can be applied to any of the cases where there is a polling thread inside the kernel, such as NAPI and KBP, or where there is a polling thread in the user space, such as DPDK. The application of the case where there is a polling thread inside the kernel is used as an example for explanation.
[0132] [Rx-side data packet processing action based on the present invention]
[0133] Figure 1 to Figure 4 Arrows (reference numerals) aa to ii indicate the flow of data packet processing on the Rx side.
[0134] When receiving a packet (or frame) in a frame from a counterpart device, the NIC 11 copies the received packet to the ring buffer 72 by DMA transfer without using the CPU (see Figure 1 to Figure 4 The ring buffer 72 is managed by the <device driver>.
[0135] When a packet arrives, NIC11 initiates a hardware interrupt (hardIRQ) to hardIRQ81 (handler) (see Figure 1 to Figure 4 The data packet is known by executing the following processing through the HW interrupt processing unit 182.
[0136] When hardwire81 (processor) starts (refer to Figure 1 The HW interrupt processing unit 182 stores information of a network device (net_device) indicating which device the hardware interrupt from the NIC 11 is interrupting as one of the information of the content of the hardware interrupt (hardIRQ) in the receiving list 186, and registers the cutout information of the queue. Specifically, in response to the data packet being inserted into the ring buffer 72, the HW interrupt processing unit 182 registers the cutout of the queue in the receiving list 186 (see Figure 1 to Figure 4 As a result, the cutout based on the queue in which the data packets are jammed in the ring buffer 72 is registered in the reception list 186.
[0137] The HW interrupt processing unit 182 registers net_device in the receiving list 186, but Fig.19 Unlike netif_rx82, HW interrupt processing unit 182 does not schedule software interrupts (softIRQs). Fig.19 The netif_rx82 is different.
[0138] In addition, the HW interrupt processing unit 182 performs sleep release to wake up the sleeping polling thread (see Figure 1 to Figure 4 Figure ee).
[0139] So far, Figure 1 to Figure 4 The processing of a hardware interrupt in <device driver> stopped.
[0140] In this embodiment, Fig.19 In the <Network Layer> shown, softIRQ83 and do_softirq84 are deleted, and along with this, Fig.19 The netif_rx82 shown does not notify the start of softIRQ83 (handler) (see Fig.19 Reference numeral f).
[0141] In this embodiment, the server internal delay control system 1000 deletes Fig.19 Instead of the softIRQ83 and do_softirq84 shown in the figure, a polling thread (delay control device 100 in the server) is set in the <kernel space> (refer to Figure 2 Alternatively, the server delay control system 1000 sets a polling thread (server delay control device 100) in the <user space> (refer to Figure 3 ).
[0142] The packet arrival monitoring unit 110 monitors (polling) (refer to Figure 1 to Figure 4 ff) receiving list 186 to confirm whether the data packet has arrived.
[0143] The packet arrival monitoring unit 110 obtains the pointer information and net_device information of the packet existing in the ring buffer 72 from the reception list 186, and transmits the information (pointer information and net_device information) to the packet cutting unit 120 (refer to Figure 1 to Figure 4 Here, if there are a plurality of data packet information in the receiving list 186, the information of the plurality of data packets is transmitted.
[0144] When a packet has arrived, the packet extraction unit 120 of the server internal delay control device 100 extracts the packet from the ring buffer 72 (see Figure 1 to Figure 4 Figure 1 shows the reference numeral hh).
[0145] The packet extraction unit 120 extracts the packet from the ring buffer 72 based on the received information and transfers the packet to the protocol processing unit 74 (see Figure 1 to Figure 4 ii).
[0146] [Sleep action of polling thread]
[0147] The server delay control system 1000 stops the softIRQ of the packet processing which is the main cause of the NW delay, and executes the polling thread of the packet arrival monitoring unit 110 of the server delay control device 100 to monitor the packet arrival. Then, the packet extraction unit 120 performs the packet processing by the polling model (without softIRQ) when the packet arrives.
[0148] When a packet arrives, the polling thread is called up by the hard interrupt handler, which can avoid softIRQ conflicts and enable packet transmission processing to be performed immediately. In other words, the packet arrival monitoring function is put on standby in advance and called up by a hard interrupt, thereby achieving lower latency than packet transmission processing by soft interrupts such as NAPI.
[0149] The polling thread (server delay control device 100) that monitors the arrival of data packets is set to be sleep-enabled during a period when no data packets arrive.
[0150] The polling thread (delay control device 100 in the server) sleeps according to whether a data packet arrives, and wakes up from sleep through hardIRQ81 when a data packet arrives. Specifically, the sleep management unit 130 of the delay control device 100 in the server sleeps according to whether a data packet arrives, that is, if no data packet arrives within a specified period of time. The sleep management unit 130 wakes up from sleep through hardIRQ81 when a data packet arrives. In this way, softIRQ conflicts are avoided and low latency is achieved.
[0151] The CPU frequency / CPU idle setting unit 140 of the server internal delay control device 100 changes the CPU operating frequency and idle setting according to whether the data packet arrives. Specifically, the CPU frequency / CPU idle setting unit 140 lowers the CPU frequency when in sleep mode, and increases the CPU frequency when restarting (restoring the CPU operating frequency to the original value). In addition, the CPU frequency / CPU idle setting unit 140 changes the CPU idle setting to power saving when in sleep mode. By changing the CPU operating frequency to a lower value during sleep mode, and changing the CPU idle setting to power saving mode, power saving is also achieved.
[0152] [Business inflow frequency and polling thread operation example]
[0153] <When the business inflow frequency is "sparse">
[0154] First, the case where the business inflow frequency is "sparse" is described.
[0155] Figure 5 This is a diagram showing an example of the polling thread operation when the service inflow frequency of the server delay control device 100 is "sparse". The vertical axis represents the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis represents time. It should be noted that Figure 5 Shown with Fig. 20 The data transmission example of the video (30FPS) of intermittently receiving data packets corresponds to the polling thread operation example based on the arrival of data packets.
[0156] Figure 5 Yes Fig. 20The data transmission example of the video (30FPS) is an example of a case where the business inflow frequency is "sparse". It should be noted that the example of a case where the business inflow frequency is "dense" is in Figure 6 To be described later.
[0157] like Figure 5 As shown, the sleep management unit 130 of the server delay control device 100 puts the polling thread to sleep (see Figure 5 Then, the sleep management unit 130 starts the polling thread through the hardIRQ 81 at which the data packet arrives (see Figure 5 Reference symbol q: wake up).
[0158] It should be noted that during sleep, since the kernel thread does not occupy the CPU core, in addition to the use of the polling thread, the interrupt of the timer used for system stability operation enters the corresponding CPU core, or the migration thread for error handling enters the corresponding CPU core, so the CPU usage of the CPU core used by the polling thread may fluctuate (see Figure 5 denoted by the reference numeral r).
[0159] like Figure 5 As shown in the polling thread action example, putting the polling thread to sleep can fully achieve the power saving effect when the business inflow is small.
[0160] <When the business inflow frequency is "high">
[0161] Next, a case where the business inflow frequency is "high" is described.
[0162] Figure 6 This is an example of data transmission when the business inflow frequency is "high". Figure 6 The workload shown is similar to Fig. 20 By comparison, it can be seen that the frequency of business inflow is high, that is, the frequency of business inflow on the time axis is "dense".
[0163] For example, it corresponds to the case where data arrives with a short symbol interval in the time direction (for example, intervals of 8.92us, 4.46us) as in parameter set = 3 or 4 in a vRAN (virtual Radio Access Network) vDU (virtual Distributed Unit) system.
[0164] Figure 7 Yes means Figure 6This is a diagram showing an example of polling thread operation in a data transmission example when the traffic inflow frequency is "dense". The vertical axis represents the CPU usage [%] of the CPU core used by the polling thread, and the horizontal axis represents time. Figure 5 The same polling thread actions are given the same reference numerals.
[0165] exist Figure 6 If the business inflow volume is large, that is, the business inflow frequency is "dense", Figure 7 As shown, the time for sleeping is shortened, and sleeping and waking are repeated at a high frequency (refer to Figure 7 Reference symbols r: sleep / q: wake up).
[0166] When the business inflow frequency is "dense", the CPU usage cannot be reduced because sleep and wake-up are repeated frequently. Therefore, the increase in power consumption of the CPU cycle caused by the interruption overhead during wake-up is greater than the reduction in power consumption of the CPU cycle obtained by sleeping, and as a result, power consumption may sometimes increase due to sleep.
[0167] Thus, when the business inflow frequency is "sparse" (refer to Figure 5 ), the power saving effect can be fully achieved, but when the business inflow frequency is "dense", sometimes the polling thread is not put to sleep, and simply continuous busy polling can reduce power consumption.
[0168] <Comparison of power consumption between "Sleep Control Mode" and "Continuous Busy Polling Mode">
[0169] Next, the reason why simple busy polling consumes less power than repeating sleep / wake-up is described.
[0170] In the "sleep control mode" in which sleep / wake-up is performed, when a data packet is received during sleep, the following processing occurs, and a CPU cycle is required for calculation of the processing.
[0171] Hardware interrupt trigger
[0172] Hardware interrupt handler processing (registering to the reception list, waking up the sleeping thread)
[0173] When the polling thread is configured in the user space, a context switch is performed from the kernel privileged mode for hardware interrupt processing to the general mode for the wakeup processing of the polling thread.
[0174] When comparing the amount of computation (workload) in these "sleep control modes" with the amount of computation (workload) in the "continuous busy polling mode" that simply performs busy polling, when the frequency of business inflow is "dense", the amount of computation in the "sleep control mode" is greater than that in the "continuous busy polling mode". In this way, when the frequency of business inflow is "dense", sometimes it is possible to reduce power consumption by simply performing continuous busy polling instead of putting the polling thread to sleep.
[0175] <Mode Switching Summary>
[0176] When the service inflow frequency is "sparse", since the power saving effect of putting the polling thread to sleep can be expected, sleep control is performed. On the other hand, when the service inflow frequency is "dense", if the polling thread is put to sleep, sleep / wake-up is repeated at a high frequency. In this case, the interruption overhead is greater than the power saving effect of sleep, and power consumption sometimes deteriorates due to sleep control. Therefore, when the service inflow frequency is "dense", it is set to "continuous busy polling mode" (not set to "sleep control mode").
[0177] When the business inflow frequency is "sparse", the polling thread is put into sleep control.
[0178] When the service inflow frequency is "high", the polling thread performs continuous busy polling. When the service inflow frequency is "high", always performing busy polling can reduce the number of CPU cycles more than high-frequency repeated sleep / wake-up.
[0179] In this way, these receiving modes are switched according to the frequency of business inflow, thereby achieving a balance between power saving and low latency.
[0180] [Summary of the Invention]
[0181] Low latency
[0182] The polling thread (delay control device 100 in the server) includes a packet arrival monitoring unit 110 and a packet cutting unit 120, and performs packet arrival monitoring and reception processing through a polling model, thereby realizing low-latency packet reception processing. Specifically, the polling thread (delay control device 100 in the server) performs packet arrival monitoring and reception processing through a low-latency polling model (refer to Figure 1 to Figure 4 ff). Therefore, no softIRQ conflict occurs, which has the effect of reducing delay. In addition, when a data packet arrives during sleep, the polling thread is called up by the hardIRQ with high priority, so the overhead caused by sleep can be suppressed as much as possible.
[0183] (2) Power saving (Part 1)
[0184] The polling thread (internal server delay control device 100 ) includes a sleep management unit 130 . The sleep management unit 130 puts the polling thread to sleep during a period when no data packets arrive, thereby preventing wasteful power consumption due to useless busy polling of the polling thread.
[0185] In addition, the polling thread (server internal delay control device 100) includes a CPU frequency / CPU idle setting unit 140, and the CPU frequency / CPU idle setting unit 140 performs dynamic control of the CPU operating frequency. The dynamic control of the CPU operating frequency is used together with the sleep control.
[0186] In this way, when no power saving packets arrive, the polling thread sleeps and the CPU frequency is controlled to be set low, thereby suppressing an increase in power consumption caused by busy polling.
[0187] (3) Power saving (Part 2)
[0188] The polling thread (delay control device 100 within the server) includes a mode switching control unit 150 and a service frequency measuring unit 160. The mode switching control unit 150 measures the service inflow frequency and transmits the service inflow frequency to the mode switching control unit 150. The mode switching control unit 150 switches the working mode of the polling thread to one of the "continuous busy polling mode" and the "sleep control mode" according to the service inflow frequency. Specifically, the mode switching control unit 150 switches the working mode of the polling thread to the "sleep control mode" when the service inflow frequency is "sparse", and switches the working mode of the polling thread to the "continuous busy polling mode" when the service inflow frequency is "dense".
[0189] [Features of switching control between "sleep control mode" and "continuous busy polling mode"]
[0190] Next, the advantages of dividing the modes instead of controlling the sleep time etc. will be described.
[0191] The modes are divided into a "sleep control mode" for sleeping / waking up and a "continuous busy polling mode" for simple busy polling. As a result, it is not necessary to install sleep control logic that is not required for simple busy polling in the simple busy polling mode. Therefore, it is possible to omit the calculation of redundant control logic, reduce redundant calculations, and potentially reduce power consumption. On the contrary, in the case where the operating modes are not divided, even in the mode of simple busy polling, judgment logic such as the sleep control time is installed, which requires the calculation cost.
[0192] Furthermore, since it is easy to create an independent program for each mode, it is easy to introduce personalized control for each mode.
[0193] [Working mode switching point]
[0194] Figure 8 This is a diagram for explaining the switching point of the operation mode. The vertical axis represents the power consumption caused by the polling thread, and the horizontal axis represents the packet inflow frequency (traffic inflow frequency).
[0195] like Figure 8 As shown, when the polling thread is always busy polling, the power consumption caused by the polling thread is fixed. When sleep control is performed, as the frequency of packet inflow increases, the power consumption caused by the polling thread also increases. When the packet inflow frequency is at a certain threshold T, the power consumption caused by the polling thread is equal. When the packet inflow frequency exceeds the threshold T, if sleep control is performed, the power consumption caused by the polling thread increases instead. From the perspective of power consumption caused by the polling thread, the area from the low packet inflow frequency to the threshold T is the "area where sleep control mode should be used" (refer to Figure 8 The reference symbol jj), the threshold value T is above the "area where the continuous busy polling mode should be used" (refer to Figure 8 Figure 1 shows the reference numeral kk).
[0196] That is, when the packet inflow frequency reaches the threshold value T, even if sleep control is performed, the sleep time is short and the interruption overhead is larger, so the power consumption is higher than that of continuous busy polling (refer to Figure 8 Therefore, the threshold T is the working mode switching point between the "sleep control mode" and the "continuous busy polling mode".
[0197] However, the power saving effect and interruption overhead of the polling thread sleep vary depending on the server specifications used. That is, the threshold T mentioned above varies depending on the server model used. On the other hand, since it is not closely related to the size of the incoming data packet, it is possible to use a server that the operator has used in the service in advance and measure the threshold T in advance through experiments.
[0198] [Switch judgment logic example]
[0199] Fig. 9 This is a diagram showing an example of switching judgment logic in a table.
[0200] like Fig. 9 As shown, the switching decision logic is composed of categories and a logic outline for each category.
[0201] 1. Simple threshold determination
[0202] The method of measuring the business inflow in advance and switching the working mode when the business inflow frequency per unit time exceeds the threshold T
[0203] 2. Judgment based on time period and threshold
[0204] Since people are very active during the daytime, the business volume tends to increase compared to the nighttime. Considering the characteristics of this business volume, the following work mode switching considering time periods is carried out.
[0205] Daytime: When the business inflow frequency is higher than the threshold T, it transfers to the continuous busy polling mode. In this case, even if it is temporarily lower than the threshold T, it will not transfer to the sleep control mode, thereby preventing the oscillation of frequent switching of the work mode at the threshold T.
[0206] Nighttime: When the business frequency is lower than the threshold T, it transfers to the sleep control mode. In this case, even if it is temporarily higher than the threshold T, it will not transfer to the continuous busy polling mode, thereby preventing the oscillation of frequent switching of the work mode at the threshold T.
[0207] 3. Determination Based on Planning-Type Activity Information, Location Information, and Threshold
[0208] According to activities such as fireworks festivals and the business hours of stores, etc., sometimes the number of people in the area changes and the business volume has characteristics. By pre-obtaining such planning-type activity information and location information, and based on the business volume predicted for each time period by this activity, the same control as in 2. above is carried out, thereby enabling highly effective switching of the work mode.
[0209] 4. Determination Based on Business Prediction by Machine Learning
[0210] By pre-learning the trend of business volume through machine learning, and predicting the future business frequency through inference based on the incoming business mode, switch to a suitable work mode.
[0211] [Flowchart]
[0212] <NIC and HW Interrupt Handling>
[0213] Fig.10 It is a flowchart showing the NIC and HW interrupt handling of the polling thread (server internal delay control device 100).
[0214] During the period when the polling thread is started, this action process is executed in a loop.
[0215] When a data packet arrives at NIC11, this process starts. In step S1, NIC11 copies the data of the arrived data packet to the memory area through DMA (Direct Memory Access).
[0216] In step S2, the polling thread (delay control device 100 in the server) determines whether HW interruption is allowed. If HW interruption is allowed (S2: Yes), the process proceeds to step S3, and if HW interruption is not allowed (S2: No), the process of this flow ends.
[0217] In step S3 , the NIC 11 activates the HW interrupt (hardIRQ) to the hardIRQ 81 (handler) to start the HW interrupt, and registers the packet arrival information (NIC device information, etc.) in the reception list 186 .
[0218] In step S4, when the polling thread (delay control device 100 in the server) is sleeping, the NIC 11 activates the polling thread and ends the processing of this flow.
[0219] [Operation Flow of Polling Thread (Delay Control Device 100 in Server)]
[0220] <Working mode switching process>
[0221] Fig.11 1 is a flowchart showing the operation mode switching process of the mode switching control unit 150 of the polling thread (the delay control device 100 within the server).
[0222] In step S11 , the mode switching control unit 150 receives traffic inflow frequency information from the traffic frequency measuring unit 160 .
[0223] In step S12, the mode switching control unit 150 performs the following operations based on the received traffic inflow frequency information: Fig. 9 The switching judgment logic described in the , judges which of the "sleep control mode" and the "continuous busy polling mode" is more suitable. When the current working mode is different from the working mode after judgment, the mode switching control unit 150 indicates the working mode after judgment to each unit (packet arrival monitoring unit 110, packet cutting unit 120, sleep management unit 130, and CPU frequency / CPU idle setting unit 140). When the current working mode is the same as the working mode after judgment, the working mode is not indicated to each unit. Thus, the current working mode continues.
[0224] <Poll thread action flow>
[0225] Fig.12 1 is a flowchart showing the operation mode switching process of the polling thread (internal server delay control device 100).
[0226] When a data packet arrives while the polling thread is sleeping, the process starts due to a HW interrupt.
[0227] In step S21, the mode switching control unit 150 prohibits the HW interruption by the NIC 11. If the HW interruption occurs during the process, the process is interrupted, so the mode switching control unit 150 temporarily prohibits the HW interruption by the NIC 11.
[0228] In step S22 , the CPU frequency / CPU idle setting unit 140 sets the CPU frequency of the CPU core in which the polling thread operates to a higher level, and releases the idle state if the corresponding CPU has been set to the idle state.
[0229] In step S23, the polling thread refers to the reception list 186. The polling thread learns from which device the HW interrupt has occurred, and confirms the packet arrival information in the reception list 186 in the next step S24.
[0230] It should be noted that the arrival of a data packet may be confirmed by directly referring to the ring buffer 72 instead of referring to the control plane list of the reception list 186. For example, in NAPI implemented in the Linux kernel, the control plane list of poll_list is monitored.
[0231] In step S24, the packet arrival monitoring unit 110 determines whether there is packet arrival information in the reception list 186. If there is packet arrival information in the reception list 186 (S24: Yes), the process proceeds to step S25. If there is no packet arrival information in the reception list 186 (S24: No), that is, if there is no packet to be processed, the following process is skipped and the process proceeds to step S30.
[0232] In step S25, the polling thread refers to the packet data from the ring buffer 72, and transmits the corresponding data to the subsequent protocol processing unit 74. Here, when there are a plurality of data, the receiving process may be performed all at once.
[0233] In step S26 , the traffic frequency measuring unit 160 measures the traffic inflow frequency and transmits the traffic inflow frequency to the mode switching control unit 150 .
[0234] The service frequency measuring unit 160 can also measure the service frequency by analogy with the service frequency through the number of HW interruptions (recorded in the kernel as statistical information). Fig. 9 In the case of light processing such as the simple threshold determination described in , the determination may not be handed over to the mode switching control unit 150, but the operating mode may be determined by the business frequency measuring unit 160 (in this case, the business frequency measuring unit 160 also has the function of the mode switching control unit 150).
[0235] In step S27, the sleep management unit 130 causes the polling thread to sleep for a short time in a manner suitable for the traffic inflow frequency. For example, if the traffic inflow frequency is 5us, the polling thread is caused to sleep for about 3us.
[0236] In step S28, the packet arrival monitoring unit 110 determines whether the operation mode instructed by the mode switching control unit is the "sleep control mode." If the operation mode instructed by the mode switching control unit is not the "sleep control mode" (S28: No), the process returns to step S25.
[0237] When the operation mode instructed by the mode switching control unit is the "sleep control mode" (S28: Yes), in step S29, the packet cutting unit 120 determines whether there are unreceived packets in the ring buffer 72. When there are unreceived packets in the ring buffer 72 (S29: Yes), the process returns to the above step S25.
[0238] Here, the loop from step S25 to step S28 is a continuous busy polling loop (refer to Fig.12 The dotted box (mm) (the loop other than this is the loop of the sleep control mode).
[0239] When there are no unreceived data packets in the ring buffer 72 ( S29 : No), in step S30 , the CPU frequency / CPU idle setting unit 140 sets the CPU frequency of the CPU core in which the polling thread operates to a lower level and puts the corresponding CPU into an idle state.
[0240] In step S31 , the packet arrival monitoring section 110 deletes the corresponding NIC information from the reception list 186 .
[0241] In step S32 , the packet arrival monitoring section 110 permits the HW interruption by the corresponding NIC.
[0242] In step S33 , the sleep management unit 130 puts the polling thread to sleep and ends the processing of this flow.
[0243] [Hardware Configuration]
[0244] The server delay control device 100 of the above embodiment is implemented by, for example, Fig.13 The illustrated configuration is implemented by a computer 900 .
[0245] Fig.13 1 is a diagram showing a hardware configuration of an example of a computer 900 that realizes the function of the delay control device 100 within the server.
[0246] The computer 900 includes 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 .
[0247] CPU 901 operates based on the program stored in ROM 902 or HDD 904. Figures 1 to 4 The control of each part of the server internal delay control device 100 is shown. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, a program depending on the hardware of the computer 900, and the like.
[0248] 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 obtains data from the input device 910 via the input / output I / F 905, and outputs the generated data to the output device 911. It should be noted that a GPU (Graphics Processing Unit: graphics processor) or the like may be used as a processor together with the CPU 901.
[0249] HDD 904 stores programs executed by CPU 901 and data used by the programs, etc. Communication I / F 906 receives data from other devices via a communication network (eg, NW (Network) 920) and outputs it to CPU 901, and transmits data generated by CPU 901 to other devices via the communication network.
[0250] The media I / F 907 reads the 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 target processing program from the recording medium 912 to 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 (Phasechange rewritable disk), an optical magnetic recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.
[0251] For example, when the computer 900 functions as the server delay control device 100 constituting one of the devices of the present embodiment, the CPU 901 of the computer 900 implements the function of the server delay control device 100 by executing the program loaded on the RAM 903. In addition, the data in the RAM 903 is stored in the HDD 904. The CPU 901 reads the program of the target process from the recording medium 912 and executes it. In addition, the CPU 901 may also read the program of the target process from other devices via the communication network (NW 920).
[0252] [Application Examples]
[0253] (How to configure polling threads in the kernel)
[0254] like Figure 2 The polling thread (server delay control device 100) shown in FIG. 1 can be applied to a server delay control device that starts a thread in the kernel that monitors the arrival of data packets using a polling model. In this case, the OS is not limited. In addition, it is not limited to a server virtualization environment. Therefore, the server delay control system can be applied to Fig.14 and Fig.15 The components shown.
[0255] <Application example to VM configuration>
[0256] Fig.14 FIG. 1 is a diagram showing an example of applying a server internal delay control system 1000A to an interrupt model in a server virtualization environment composed of a general-purpose Linux kernel (registered trademark) and VMs. Figure 1 and Fig.18 The same components are denoted by the same reference numerals.
[0257] like Fig.14 As shown, in the intra-server delay control system 1000A, the intra-server delay control device 100 is configured in the kernel 171 of the child operating system 70 , and the intra-server delay control device 100 is configured in the kernel 91 of the parent operating system 90 .
[0258] Specifically, the server includes a parent operating system 90 capable of operating the virtual machine and an external process formed outside the virtual machine, and a child operating system 70 operating in the virtual machine.
[0259] The parent operating system 90 includes: a kernel 91; a ring buffer 22, and a memory space in a server equipped with the parent operating system 90 is managed by the kernel 91; a receiving list 186 ( Figure 2), which registers information of a network device indicating which device the hardware interrupt (hardIRQ) from NIC11 is interrupting; a vhost-net module 221, which is a kernel thread; a tap device 222, which is a virtual interface created by the kernel 91; and a virtual switch (br) 223.
[0260] The core 91 includes a server-internal delay control device 100 .
[0261] The kernel 91 transfers the data packet to the virtual machine 40 composed of Linux (registered trademark) and KVM 30 via the tap device 222 .
[0262] On the other hand, the guest operating system 70 includes a kernel 171 , a ring buffer 52 , and a driver 53 . The driver 53 includes a virtio-driver 531 .
[0263] The core 171 includes the intra-server delay control device 100 and a protocol processing unit 74 that performs protocol processing on the data packets that have been cut out.
[0264] The kernel 171 passes the packet to the packet processing APL1 via the protocol processing unit 74 .
[0265] As a result, in a system composed of virtual servers of VMs, data packets can be transmitted with reduced delay in the server without changing the APL in either the parent operating system 90 or the child operating system 70.
[0266] <Application example to container configuration>
[0267] Fig.15 FIG. 1 is a diagram showing an example of applying a server internal delay control system 1000B to an interrupt model in a server virtualization environment composed of containers. Figure 1 and Fig.14 The same components are denoted by the same reference numerals.
[0268] like Fig.15 As shown, the server delay control system 1000B includes a container configuration in which the guest operating system 70 is replaced with a container 211. The container 211 includes a vNIC (virtual NIC) 212.
[0269] In a system composed of virtual servers such as containers, it is possible to transmit packets while reducing the delay within the server without changing the APL.
[0270] The above describes how to configure the polling thread in the kernel. Next, the following describes how to configure the polling thread in the user space.
[0271] (How to configure polling threads in user space)
[0272] like Figure 3 As shown, it can be applied to the configuration example of configuring the polling thread (delay control device 100 in the server) in the user space. In this case, the OS is not limited. In addition, it is not limited to the server virtualization environment. Therefore, the delay control system in the server can be applied Fig.16 and Fig.17 The components shown.
[0273] <Application example to VM configuration>
[0274] Fig.16 FIG. 1 is a diagram showing an example of applying a server internal delay control system 1000C to an interrupt model in a server virtualization environment composed of a general-purpose Linux kernel (registered trademark) and VMs. Figure 1 and Fig.14 The same components are denoted by the same reference numerals.
[0275] like Fig.16 As shown, the server delay control system 1000C includes a parent operating system 20 capable of operating a virtual machine and an external process formed outside the virtual machine, and the parent operating system 20 includes a kernel 21 and a driver 23. In addition, the server delay control system 1000C includes: a NIC 11 of HW connected to the parent operating system 20; a polling thread (server delay control device 100) configured in the user space 60; a virtual switch 53; a child operating system 50 operating in the virtual machine; and a polling thread (server delay control device 100) connected to the parent operating system 20 and configured in the user space 60.
[0276] Thus, in a system composed of virtual servers of VM, in either the parent operating system 20 or the child operating system 1 (50), packet transmission can be performed with reduced delay in the server without changing the APL.
[0277] <Application example to container configuration>
[0278] Fig.17 FIG. 1 is a diagram showing an example of applying a server internal delay control system 1000D to an interrupt model in a server virtualization environment composed of containers. Figure 1 , Fig.14 ,as well as Fig.16 The same components are denoted by the same reference numerals.
[0279] like Fig.17 As shown, the server internal delay control system 1000D has: Fig.16The sub operating system 50 is replaced with a container configuration of a container 211. The container 211 has a vNIC (virtual NIC) 212.
[0280] In a system composed of virtual servers such as containers, it is possible to transfer packets while reducing the delay within the server without changing the APL.
[0281] <Application example to bare machine configuration (non-virtualized configuration)>
[0282] The present invention can be applied to a non-virtualized system such as a bare metal system. In a non-virtualized system, data packets can be transmitted with reduced delay in the server without changing the APL.
[0283] <Horizontal shrinking / horizontal expansion>
[0284] When the traffic volume is large and multiple NIC devices and NIC ports are used, multiple polling threads can be operated in association with them, so that the polling threads can be scaled down / scaled out while the HW interrupt frequency is controlled.
[0285] <Expansion Technology>
[0286] When the number of service flows increases, the present invention cooperates with RSS (Receive-Side Scaling) that can process inbound network services through multiple CPUs to increase the number of CPUs allocated to the data packet arrival monitoring thread, thereby enabling horizontal expansion of the network load.
[0287] <Application to PCI device I / O such as accelerators>
[0288] Although the NIC (Network Interface Card) I / O is used as an example, this technology can also be applied to the I / O of PCI devices of accelerators (FPGA / GPU, etc.). In particular, it can be effectively used in polling when receiving the response to the offload result of FEC (Forward Error Correction) to the accelerator in vRAN.
[0289] <Application to Processors Other Than CPU>
[0290] In addition to the CPU, the present invention can also be similarly applied to a processor such as a GPU / FPGA / ASIC (application specific integrated circuit) having an idle function.
[0291] [Effect]
[0292] As described above, the server delay control device 100 (see Figure 1 and Figure 2 ) is configured in the kernel space of the OS, and starts a thread (thread) that uses a polling model to monitor the arrival of data packets, wherein the working modes of the thread (polling thread) include: a sleep control mode that can put the thread to sleep; and a continuous busy polling mode that causes the thread to perform continuous busy polling. The delay control device 100 in the server includes: a business frequency measuring unit 160 that measures the business inflow frequency; and a mode switching control unit 150 that switches the working mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the business inflow frequency measured by the business frequency measuring unit 160.
[0293] In previous examples, Figure 8 As shown by the double-headed arrow 11, when the packet inflow frequency reaches the threshold value T, even if sleep control is performed, the sleep time is short and the interruption overhead is greater, so there is a problem that the power consumption is higher than that of continuous busy polling.
[0294] In the server delay control device 100, the mode switching control unit 150 switches the mode based on the service inflow frequency, for example, when the service inflow frequency reaches a predetermined threshold value ( Figure 8 In the case of a threshold value T), the working mode of the thread (polling thread) is switched to one of the sleep control mode and the continuous busy polling mode. In this way, the sleep and sleep release actions when the business inflow frequency is "dense" can be suppressed, and power saving is achieved while achieving low latency. Specifically, by dynamically switching the appropriate data packet reception mode (sleep control mode / continuous busy polling mode) according to the business inflow frequency, the power saving effect based on sleep can be enjoyed during the period when the business inflow frequency is sparse. When the business inflow frequency is "dense", even if the interruption overhead is greater than the power saving effect based on sleep, continuous busy polling can be performed to prevent the deterioration of power consumption.
[0295] In addition, the following effects can be obtained by switching between the "sleep control mode" and the "continuous busy polling mode" instead of the sleep time control in the sleep control. That is, since it is not necessary to install the sleep control logic that is not required for the simple busy polling in the simple busy polling mode, it is possible to omit the calculation of the redundant control logic, and it is possible to reduce power consumption. In addition, since it is easy to create an independent program for each mode, it is easy to introduce personalized control for each mode.
[0296] In addition, since the arrival monitoring and reception processing of data packets are performed through the polling model, there will be no softIRQ conflict, which can reduce delays. In addition, when a data packet arrives during sleep, the polling thread is called up through the high-priority hardIRQ, so the overhead caused by sleep can be minimized.
[0297] Furthermore, during a period when no data packets arrive, the polling thread is put to sleep and the CPU frequency is controlled to be set low, thereby suppressing an increase in power consumption due to busy polling (power saving).
[0298] Furthermore, the present invention can be applied to a case where a polling thread exists inside a kernel, such as NAPI and KBP.
[0299] In addition, the server internal delay control device 100 (see Figure 1 and Figure 3 ) is configured in the user space (User space), and starts a thread (thread) that uses a polling model to monitor the arrival of data packets, wherein the working modes of the thread (polling thread) include: a sleep control mode that can put the thread to sleep; and a continuous busy polling mode that causes the thread to perform continuous busy polling. The delay control device 100 in the server includes: a business frequency measuring unit 160 that measures the business inflow frequency; and a mode switching control unit 150 that switches the working mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the business inflow frequency measured by the business frequency measuring unit 160.
[0300] This makes it possible to suppress sleep and sleep release actions when the traffic inflow frequency is "dense", thereby achieving low latency and power saving.
[0301] Furthermore, the present invention can be applied to a case where a polling thread exists in a user space, such as in DPDK.
[0302] In addition, the sub-operating system (sub-operating system 70) running in the virtual machine (see Fig.14 ) has: a core (core 171); a ring buffer (ring buffer 72) (refer to Fig.14), the memory space in the server with the sub-operating system is managed by the kernel; the packet arrival monitoring unit 110 monitors the polling list of the network device that registers the information indicating which device the hardware interrupt from the interface unit (NIC11) is interrupted by, and confirms whether the packet has arrived; the packet cutting unit 120, when the packet arrives, executes the cutting of the entry of the corresponding queue by referring to the packet stored in the ring buffer (ring buffer 72) and deleting the corresponding queue from the ring buffer; and the protocol processing unit performs the protocol processing of the cut packet, and the server delay control device 100 is provided in the kernel, and the server The in-server delay control device 100 starts a thread (thread) that uses a polling model to monitor the arrival of data packets. As far as the in-server delay control device 100 is concerned, the working modes of the thread (polling thread) include: a sleep control mode that can put the thread to sleep; and a continuous busy polling mode that causes the thread to perform continuous busy polling. The in-server delay control device 100 includes: a business frequency measuring unit 160 that measures the business inflow frequency; and a mode switching control unit 150 that switches the working mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the business inflow frequency measured by the business frequency measuring unit 160.
[0303] Therefore, in a system composed of virtual servers of VM, for a server having a sub-operating system (sub-operating system 70), sleep and sleep release actions can be suppressed when the business inflow frequency is "dense", thereby achieving low latency and power saving.
[0304] In addition, a host operating system (host operating system 90) that can operate the virtual machine and an external process formed outside the virtual machine (see Fig.14 )(Main operating system 20)(Refer to Fig.16 and Fig.17 ) has: a core (core 91); a ring buffer (ring buffer 72) (refer to Fig.18 ), the memory space in the server with the mother operating system is managed by the kernel; the packet arrival monitoring unit 110 monitors the polling list of the network device that registers the information indicating which device the hardware interrupt from the interface unit (NIC11) is interrupted by, and confirms whether the packet has arrived; the packet cutting unit 120, when the packet arrives, executes the cutting of the entry of the referenced packet stored in the ring buffer and deletes the corresponding queue from the ring buffer; and the tap device 222 (refer to Fig.14), which is a virtual interface created by the kernel (kernel 21), and a server-side delay control device 100 is provided in the kernel. The server-side delay control device 100 starts a thread (thread) that uses the polling model to monitor the arrival of data packets. As for the server-side delay control device 100, the working modes of the thread include: a sleep control mode that can put the thread to sleep; and a continuous busy polling mode that causes the thread to perform continuous busy polling. The server-side delay control device 100 includes: a business frequency measuring unit 160 that measures the business inflow frequency; and a mode switching control unit 150 that switches the working mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the business inflow frequency measured by the business frequency measuring unit 160.
[0305] Therefore, in a system composed of virtual servers of VM, for a server having a kernel (kernel 171) and a parent operating system (parent operating system 90), the sleep and sleep release actions can be suppressed when the business inflow frequency is "dense", thereby achieving low latency and power saving.
[0306] The delay control device 100 in the server (refer to Figure 1 to Figure 4 ), the mode switching control unit 150 is characterized in that, in the process of switching from the area with low traffic inflow frequency to the area with a predetermined threshold value ( Figure 8 The working mode of the thread (polling thread) is switched to the sleep control mode until the threshold T of the business inflow is reached. Figure 8 When the threshold T) is exceeded, it switches to continuous busy polling mode.
[0307] Therefore, if Figure 8 As shown in FIG. 1 , the “area where the sleep control mode should be used” (refer to FIG. 1 ) is from the low packet inflow frequency to the threshold T. Figure 8 In the figure mark jj), the working mode of the thread (polling thread) can be switched to the sleep control mode, and in the "area where the continuous busy polling mode should be used" above the threshold T (refer to Figure 8 In the figure mark kk), the working mode of the thread (polling thread) can be switched to the continuous busy polling mode. Therefore, when the frequency of business inflow above the threshold T is "dense", power consumption can be suppressed by switching to the continuous busy polling mode. It should be noted that the threshold T is Fig. 9 The switching judgment logic shown in the table selects the optimal value.
[0308] The delay control device 100 in the server (refer to Figure 1 to Figure 4), comprising: a data packet arrival monitoring unit 110, which, in the case of continuous busy polling mode, monitors (polls) the arrival of data packets from the interface unit (NIC11) to confirm whether the data packets have arrived; and a sleep management unit 130, which, in the case of sleep control mode, puts the thread (polling thread) to sleep (Sleep) when the data packet does not arrive within a specified period of time, and releases the sleep of the thread (polling thread) through a hardware interrupt (hardIRQ) when a data packet arrives.
[0309] Thus, in the case of continuous busy polling mode, the data packet arrival monitoring unit 110 performs data packet arrival monitoring and reception processing through the polling model, so no softIRQ conflict occurs, and the delay can be reduced. In addition, in the case of sleep control mode, when a data packet arrives during sleep, the sleep management unit 130 starts the polling thread through the hardIRQ with high priority, so the overhead caused by sleep can be suppressed as much as possible.
[0310] It should be noted that in the above embodiment, the case where a polling thread exists in the kernel as in NAPI and KBP is described, but the polling thread may also be configured in the user space as in DPDK (see Figure 3 , Fig.17 ).
[0311] In addition, in each process described in the above embodiment, all or part of the process described as automatic execution may be manually executed, or all or part of the process described as manual execution may be automatically executed by a known method. In addition, the process, control process, specific name, and information including various data and parameters shown in the above text and drawings may be changed arbitrarily except for the cases specifically described.
[0312] In addition, the components of each device shown in the figure are conceptual functions and do not necessarily need to be physically configured as shown in the figure. That is, the specific method of distributing / integrating each device is not limited to the method shown in the figure, and all or part of them can be functionally or physically distributed / integrated in arbitrary units according to various loads, usage conditions, etc.
[0313] In addition, the above-mentioned structures, functions, processing parts, processing units, etc. can also be implemented by hardware, such as designing a part or all of them with integrated circuits. In addition, the above-mentioned structures, functions, etc. can also be implemented by software for a processor to interpret and execute the program of each function. Information such as programs, tables, files, etc. that implement each function can be stored in a recording device such as a memory, a hard disk, an SSD (Solid State Drive), or an IC (Integrated Circuit) card, an SD (Secure Digital) card, an optical disk, etc., or a recording medium such as a CD.
[0314] Description of reference numerals:
[0315] 1: Packet processing APL (application); 10: HW; 11: NIC (physical NIC) (interface); 20, 90: parent operating system (OS); 22, 52, 72: ring buffer (Ring Buffer); 50, 70: child operating system (OS); 60: user space (userspace); 74: protocol processing unit; 86, 186: receiving list (polling list); 91, 171: kernel (Kernel); 100: server internal delay control device (polling thread); 110: packet arrival monitoring unit; 120: packet cutting unit; 130: sleep management unit (sleep management unit); 140: CPU frequency / CPU idle setting unit; 150: mode switching control unit; 160: business frequency measurement unit; 211: container (Container); 1000, 1000A, 1000B, 1000C, 1000D: server internal delay control system; T: threshold value.
Claims
1. A delay control device in a server, configured in the kernel space of an operating system, and starting a thread that uses a polling model to monitor the arrival of data packets, characterized in that: The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The delay control device in the server comprises: A business frequency measurement unit measures the business inflow frequency; and A mode switching control unit switches the operation mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the traffic inflow frequency measured by the traffic frequency measurement unit.
2. A delay control device in a server, configured in user space, and starting a thread that uses a polling model to monitor the arrival of data packets, characterized in that: The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The delay control device in the server comprises: A business frequency measurement unit measures the business inflow frequency; and A mode switching control unit switches the operation mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the traffic inflow frequency measured by the traffic frequency measurement unit.
3. A delay control device in a server, characterized in that: The sub-operating system running in the virtual machine has: Kernel; a ring buffer, a memory space in a server having the sub-operating system managed by the kernel; The data packet arrival monitoring unit monitors the polling list of the network device that registers information indicating which device has interrupted the hardware interrupt from the interface unit, and confirms whether the data packet has arrived; a packet cutting unit, which, when a packet arrives, performs cutting by referring to the packet stored in the ring buffer and deleting the entry of the corresponding queue from the ring buffer; as well as The protocol processing unit performs protocol processing on the data packets cut out. The kernel is provided with the server delay control device, and the server delay control device starts a thread that monitors the arrival of data packets using a polling model. As for the delay control device in the server, The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The delay control device in the server comprises: A business frequency measurement unit measures the business inflow frequency; and A mode switching control unit switches the operation mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the traffic inflow frequency measured by the traffic frequency measurement unit.
4. A delay control device in a server, characterized in that: The mother operating system capable of operating the virtual machine and the external process formed outside the virtual machine has: Kernel; a ring buffer, a memory space in a server having the mother operating system managed by the kernel; The data packet arrival monitoring unit monitors the arrival of data packets from the interface unit and confirms whether the data packets have arrived; a packet cutting unit that, when a packet arrives, performs cutting by referring to the packet stored in the ring buffer and deleting an entry of a corresponding queue from the ring buffer; and The tap device is a virtual interface created by the kernel. The kernel is provided with the server delay control device, and the server delay control device starts a thread that monitors the arrival of data packets using a polling model. As for the delay control device in the server, The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The delay control device in the server comprises: A business frequency measurement unit measures the business inflow frequency; and A mode switching control unit switches the operation mode of the thread to one of the sleep control mode and the continuous busy polling mode based on the traffic inflow frequency measured by the traffic frequency measurement unit.
5. The server delay control device according to any one of claims 1 to 4, characterized in that: The mode switching control unit switches the operation mode of the thread to the sleep control mode from a low traffic inflow frequency region to a predetermined threshold, and switches to the continuous busy polling mode when the traffic inflow frequency is greater than the predetermined threshold.
6. The server delay control device according to claim 1 or claim 2, characterized in that: have: A data packet arrival monitoring unit monitors a polling list that registers information indicating which device has interrupted a hardware interrupt from the interface unit, in the case of the continuous busy polling mode, to confirm whether a data packet has arrived; as well as The sleep management unit, in the sleep control mode, puts the thread to sleep when no data packet arrives within a predetermined period of time, and releases the thread from sleep by a hardware interrupt when a data packet arrives.
7. A method for controlling delay in a server by a delay control device in a server, wherein the delay control device in the server is configured in the kernel space of an operating system and starts a thread for monitoring the arrival of data packets using a polling model, wherein the method for controlling delay in the server is characterized in that: The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The server internal delay control method performs the following steps: Measuring the frequency of business inflow; and Based on the measured traffic inflow frequency, the operation mode of the thread is switched to one of the sleep control mode and the continuous busy polling mode.
8. A method for controlling delay in a server of a delay control device in a server, wherein the delay control device in the server is configured in a user space and starts a thread for monitoring the arrival of data packets using a polling model, wherein the method for controlling delay in the server is characterized in that: The working modes of the thread include: a sleep control mode, which can make the thread sleep; and a continuous busy polling mode, which makes the thread perform continuous busy polling. The server internal delay control method performs the following steps: Measuring the frequency of business inflow; and Based on the measured traffic inflow frequency, the operation mode of the thread is switched to one of the sleep control mode and the continuous busy polling mode.
9. A program for causing a computer to function as the server internal delay control device according to any one of claims 1 to 4.
Citation Information
Patent Citations
Intra-server delay control device, intra-server delay control method, and program
WO2021130828A1
Cited By
High-performance virtualized network data plane acceleration method based on DPDK and SR-IOV
CN121924073A
