WO2023144878A1 - サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム - Google Patents

サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム Download PDF

Info

Publication number
WO2023144878A1
WO2023144878A1 PCT/JP2022/002637 JP2022002637W WO2023144878A1 WO 2023144878 A1 WO2023144878 A1 WO 2023144878A1 JP 2022002637 W JP2022002637 W JP 2022002637W WO 2023144878 A1 WO2023144878 A1 WO 2023144878A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
interrupt
sleep
intra
delay control
Prior art date
Application number
PCT/JP2022/002637
Other languages
English (en)
French (fr)
Inventor
圭 藤本
廣 名取
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2022/002637 priority Critical patent/WO2023144878A1/ja
Publication of WO2023144878A1 publication Critical patent/WO2023144878A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to an intra-server delay control device, an intra-server delay control method, and a program.
  • NFV Network Functions Virtualization
  • SFC Service Function Chaining
  • a hypervisor environment composed of Linux (registered trademark) and KVM (kernel-based virtual machine) is known as a technology for configuring virtual machines.
  • the Host OS with the KVM module installed (the OS installed on the physical server is called the Host OS) operates as a hypervisor in a memory area called the kernel space, which is different from the user space.
  • the kernel space which is different from the user space.
  • a virtual machine runs in the user space
  • a Guest OS an OS installed on the virtual machine is called a Guest OS
  • a virtual machine running a Guest OS is different from a physical server running a Host OS. This is the register control required for load processing and writing from the Guest OS to the hardware. In such register control, the notification and processing that should be executed by the physical hardware are simulated by software, so the performance is generally lower than that of the host OS environment.
  • Virtio defines data exchange using a queue designed with a ring buffer as a unidirectional transfer transport for transfer data with respect to data input/output such as console, file input/output, and network communication. Then, using the virtio queue specifications, by preparing the number and size of queues suitable for each device when starting the Guest OS, communication between the Guest OS and the outside of the virtual machine can be performed using hardware emulation. It can be realized only by operations by queue without execution.
  • DPDK example Packet transfer by polling model
  • Inter-VM Communication A method of connecting and coordinating multiple virtual machines is called Inter-VM Communication, and in large-scale environments such as data centers, virtual switches have been used as standard for connecting VMs.
  • this method involves a large communication delay, a new method with higher speed has been proposed.
  • SR-IOV Single Root I/O Virtualization
  • DPDK Intelligent Data Plane Development Kit
  • DPDK is a framework for controlling the NIC (Network Interface Card), which was conventionally performed by the Linux kernel (registered trademark), in user space.
  • the biggest difference from the processing in the Linux kernel is that it has a polling-based reception mechanism called PMD (Pull Mode Driver).
  • PMD Pull Mode Driver
  • PMD a dedicated thread continuously performs data arrival confirmation and reception processing.
  • High-speed packet processing can be achieved by eliminating overhead such as context switches and interrupts.
  • DPDK greatly enhances packet processing performance and throughput, allowing more time for data plane application processing.
  • DPDK exclusively uses computer resources such as CPU (Central Processing Unit) and NIC. For this reason, it is difficult to apply it to applications such as SFC that flexibly switch connections on a module-by-module basis.
  • SPP Soft Patch Panel
  • the SPP omits packet copying in the virtualization layer by preparing a shared memory between VMs so that each VM can directly refer to the same memory space.
  • DPDK is used for packet exchange between the physical NIC and the shared memory to achieve high speed.
  • the SPP can change the packet input destination and output destination by software by controlling the reference destination of memory exchange of each VM. Through this processing, the SPP realizes dynamic connection switching between VMs and between VMs and physical NICs.
  • FIG. 13 is a schematic diagram of Rx-side packet processing by New API (NAPI) implemented by Linux kernel 2.5/2.6 (see Non-Patent Document 1).
  • New API (NAPI) executes packet processing APL1 located in User space 60 available to users on a server equipped with OS 70 (for example, Host OS), and is connected to OS 70. Packet transfer is performed between the NIC 11 of the HW 10 and the packet processing APL1.
  • OS 70 for example, Host OS
  • OS 70 has kernel 71 , Ring Buffer 72 and Driver 73 , and kernel 71 has protocol processor 74 .
  • the Kernel 71 is a function of the core part of the OS 70 (for example, the host OS), and monitors hardware and manages the execution state of programs on a process-by-process basis. Here, the kernel 71 responds to the request from the packet processing APL1 and also transmits the request from the HW 10 to the packet processing APL1. Kernel 71 processes requests from packet processing APL 1 through system calls ("user program running in non-privileged mode" requests processing from "kernel running in privileged mode"). . Kernel 71 transfers the packet to packet processing APL 1 via Socket 75 . Kernel 71 receives packets from packet processing APL 1 via Socket 75 .
  • the Ring Buffer 72 is managed by the Kernel 71 and resides in the memory space of the server.
  • the Ring Buffer 72 is a buffer of a fixed size that stores messages output by the Kernel 71 as a log, and is overwritten from the beginning when the upper limit size is exceeded.
  • the Driver 73 is a device driver for monitoring hardware in the kernel 71. Note that the Driver 73 depends on the kernel 71, and if the created (built) kernel source changes, it becomes a different entity. In this case, obtain the corresponding driver source, rebuild it on the OS that uses the driver, and create the driver.
  • the protocol processing unit 74 performs L2 (data link layer)/L3 (network layer)/L4 (transport layer) protocol processing defined by the OSI (Open Systems Interconnection) reference model.
  • Socket 75 is an interface for kernel 71 to communicate between processes. Socket 75 has a socket buffer and does not generate data copy processing frequently.
  • the flow up to establishment of communication via Socket 75 is as follows. 1. The server side creates a socket file that accepts clients. 2. Name the reception socket file. 3. Create a socket queue. 4. Accept the first one of the connections from the client in 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, create a socket file for connection separately from the socket file for reception.
  • the packet processing APL 1 can call system calls such as read( ) and write( ) to the kernel 71 .
  • the Kernel 71 receives notification of packet arrival from the NIC 11 through a hardware interrupt (hardIRQ) and schedules a software interrupt (softIRQ) for packet processing.
  • the above New API (NAPI) implemented from Linux kernel 2.5/2.6 performs packet processing by software interrupt (softIRQ) after hardware interrupt (hardIRQ) when a packet arrives.
  • FIG. 13 in packet transfer based on the interrupt model, packets are transferred by interrupt processing (see symbol a in FIG. 13), so waiting for interrupt processing occurs and packet transfer delay increases. .
  • FIG. 14 is a diagram for explaining the outline of Rx side packet processing by New API (NAPI) in the portion surrounded by the dashed line in FIG. 13 .
  • the device driver includes a NIC 11 (physical NIC) that is a network interface card, hardIRQ 81 that is a handler that is called and executes requested processing (hardware interrupt) when a processing request is generated from the NIC 11, and netif_rx 82, which is a software interrupt processing functional unit.
  • NIC 11 physical NIC
  • hardIRQ 81 that is a handler that is called and executes requested processing (hardware interrupt) when a processing request is generated from the NIC 11
  • netif_rx 82 which is a software interrupt processing functional unit.
  • softIRQ 83 which is a handler that is invoked by generation of a processing request of netif_rx 82 and executes the requested processing (software interrupt)
  • do_softirq 84 which is a control function unit that performs the substance of the software interrupt (softIRQ)
  • net_rx_action 85 which is a packet processing function unit that receives and executes a software interrupt (softIRQ)
  • a netif_receive_skb 87 and a Ring Buffer 72 that create an sk_buff structure (a structure that allows the Kernel 71 to perceive what is happening in the packet) are arranged.
  • the protocol layer includes ip_rcv 88, arp_rcv 89, etc., which are packet processing functional units.
  • netif_rx82, do_softirq84, net_rx_action85, netif_receive_skb87, ip_rcv88, and arp_rcv89 are program parts (function names) used for packet processing in Kernel71.
  • FIG. 14 [Rx side packet processing operation by New API (NAPI)] Arrows (codes) b through m in FIG. 14 indicate the flow of packet processing on the Rx side.
  • the hardware function unit 11a of the NIC 11 hereinafter referred to as the NIC 11
  • the packet arrives at the Ring Buffer 72 without using the CPU by DMA (Direct Memory Access) transfer. is copied (see symbol b in FIG. 14).
  • the Ring Buffer 72 is a memory space within the server and is managed by the Kernel 71 (see FIG. 13).
  • the Kernel 71 cannot recognize the packet if the NIC 11 just copies the packet that has arrived to the Ring Buffer 72. Therefore, when the packet arrives, the NIC 11 raises a hardware interrupt (hardIRQ) to the hardIRQ 81 (see symbol c in FIG. 14), and the netif_rx 82 executes the following processing, so that the Kernel 71 recognizes the packet.
  • hardIRQ hardware interrupt
  • the hardIRQ 81 surrounded by an ellipse in FIG. 14 represents a handler rather than a functional unit.
  • netif_rx 82 is a function that actually executes processing. saves net device (net_device) information that indicates which device the hardware interrupt of is for. Then, netif_rx 82 registers queue reaping (refers to the contents of the packet accumulated in the buffer, processes the packet, and deletes the corresponding queue entry from the buffer in consideration of the next process). (See symbol e in FIG. 14). Specifically, the netif_rx 82 uses the driver of the NIC 11 to register subsequent queue pruning in the poll_list 86 in response to the fact that the Ring Buffer 72 is filled with packets (see symbol e in FIG. 14). As a result, the poll_list 86 is registered with the queue reaping information due to the packets stuffed into the Ring Buffer 72 .
  • NIC 11 when the NIC 11 receives a packet, it copies the packet that has arrived to the Ring Buffer 72 by DMA transfer. In addition, NIC 11 raises hardIRQ 81 (handler), netif_rx 82 registers net_device in poll_list 86, and schedules software interrupts (softIRQ). Up to this point, hardware interrupt processing in ⁇ Device driver> in FIG. 14 stops.
  • netif_rx 82 uses the queued information (specifically, the pointer) loaded in poll_list 86 to reap the data stored in Ring Buffer 72 with a software interrupt (softIRQ). (handler) (see symbol f in FIG. 14), and notify do_softirq 84, which is the software interrupt control function unit (see symbol g in FIG. 14).
  • the do_softirq 84 is a software interrupt control function unit that defines each function of software interrupts (there are various types of packet processing, and interrupt processing is one of them; interrupt processing is defined). Based on this definition, do_softirq 84 notifies net_rx_action 85, which actually performs software interrupt processing, of the current (corresponding) software interrupt request (see symbol h in FIG. 14).
  • net_rx_action 85 calls a polling routine for reaping packets from Ring Buffer 72 based on net_device registered in poll_list 86 (see symbol i in FIG. 14), and reaps packets ( (See symbol j in FIG. 14). At this time, net_rx_action 85 continues to reap until poll_list 86 is empty. After that, net_rx_action 85 notifies netif_receive_skb 87 (see symbol k in FIG. 14).
  • the netif_receive_skb 87 creates an sk_buff structure, analyzes the contents of the packet, and forwards the processing to the subsequent protocol processing unit 74 (see FIG. 13) for each type. That is, the netif_receive_skb 87 analyzes the contents of the packet, and when processing according to the contents of the packet, passes the processing to the ⁇ Protocol layer> ip_rcv 88 (mark l in FIG. 14), and for example, if it is L2 The processing is passed to arp_rcv 89 (symbol m in FIG. 14).
  • Patent Document 1 describes an in-server network delay control device (KBP: Kernel Busy Poll).
  • KBP Kernel Busy Poll
  • the KBP constantly monitors packet arrivals through a polling model within the kernel. This suppresses softIRQ and realizes low-delay packet processing.
  • both the interrupt model and polling model packet transfer have the following problems.
  • packets are transferred by software interrupt processing for packet processing by the kernel that receives an event (hardware interrupt) from the HW. Therefore, in the interrupt model, packet transfer is performed by interrupt (software interrupt) processing. is generated, and there is a problem that the delay in packet transfer increases. In this case, if the interrupt process is congested, the waiting delay will increase. For example, in packet transfer based on the interrupt model, since packets are transferred by interrupt processing, queuing of interrupt processing occurs, resulting in a large delay in packet transfer.
  • FIG. 15 is an example of video (30 FPS) data transfer.
  • the workload shown in FIG. 15 intermittently transfers data every 30 ms at a transfer rate of 350 Mbps.
  • FIG. 16 is a diagram showing the CPU usage rate used by the busy poll thread in the KBP described in Patent Document 1.
  • FIG. 16 in KBP, a kernel thread occupies a CPU core in order to perform busy polling. Even with the intermittent packet reception shown in FIG. 15, the KBP always uses the CPU regardless of whether packets arrive or not, so there is a problem of increased power consumption.
  • the present invention has been made in view of this background, and the present invention suppresses the occurrence of excessive HW interrupts caused by sleeping the polling thread, reduces power consumption, and reduces delays in the server.
  • the object is to perform packet transfer with a small size.
  • an intra-server delay control device is arranged in the kernel space of the OS and launches a thread for monitoring packet arrival using a polling model.
  • a packet arrival monitoring unit that monitors a poll list that registers net device information indicating which device the hardware interrupt from is for.
  • a packet harvesting unit that performs harvesting by referring to and deleting the corresponding queue entry from the ring buffer based on the processing to be performed next; sleeping the thread if the packet does not arrive for a predetermined period; is a sleep management unit that releases the sleep of the thread by a hardware interrupt, a HW interrupt count storage unit that stores the number of hardware interrupts, and calculates the HW interrupt frequency based on the hardware interrupt count. and a HW interrupt frequency control unit for controlling HW interrupt permission or prohibition due to the sleep of the sleep management unit based on the calculated HW interrupt frequency. bottom.
  • the present invention it is possible to suppress the occurrence of excessive HW interrupts caused by sleeping polling threads, reduce power consumption, and perform packet transfer with a small delay in the server.
  • FIG. 1 is a schematic configuration diagram of an intra-server delay control system according to an embodiment of the present invention
  • FIG. This is a configuration example in which the polling thread (in-server delay control device) of FIG. 1 is arranged in the kernel space.
  • FIG. 4 is a diagram showing an example of polling thread operation of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention
  • 4 is a graph showing the relationship between the packet arrival speed and the number of hardIRQs in the intra-server delay control system according to the embodiment of the present invention
  • FIG. 10 is a diagram showing a HW interrupt due to packet arrival and a polling thread that is started by the HW interrupt in a comparative example
  • FIG. 10 is a diagram showing a HW interrupt due to packet arrival and a polling thread that is started by the HW interrupt
  • 4 is a flowchart showing NIC and HW interrupt processing of a polling thread (intra-server delay control device) of the in-server delay control system according to the embodiment of the present invention
  • 7 is a flowchart showing HW interrupt frequency control processing of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention
  • 1 is a hardware configuration diagram showing an example of a computer that implements the functions of an intra-server delay control device of an intra-server delay control system according to an embodiment of the present invention
  • FIG. 10 is a diagram showing an example of applying an intra-server delay control system to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration;
  • FIG. 10 is a diagram showing an example in which an intra-server delay control system is applied to an interrupt model in a container-configured server virtualization environment;
  • FIG. 4 is a schematic diagram of Rx-side packet processing by New API (NAPI) implemented from Linux kernel 2.5/2.6;
  • FIG. 14 is a diagram for explaining an outline of Rx-side packet processing by New API (NAPI) in a portion surrounded by a dashed line in FIG. 13;
  • FIG. 10 is a diagram showing an example of data transfer of video (30 FPS);
  • FIG. 10 is a diagram showing a CPU usage rate used by a busy poll thread in the KBP described in Patent Document 1;
  • FIG. 1 is a schematic configuration diagram of an intra-server delay control system according to an embodiment of the present invention.
  • This embodiment is an example applied to packet processing on the Rx side by New API (NAPI) implemented by Linux kernel 2.5/2.6.
  • NAPI New API
  • the intra-server delay control system 1000 executes a packet processing APL1 located in a user space available to users on a server having an OS (for example, Host OS), and is connected to the OS. Packet transfer is performed between the HW NIC 11 and the packet processing APL 1 .
  • OS for example, Host OS
  • the intra-server delay control system 1000 includes a NIC 11 (physical NIC) that is a network interface card, a hardIRQ 81 that is a handler that executes a requested process (hardware interrupt) that is called upon the occurrence of a processing request from the NIC 11, and a HW interrupt. It comprises a HW interrupt processing unit 182 , a receive list 186 , a Ring_Buffer 72 , a polling thread (in-server delay control device 100 ), and a protocol processing unit 74 , which are processing function units.
  • the Ring Buffer 72 is managed by the kernel in the memory space inside the server.
  • the Ring Buffer 72 is a buffer of a fixed size that stores messages output by the kernel as a log, and is overwritten from the beginning when the maximum size is exceeded.
  • the protocol processing unit 74 is Ethernet, IP, TCP/UDP, and the like.
  • the protocol processing unit 74 performs L2/L3/L4 protocol processing defined by, for example, the OSI reference model.
  • the intra-server delay control device 100 is a polling thread arranged in either kernel space or user space.
  • the intra-server delay control device 100 includes a packet arrival monitoring unit 110, a packet harvesting unit 120, a sleep management unit 130, a CPU frequency/CPU idle setting unit 140, and a HW interrupt count management table 150a (HW interrupt count storage). ), and a HW interrupt frequency control unit 150 having
  • the packet arrival monitoring unit 110 is a thread for monitoring whether packets have arrived.
  • the packet arrival monitor 110 monitors (polls) the receive list 186 .
  • the packet arrival monitoring unit 110 acquires pointer information indicating that a packet exists in the Ring_Buffer 72 and net_device information from the receive list 186, and transmits the information (pointer information and net_device information) to the packet harvesting unit 120.
  • the information pointer information and net_device information
  • the packet reaping unit 120 refers to the packet held in the Ring Buffer 72 and executes reaping to delete the corresponding queue entry from the Ring Buffer 72 based on the next process (hereinafter referred to as It may simply prune the packet from the Ring Buffer 72).
  • the packet harvesting unit 120 extracts packets from the Ring_Buffer 72 based on the received information, and transmits the packets to the protocol processing unit 74 .
  • the packet harvesting unit 120 harvests the multiple packets collectively and passes them to the subsequent protocol processing unit 74.
  • FIG. Note that this number of harvests collectively is called a quota, and is often called batch processing.
  • the protocol processing unit 74 also performs protocol processing at high speed because it processes a plurality of packets collectively.
  • the sleep management unit 130 puts a thread (polling thread) to sleep when a packet does not arrive for a predetermined period of time, and cancels sleep by a hardware interrupt (hardIRQ) of this thread (polling thread) when a packet arrives. Do (details below).
  • the CPU frequency/CPU idle setting unit 140 sets the CPU operating frequency of the CPU core used by the polling thread to a low value during sleep.
  • the CPU frequency/CPU idle setting unit 140 sets the CPU idle state of the CPU core used by this thread (polling thread) to the power saving mode during sleep (details will be described later).
  • the HW interrupt frequency control unit 150 calculates the HW interrupt frequency based on the number of HW interrupts, and controls HW interrupt permission or prohibition due to the sleep of the sleep management unit 130 based on the calculated HW interrupt frequency. do. Specifically, the HW interrupt frequency control unit 150 compares the calculated HW interrupt frequency with a predetermined threshold value, and if the HW interrupt frequency is smaller than the predetermined threshold value, the sleep management unit 130 executes sleep for a certain period of time. (details below).
  • the HW interrupt count management table 150a stores the time stamp of HW interrupt occurrence (the time stamp indicating when the HW interrupt occurred) as the number of HW interrupts.
  • the HW interruption frequency control unit 150 calculates the number of HW interruptions based on the number of time stamps stored in the HW interruption number management table 150a.
  • FIG. 2 is a configuration example in which the polling thread (in-server delay control device 100) of FIG. 1 is arranged in the kernel space.
  • a polling thread server delay control device 100
  • a protocol processing unit 74 are arranged in the kernel space. This polling thread (intra-server delay control device 100) operates within the kernel space.
  • the intra-server delay control system 1000 executes a packet processing APL1 located in User space on a server equipped with an OS, and sends packets between the HW NIC11 and the packet processing APL1 via a device driver connected to the OS. make a transfer.
  • the device driver includes hardIRQ 81, HW interrupt processor 182, receive list 186, and Ring_Buffer 72.
  • FIG. A device driver is a driver for monitoring hardware.
  • the present invention can be applied when there is a polling thread inside the kernel like NAPI or KBP.
  • FIG. 3 is a configuration example in which the polling thread (in-server delay control device 100) of FIG. 1 is arranged in User Space.
  • a polling thread server delay control device 100
  • a protocol processing unit 74 are arranged in a user space.
  • This polling thread (in-server delay control device 100) operates in User space, not in Kernel space.
  • the polling thread bypasses the kernel space and transfers packets between the device driver and NIC 11 and the packet processing APL1.
  • the present invention can be applied when there is a polling thread in the user space like DPDK.
  • FIGS. 1 to 3 indicate the flow of packet processing on the Rx side.
  • the NIC 11 receives a packet (or frame) within a frame from the opposite device, it copies the arriving packet to the Ring Buffer 72 by DMA transfer without using the CPU (see symbol aa in FIGS. 1 to 3).
  • This Ring Buffer 72 is managed by ⁇ Device driver>.
  • the NIC 11 When a packet arrives, the NIC 11 raises a hardware interrupt (hardIRQ) to the hardIRQ 81 (handler) (see symbols bb in FIGS. 1 to 3), and the HW interrupt processing unit 182 executes the following processing. , recognize the packet.
  • hardIRQ hardware interrupt
  • the HW interrupt processing unit 182 executes the following processing. , recognize the packet.
  • the HW interrupt processing unit 182 stores the receive list 186 with one of the information contained in the hardware interrupt (hardIRQ) from the NIC 11. register the queue reaping information by saving net device (net_device) information indicating which device the hardware interrupt belongs to. Specifically, the HW interrupt processing unit 182 uses the driver of the NIC 11 in response to the fact that packets are packed in the Ring Buffer 72, and registers subsequent queue harvesting in the receive list 186 (see FIGS. 1 to 3). (see symbol dd). As a result, the receive list 186 registers the pruning of the queue due to the packets being stuffed into the Ring Buffer 72 .
  • the HW interrupt processing unit 182 registers net_device in the receive list 186, but unlike netif_rx 82 in FIG. 14, it does not schedule software interrupts (softIRQ). That is, the HW interrupt processing unit 182 differs from the netif_rx 82 in FIG. 14 in that it does not schedule software interrupts (softIRQ).
  • the HW interrupt processing unit 182 cancels sleep by awakening the sleeping polling thread (see symbol ee in FIGS. 1 to 3). Up to this point, hardware interrupt processing in ⁇ Device driver> in FIGS. 1 to 3 stops.
  • softIRQ 83 and do_softirq 84 are deleted in the ⁇ Networking layer> shown in FIG. 14, and along with this, netif_rx 82 shown in FIG. Not performed.
  • the intra-server delay control system 1000 deletes the softIRQ 83 and do_softirq 84 shown in FIG. 14 and instead provides a polling thread (in-server delay control device 100) in ⁇ kernel space> (see FIG. 2).
  • the intra-server delay control system 1000 provides a polling thread (in-server delay control device 100) in ⁇ User space> (see FIG. 3).
  • the packet arrival monitoring unit 110 monitors (polls) the receive list 186 (see symbol gg in FIGS. 1 to 3) to check whether packets have arrived.
  • Packet arrival monitoring unit 110 acquires pointer information indicating that a packet exists in Ring_Buffer 72 and net_device information from receive list 186, and transmits the information (pointer information and net_device information) to packet harvesting unit 120 (Figs. 3 symbol hh).
  • the multiple pieces of information are transmitted.
  • the packet harvesting unit 120 of the intra-server delay control device 100 harvests the packet from the Ring Buffer 72 when the packet has arrived (see symbol ii in FIGS. 1 to 3).
  • the packet harvesting unit 120 extracts packets from the Ring_Buffer 72 based on the received information, and transmits the packets to the protocol processing unit 74 (see symbol jj in FIGS. 1 to 3).
  • the intra-server delay control system 1000 stops the packet processing softIRQ, which is the main cause of NW delay, and the packet arrival monitoring unit 110 of the intra-server delay control device 100 executes a polling thread for monitoring packet arrival. Then, when a packet arrives, the packet harvesting unit 120 processes the packet according to the polling model (without softIRQ).
  • a polling thread is triggered in the hardware interrupt handler to avoid softIRQ contention and enable immediate packet transfer processing.
  • a polling thread is triggered in the hardware interrupt handler to avoid softIRQ contention and enable immediate packet transfer processing.
  • the hardware interrupt handler to avoid softIRQ contention and enable immediate packet transfer processing.
  • a polling thread (intra-server delay control device 100) that monitors packet arrival can sleep while no packet arrives.
  • the polling thread (intra-server delay control device 100) sleeps depending on whether or not a packet arrives, and cancels sleep by hardIRQ 81 when a packet arrives.
  • the sleep management unit 130 of the intra-server delay control device 100 causes the polling thread to sleep according to the presence or absence of packet arrival, that is, if no packet arrives for a predetermined period of time.
  • the sleep management unit 130 cancels sleep using hardIRQ 81 when a packet arrives. This avoids softIRQ contention and achieves low latency.
  • the CPU frequency/CPU idle setting unit 140 of the intra-server delay control device 100 changes the CPU operating frequency and idle settings according to whether or not packets have arrived. Specifically, the CPU frequency/CPU idle setting unit 140 lowers the CPU frequency during sleep, and raises the CPU frequency (returns the CPU operating frequency to the original value) during restart. Also, the CPU frequency/CPU idle setting unit 140 changes the CPU idle setting to power saving during sleep. Power saving is also achieved by lowering the CPU operating frequency during sleep and changing the CPU idle setting to power saving.
  • FIG. 4 is a diagram showing an example of the polling thread operation of the intra-server delay control device 100.
  • the vertical axis indicates the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis indicates time.
  • 4 shows a polling thread operation example due to packet arrival corresponding to the data transfer example of video (30 FPS) in which packets are intermittently received shown in FIG.
  • the sleep management unit 130 of the intra-server delay control device 100 when no packet arrives for a predetermined period When the next packet does not arrive even after the value (fixed period) has passed), the polling thread is made to sleep (see symbol p in FIG. 4).
  • the sleep management unit 130 activates the polling thread at hardIRQ 81 of packet arrival (see symbol q in FIG. 4).
  • the timer interrupt for system stable operation enters the corresponding CPU core, and the migration thread for error processing etc. enters the corresponding CPU core, the CPU usage rate of the CPU core used by the polling thread may fluctuate (see symbol r in FIG. 4).
  • the polling thread inhibits the hardware interrupt request (hardIRQ) and performs packet reception by polling when there is an unreceived packet in the Ring Buffer 72 .
  • the hardware interrupt request (hardIRQ)
  • the number of hardIRQs due to packet arrival increases, and the hardIRQ overhead may increase the packet transfer delay time and power consumption.
  • Describe hardIRQ overhead A hardware interrupt is a process with an extremely high priority, and the interrupted process must interrupt the process and save the intermediate process in memory.
  • packet reception processing (protocol processing, etc.) is interrupted by hardIRQs taking up CPU time, resulting in a decrease in packet reception processing efficiency. The relationship between the packet arrival speed and the packet reception speed will be described below.
  • FIG. 5 is a graph showing the relationship between the packet arrival speed (Packets per second) and the number of hardIRQs (Number of hardIRQs), which indicates how many packets arrive per second. ⁇ When the packet arrival frequency is “sparse” (see the short two-way arrow in the middle of Fig. 5) As shown in the lower left of FIG. 5, the speed at which packets are accumulated in the Ring Buffer 72 (see white arrow t in FIG. 5) and the speed at which packets are received from the Ring Buffer 72 one packet at a time (see white arrow u in FIG. 5). are equal (competitive), the frequency of packet arrival is low, so packets do not accumulate in the Ring Buffer 72, and hardIRQ is activated each time a packet arrives.
  • FIG. 6 is a diagram showing a HW interrupt due to packet arrival and a polling thread that is started by the HW interrupt in a comparative example.
  • FIG. 7 is a diagram showing a HW interrupt due to packet arrival and a polling thread that is started by the HW interrupt in this embodiment.
  • " ⁇ " indicates packet arrival
  • " ⁇ " indicates HW interrupt
  • shaded blocks indicate polling status.
  • FIG. 6 when the number of packets arriving is moderate, a large number of HW interrupts occur (see symbol x in FIG.
  • HW interrupts become excessive and delay time increases due to overhead. Note that when packets arrive sparsely or when packets arrive densely, HW interrupts are less likely to occur and the delay time due to overhead is small.
  • the polling thread calculates the HW interrupt frequency f per unit time, and compares the calculated HW interrupt frequency f with a threshold preset by the operator. evaluate. Then, put the polling thread to sleep and introduce logic to decide whether to allow subsequent HW interrupts. Take the case of moderate packet arrival in FIG. 7 as an example. As indicated by symbol y in FIG. 7, the polling thread (intra-server delay control device 100) considers the number of HW interrupts per unit time and controls interrupt prohibition/permission according to the HW interrupt frequency. (See dashed box z in FIG. 7). As a result, excessive HW interrupts are suppressed, and an event in which HW interrupts become excessive and the delay time increases due to overhead is suppressed.
  • FIG. 8 is a flow chart showing NIC and HW interrupt processing of the polling thread (intra-server delay control device 100). While the polling thread is running, this operation flow is looped and executed. This flow starts when a packet arrives at the NIC 11 . In step S1, the NIC 11 copies packet data arrived by DMA (Direct Memory Access) to a memory area.
  • DMA Direct Memory Access
  • step S2 the polling thread (the intra-server delay control device 100) determines whether or not the HW interrupt is permitted. If the HW interrupt is permitted (S2: Yes), the process proceeds to step S3, and if the HW interrupt is not permitted (S2: No), the processing of this flow ends.
  • step S3 the NIC 11 activates the HW interrupt (hardIRQ) by raising the hardIRQ 81 (handler) to activate the HW interrupt, and registers packet arrival information (NIC device information, etc.) in the receive list 186.
  • FIG. if the polling thread (in-server delay control device 100) is sleeping, the NIC 11 wakes up the polling thread and terminates the processing of this flow.
  • FIG. 9 is a flowchart showing the HW interrupt frequency control process of the polling thread (the intra-server delay control device 100).
  • the polling thread When the polling thread is sleeping, a packet arrives and is woken up by a HW interrupt to start this flow.
  • the HW interrupt frequency control unit 150 prohibits HW interrupts by the NIC 11 . If an HW interrupt occurs during processing, the processing will be interrupted.
  • step S12 the CPU frequency/CPU idle setting unit 140 sets the CPU frequency of the CPU core on which the polling thread operates to a high value, and cancels the idle state if the corresponding CPU is in the idle state.
  • step S13 the HW interrupt frequency control unit 150 records the time stamp of the occurrence of the HW interrupt in the HW interrupt count management table 150a.
  • the polling thread refers to the receive list 186 in step S14.
  • the polling thread knows from which device the HW interrupt has occurred, and confirms packet arrival information in the receive list 186 in the next step S15.
  • the Ring Buffer 72 may be directly referenced to confirm whether or not a packet has arrived.
  • NAPI implemented in the Linux kernel monitors a Control Plane list called poll_list.
  • step S15 the packet arrival monitoring unit 110 determines whether or not there is packet arrival information in the receive list 186.
  • S15: No When there is no packet arrival information in the receive list 186 (S15: No), that is, when there is no packet to be processed, the following processing is skipped and the process proceeds to step S20.
  • step S16 the polling thread refers to the packet data from the ring buffer 72 and transfers the data to the subsequent protocol processing section 74.
  • the polling thread refers to the packet data from the ring buffer 72 and transfers the data to the subsequent protocol processing section 74.
  • the polling thread may be received and processed collectively.
  • the packet harvesting unit 120 determines whether or not there is an unreceived packet in the ring buffer 72. If there is an unreceived packet in the ring buffer 72 (S17: Yes), the process returns to step S16.
  • the HW interrupt frequency control unit 150 refers to the HW interrupt frequency management table 150a and determines the HW interrupt frequency f per unit time. calculate.
  • the HW interrupt frequency management table 150a records time stamps of occurrence of HW interrupts.
  • the HW interrupt frequency control unit 150 calculates the HW interrupt frequency f per unit time based on the number of time stamps recorded in the HW interrupt frequency management table 150a. By the way, by repeating the polling loop while the HW interrupt is prohibited, the HW interrupt frequency f becomes smaller each time it is calculated.
  • step S19 the HW interrupt frequency control unit 150 determines whether the HW interrupt frequency f is smaller than the threshold set by the operator. If the HW interrupt frequency f is greater than or equal to the threshold (for example, two or more HW interrupts in 50 ⁇ s) (S19: No), the process proceeds to step S24. Note that the determination based on the HW interrupt frequency f may be determined dynamically by learning according to the characteristics of the inflow traffic, instead of using a fixed threshold set by the operator.
  • HW interrupt frequency f is smaller than the threshold set by the operator (S19: Yes), proceed to sleep control from step S20 onwards. If the HW interrupt frequency f is smaller than the threshold, it corresponds to the "sparse" packet arrival shown in FIG.
  • step S20 the CPU frequency/CPU idle setting unit 140 sets the CPU frequency of the CPU core on which the polling thread operates to be low, and puts the corresponding CPU in the idle state.
  • step S ⁇ b>21 the packet arrival monitoring unit 110 deletes the NIC information from the receive list 186 .
  • the HW interrupt frequency control unit 150 permits the HW interrupt by the corresponding NIC.
  • the sleep management unit 130 puts the polling thread to sleep and terminates the processing of this flow.
  • step S24 If the HW interrupt frequency f is equal to or greater than the threshold, it corresponds to the case of "medium" packet arrival shown in FIG.
  • step S24 the polling thread is put to sleep for a predetermined period of time (for example, after a predetermined period of time t has elapsed), and the process proceeds to step S16.
  • the sleeping time is shortened by causing the polling thread to sleep after a certain time t has elapsed.
  • HW interrupts have a long delay, it is more efficient to give a grace period before going to sleep, considering that sleep is caused by HW interrupts every time.
  • the constant time t may be zero. If the fixed time t is set to zero, the excessive HW interrupt suppression effect of this embodiment cannot be obtained, but the flow of FIG. 9 can always be executed. That is, if the constant time t is set to zero, the effect is substantially the same as when this system is not applied. This eliminates the process of determining whether to execute the flow of FIG. 9 or not. In other words, since it is enough to change the setting of t, it can be implemented universally without modifying the existing system.
  • t is called a fixed time, but t is not limited to a fixed time, and may be a variable time (predetermined time).
  • t may be determined by learning from the input traffic characteristics, or the value of t may be increased little by little each time the loop of the flow in FIG. 9 is repeated (for example, every 1 ⁇ s). If the value of t is gradually increased, when the HW interrupt frequency f is equal to or higher than the threshold value, the time until sleep can be increased according to the current state of arrival of the bucket, and excessive HW interrupt suppression can be achieved. can be implemented.
  • FIG. 10 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the intra-server delay control device 100.
  • Computer 900 has CPU 901 , ROM 902 , RAM 903 , HDD 904 , communication interface (I/F) 906 , input/output interface (I/F) 905 , and media interface (I/F) 907 .
  • the CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls each part of the intra-server delay control device 100 shown in FIGS.
  • 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.
  • the CPU 901 controls an input device 910 such as a mouse and keyboard, and an output device 911 such as a display via an input/output I/F 905 .
  • the CPU 901 acquires data from the input device 910 and outputs the generated data to the output device 911 via the input/output I/F 905 .
  • a GPU Graphics Processing Unit
  • a GPU may be used together with the CPU 901 as a processor.
  • the HDD 904 stores programs executed by the CPU 901 and data used by the programs.
  • Communication I/F 906 receives data from other devices via a communication network (for example, NW (Network) 920) and outputs it to CPU 901, and transmits data generated by CPU 901 to other devices via the communication network. Send to device.
  • NW Network
  • the media I/F 907 reads programs or data stored in the recording medium 912 and outputs them to the CPU 901 via the RAM 903 .
  • the CPU 901 loads a program related to target processing from the recording medium 912 onto the RAM 903 via the media I/F 907, and executes the loaded program.
  • the recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductor memory tape medium, a semiconductor memory, or the like. is.
  • the CPU 901 of the computer 900 executes a program loaded on the RAM 903 to execute the intra-server delay control device. 100 functions are realized. Data in the RAM 903 is stored in the HDD 904 .
  • the CPU 901 reads a program related to target processing from the recording medium 912 and executes it. In addition, the CPU 901 may read a program related to target processing from another device via the communication network (NW 920).
  • intra-server delay control device 100 Like the polling thread (intra-server delay control device 100) shown in FIG. 2, it can be applied to an intra-server delay control device that launches a thread for monitoring packet arrival using a polling model in the Kernel.
  • the OS is not limited.
  • the intra-server delay control system 1000 can be applied to each configuration shown in FIGS. 11 and 12. FIG.
  • FIG. 11 is a diagram showing an example in which the intra-server delay control system 1000A is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration.
  • the same components as those in FIG. 1 are denoted by the same reference numerals.
  • the server delay control device 100 is arranged in the Kernel 171 of the Guest OS 70 and the server delay control device 100 is arranged in the Kernel 91 of the Host OS 90 .
  • the server includes a Host OS 90 on which a virtual machine and an external process formed outside the virtual machine can operate, and a Guest OS 70 that operates within the virtual machine.
  • HostOS90 is a memory space in a server that includes Kernel91 and HostOS90.
  • Ring Buffer 22 managed by Kernel91 and net device information indicating which device the hardware interrupt (hardIRQ) from NIC11 belongs to are registered.
  • receive list 186 (FIG. 2)
  • a vhost-net module 221 that is a kernel thread
  • a tap device 222 that is a virtual interface created by the kernel 91
  • the Kernel 91 includes an intra-server delay control device 100 . Kernel 91 transmits the packet to virtual machine 30 via tap device 222 .
  • the GuestOS 70 is a memory space in the server equipped with the Kernel 171 and the GuestOS 70.
  • the Kernel 171 includes the intra-server delay control device 100 and a protocol processing unit 74 that performs protocol processing on pruned packets. Kernel 171 transfers the packet to packet processing APL 1 via protocol processing unit 74 .
  • packet transfer can be performed with a small delay in the server without modifying the APL in either the HostOS 90 or the GuestOS 70.
  • FIG. 12 is a diagram showing an example in which the intra-server delay control system 1000B is applied to an interrupt model in a container-configured server virtualization environment.
  • the intra-server delay control system 1000B has a container configuration with a Guest OS 180 and a Container 210 instead of the OS.
  • Container 210 has vNIC (virtual NIC) 211 .
  • the intra-server delay control device 100 is arranged in the Kernel 181 of the Guest OS 180 .
  • the present invention can be applied to systems with non-virtualized configurations such as bare metal configurations.
  • packet transfer can be performed with reduced delay in the server without modifying the APL.
  • a sleep unit 120 that sleeps a polling thread if no packet arrives for a predetermined period of time, and wakes the polling thread by a hardware interrupt (hardIRQ) when a packet arrives.
  • a management unit 130 a HW interrupt count storage unit (HW interrupt count management table 150a) that stores the number of hardware interrupts, a HW interrupt frequency that is calculated based on the number of hardware interrupts, and the calculated HW and an HW interrupt frequency control unit 150 that controls HW interrupt permission or prohibition by sleep of the sleep management unit 130 based on the interrupt frequency.
  • HW interrupt count management table 150a that stores the number of hardware interrupts, a HW interrupt frequency that is calculated based on the number of hardware interrupts, and the calculated HW and an HW interrupt frequency control unit 150 that controls HW interrupt permission or prohibition by sleep of the sleep management unit 130 based on the interrupt frequency.
  • the server delay control device 100 stops the packet processing software interrupt (softIRQ), which is the main cause of NW delay, and the packet arrival monitoring unit 110 of the server delay control device 100 A thread that monitors arrival is executed, and the packet harvesting unit 120 performs packet processing according to the polling model (without softIRQ) when a packet arrives. Then, the sleep management unit 130 puts the polling thread to sleep when the packet does not arrive for a predetermined period of time, so that the polling thread sleeps when the packet does not arrive. The sleep management unit 130 cancels sleep by a hardware interrupt (hardIRQ) when a packet arrives.
  • softIRQ packet processing software interrupt
  • the HW interrupt frequency control unit 150 calculates the HW interrupt frequency based on the HW interrupt count stored in the HW interrupt count storage unit (HW interrupt count management table 150a), and calculates the calculated HW interrupt frequency. HW interrupt permission or prohibition by sleep of the sleep management unit 130 is controlled based on the frequency. This provides the following effects (1) to (4).
  • the intra-server delay control system 1000 implements a polling model instead of an interrupt model that is the main cause of NW delays, unlike the existing technology NAPI.
  • the polling thread in the server delay control device 100 operates as a kernel thread and monitors packet arrival in polling mode.
  • a kernel thread (polling thread) that monitors packet arrivals sleeps while no packets arrive. When no packet arrives, the CPU is not used by sleep, so power saving can be achieved.
  • sleep release is characterized in that it is not triggered by a timer that has a timer, but by a hardIRQ handler. If the traffic load is known in advance, for example, if 30 mssleep is known like the workload transfer rate shown in FIG. 15, the hardIRQ handler may wake up at this timing.
  • the present invention can be applied when there is a polling thread inside the kernel like NAPI or KBP.
  • the server delay control device 100 achieves both low delay and power saving by managing the sleep of the polling thread that performs packet transfer processing. be able to. Furthermore, when a predetermined condition such as the packet arrival speed and the packet reception speed being equal to each other is satisfied, it is possible to prevent an increase in packet transfer delay time due to an increase in the number of HW interrupts due to packet arrival. .
  • an intra-server delay control device 100 (see FIGS. 1 and 3) that is placed in the user space and launches a thread that monitors packet arrival using a polling model, and an interface unit ( A packet arrival monitoring unit 110 that monitors a poll list (receive list 186) that registers net device information indicating which device the hardware interrupt (hardIRQ) from the NIC 11 belongs to, and a packet arrival monitoring unit 110 If so, a packet reaping unit 120 that refers to the packet held in the ring buffer (Ring Buffer 72) and performs reaping to delete the corresponding queue entry from the ring buffer based on the next process; a sleep management unit 130 that puts a polling thread to sleep when a packet does not arrive for a predetermined period of time, and wakes the polling thread by a hardware interrupt (hardIRQ) when a packet arrives; A HW interrupt frequency storage unit (HW interrupt frequency management table 150a) that stores the number of hardware interrupts, and a HW interrupt frequency is calculated based on the hardware interrupt frequency, and a
  • the intra-server delay control device 100 performs sleep management of the polling thread that performs packet transfer processing when there is a polling thread in the user space like DPDK. It is possible to achieve both low delay and power saving. Furthermore, when a predetermined condition such as the packet arrival speed and the packet reception speed being equal to each other is satisfied, it is possible to suppress an increase in the delay time due to the excessive occurrence of HW interrupts, thereby further reducing the delay. can be achieved.
  • the Guest OS (Guest OS 70) running in the virtual machine is a kernel (Kernel 171), a ring buffer (Ring Buffer 72) managed by the kernel in a memory space in a server equipped with the Guest OS, and an interface (NIC 11).
  • a poll list (poll_list 186) for registering net device information indicating which device the hardware interrupt (hardIRQ) belongs to; and has an intra-server delay controller 100 in the kernel that launches a thread that monitors packet arrivals using a polling model, and the intra-server delay controller 100 polls the poll list.
  • packet arrival monitoring unit 110 and if a packet has arrived, refer to the packet held in the ring buffer and delete the corresponding queue entry from the ring buffer based on the next process.
  • Harvesting unit 120 puts the polling thread to sleep when a packet does not arrive for a predetermined period of time, and wakes the polling thread from sleep by a hardware interrupt (hardIRQ) when a packet arrives.
  • the HW interrupt frequency is calculated based on the sleep management unit 130, the HW interrupt frequency storage unit (HW interrupt frequency management table 150a) that stores the hardware interrupt frequency, and the hardware interrupt frequency. and an HW interrupt frequency control unit 150 for controlling HW interrupt permission or prohibition due to sleep of the sleep management unit 130 based on the HW interrupt frequency.
  • a server equipped with a Guest OS can reduce the power consumption, reduce the delay in the server without modifying the APL, and perform packet processing. Transfers can be made. Furthermore, when a predetermined condition such as the packet arrival speed and the packet reception speed being equal to each other is satisfied, it is possible to suppress an increase in the delay time due to the excessive occurrence of HW interrupts, thereby further reducing the delay. can be achieved.
  • the host OS in which the virtual machine and the external process formed outside the virtual machine can operate, uses the kernel (Kernel 91) and a ring buffer (Ring Buffer 22), a poll list (poll_list 186) for registering net device information indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC 11) belongs to, and the kernel (Kernel 91). and a tap device 222, which is a virtual interface. refers to the packet arrival monitoring unit 110 that monitors the poll list, and if a packet has arrived, refers to the packet held in the ring buffer (Ring Buffer 72).
  • a packet reaping unit 120 that performs reaping to delete the entry of the ring buffer (Ring Buffer 72), and if a packet does not arrive for a predetermined period of time, the thread (polling thread) is put to sleep, and when a packet arrives, this thread (polling thread) hardware interrupt (hardIRQ) sleep management unit 130, the HW interrupt frequency is calculated based on the number of hardware interrupts, sleep based on the calculated HW interrupt frequency and an HW interrupt frequency control unit 150 that controls HW interrupt permission or prohibition by sleep of the management unit 130 .
  • this thread (polling thread) hardware interrupt (hardIRQ) sleep management unit 130 the HW interrupt frequency is calculated based on the number of hardware interrupts, sleep based on the calculated HW interrupt frequency and an HW interrupt frequency control unit 150 that controls HW interrupt permission or prohibition by sleep of the management unit 130 .
  • a server comprising a kernel (Kernel 171) and a host OS (HostOS 90) can reduce power consumption, and without modifying the APL, Packet transfer can be performed with a small delay. Furthermore, when a predetermined condition such as the packet arrival speed and the packet reception speed being equal to each other is satisfied, it is possible to suppress an increase in the delay time due to the excessive occurrence of HW interrupts, thereby further reducing the delay. can be achieved.
  • the HW interrupt frequency control unit 150 compares the calculated HW interrupt frequency with a predetermined threshold, and if the HW interrupt frequency is smaller than the predetermined threshold, the sleep management unit 130 causes sleep. It is characterized by not executing for a certain period of time.
  • the interface unit activates an interrupt handler (hardIRQ 81) for a hardware interrupt to register a device in the poll list. Stop scheduling.
  • softIRQ contention can be avoided by stopping the softIRQ that is the cause of delays, and instead performing packet processing in the context of the high priority hardIRQ with timer triggers.
  • the intra-server delay control device 100 is provided with a CPU frequency setting unit (CPU frequency/CPU idle setting unit 140) that sets the CPU operating frequency of the CPU core used by the thread low during sleep.
  • CPU frequency setting unit 140 sets the CPU operating frequency of the CPU core used by the thread low during sleep.
  • the intra-server delay control device 100 dynamically changes the CPU operating frequency according to the traffic. , the effect of power saving can be enhanced.
  • the intra-server delay control device 100 includes a CPU idle setting unit (CPU frequency/CPU idle setting unit 140) that sets the CPU idle state of the CPU core used by the thread to the power saving mode during sleep. .
  • CPU idle setting unit CPU frequency/CPU idle setting unit 140
  • the intra-server delay control device 100 dynamically changes the CPU idle state (power saving function according to the CPU model, such as changing the operating voltage) according to the traffic, thereby further saving power. Power efficiency can be enhanced.
  • each of the above configurations, functions, processing units, processing means, etc. may be realized in hardware, for example, by designing a part or all of them with an integrated circuit.
  • each configuration, function, etc. described above may be realized by software for a processor to interpret and execute a program for realizing each function.
  • Information such as programs, tables, files, etc. that realize each function is stored in memory, hard disk, SSD (Solid State Drive) and other recording devices, IC (Integrated Circuit) cards, SD (Secure Digital) cards, optical discs, etc. It can be held on a recording medium.
  • Packet processing APL application
  • 10HW 11 NIC physical NIC (interface part)
  • Guest OS protocol processor
  • 60 user space 72 Ring Buffer
  • Host OS OS
  • 91,171,181 Kernel 100 server delay controller (polling thread)
  • packet arrival monitoring unit 120 packet harvesting unit 130 sleep management unit
  • CPU frequency/CPU idle setting unit 150
  • HW interrupt frequency control unit 150a HW interrupt count management table (HW interrupt count storage unit)
  • Guest OS OS 186 receive list 210 Container 1000, 1000A, 1000B In-server delay control system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

サーバ内遅延制御装置（１００）は、パケットが所定期間到着しない場合はスレッドをスリープさせ、かつ、パケット到着時はハードウェア割込によりこのスレッドのスリープ解除を行うsleep管理部（１３０）と、ハードウェア割込回数を記憶するＨＷ割込回数管理テーブル（１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部（１３０）のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部（１５０）と、を備える。

Description

サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
　本発明は、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラムに関する。
　ＮＦＶ（Network Functions Virtualization：ネットワーク機能仮想化）による仮想化技術の進展などを背景に、サービス毎にシステムを構築して運用することが行われている。また、上記サービス毎にシステムを構築する形態から、サービス機能を再利用可能なモジュール単位に分割し、独立した仮想マシン（ＶＭ：Virtual Machineやコンテナなど）環境の上で動作させることで、部品のようにして必要に応じて利用し運用性を高めるといったＳＦＣ（Service Function Chaining）と呼ばれる形態が主流となりつつある。
　仮想マシンを構成する技術としてLinux（登録商標）とＫＶＭ（kernel-based virtual machine）で構成されたハイパーバイザー環境が知られている。この環境では、ＫＶＭモジュールが組み込まれたHost OS（物理サーバ上にインストールされたＯＳをHost OSと呼ぶ）がハイパーバイザーとしてカーネル空間と呼ばれるユーザ空間とは異なるメモリ領域で動作する。この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にGuest OS（仮想マシン上にインストールされたＯＳをGuest OSと呼ぶ）が動作する。
　Guest OSが動作する仮想マシンは、Host OSが動作する物理サーバとは異なり、（イーサーネットカードデバイスなどに代表される）ネットワークデバイスを含むすべてのＨＷ（hardware）が、ＨＷからGuest OSへの割込処理やGuest OSからハードウェアへの書き込みに必要なレジスタ制御となる。このようなレジスタ制御では、本来物理ハードウェアが実行すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がHost OS環境に比べ、低いことが一般的である。
　この性能劣化において、特にGuest OSから自仮想マシン外に存在するHost OSや外部プロセスに対して、ＨＷの模倣を削減し、高速かつ統一的なインターフェイスにより通信の性能と汎用性を向上させる技術がある。この技術として、virtioというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにLinux（登録商標）を始め、FreeBSD（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている。
　virtioでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換をキューのオペレーションにより定義している。そして、virtioのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをGuest OS起動時に用意することにより、Guest OSと自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。
［ポーリングモデルによるパケット転送（DPDKの例）］
　複数の仮想マシンを接続、連携させる手法はInter-VM Communicationと呼ばれ、データセンタなどの大規模な環境では、ＶＭ間の接続に、仮想スイッチが標準的に利用されてきた。しかし、通信の遅延が大きい手法であることから、より高速な手法が新たに提案されている。例えば、SR-IOV（Single Root I/O Virtualization）と呼ばれる特別なハードウェアを用いる手法や、高速パケット処理ライブラリであるIntel DPDK（Intel Data Plane Development Kit）（以下、ＤＰＤＫという）を用いたソフトウェアによる手法などが提案されている。
　ＤＰＤＫは、従来Linux kernel（登録商標）が行っていたＮＩＣ（Network Interface Card）の制御をユーザ空間で行うためのフレームワークである。Linux kernelにおける処理との最大の違いは、ＰＭＤ（Pull Mode Driver）と呼ばれるポーリングベースの受信機構を持つことである。通常、Linux kernelでは、ＮＩＣへのデータの到達を受けて、割込が発生し、それを契機に受信処理が実行される。一方、ＰＭＤは、データ到達の確認や受信処理を専用のスレッドが継続的に行う。コンテキストスイッチや割込などのオーバーヘッドを排除することで高速なパケット処理を行うことができる。ＤＰＤＫは、パケット処理のパフォーマンスとスループットを大幅に高めて、データプレーン・アプリケーション処理に多くの時間を確保することを可能にする。
　ＤＰＤＫは、ＣＰＵ（Central Processing Unit）やＮＩＣなどのコンピュータ資源を占有的に使用する。このため、ＳＦＣのようにモジュール単位で柔軟につなぎ替える用途には適用しづらい。これを緩和するためのアプリケーションであるＳＰＰ（Soft Patch Panel）がある。ＳＰＰは、ＶＭ間に共有メモリを用意し、各ＶＭが同じメモリ空間を直接参照できる構成にすることで、仮想化層でのパケットコピーを省略する。また、物理ＮＩＣと共有メモリ間のパケットのやり取りには、ＤＰＤＫを用いて高速化を実現する。ＳＰＰは、各ＶＭのメモリ交換の参照先を制御することで、パケットの入力先、出力先をソフトウェア的に変更することができる。この処理によって、ＳＰＰは、ＶＭ間やＶＭと物理ＮＩＣ間の動的な接続切替を実現する。
［New API(NAPI)によるＲｘ側パケット処理］
　図１３は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である（非特許文献１参照）。
　図１３に示すように、New API(NAPI)は、OS７０（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なUser space６０に配置されたパケット処理ＡＰＬ１を実行し、OS７０に接続されたＨＷ１０のＮＩＣ１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
　OS７０は、kernel７１、Ring Buffer７２、およびDriver７３を有し、kernel７１は、プロトコル処理部７４を有する。
　Kernel７１は、OS７０（例えば、Host OS）の基幹部分の機能であり、ハードウェアの監視やプログラムの実行状態をプロセス単位で管理する。ここでは、kernel７１は、パケット処理ＡＰＬ１からの要求に応えるとともに、ＨＷ１０からの要求をパケット処理ＡＰＬ１に伝える。Kernel７１は、パケット処理ＡＰＬ１からの要求に対して、システムコール（「非特権モードで動作しているユーザプログラム」が「特権モードで動作しているカーネル」に処理を依頼）を介することで処理する。
　Kernel７１は、Socket７５を介して、パケット処理ＡＰＬ１へパケットを伝達する。Kernel７１は、Socket７５を介してパケット処理ＡＰＬ１からパケットを受信する。
　Ring Buffer７２は、Kernel７１が管理し、サーバ中のメモリ空間にある。Ring Buffer７２は、Kernel７１が出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。
　Driver７３は、kernel７１でハードウェアの監視を行うためデバイスドライバである。なお、Driver７３は、kernel７１に依存し、作成された（ビルドされた）カーネルソースが変われば、別物になる。この場合、該当ドライバ・ソースを入手し、ドライバを使用するOS上で再ビルドし、ドライバを作成することになる。
　プロトコル処理部７４は、ＯＳＩ（Open Systems Interconnection）参照モデルが定義するＬ２（データリンク層）／Ｌ３（ネットワーク層）／Ｌ４（トランスポート層）のプロトコル処理を行う。
　Socket７５は、kernel７１がプロセス間通信を行うためのインターフェイスである。Socket７５は、ソケットバッファを有し、データのコピー処理を頻繁に発生させない。Socket７５を介しての通信確立までの流れは、下記の通りである。1.サーバ側がクライアントを受け付けるソケットファイルを作成する。2.受付用ソケットファイルに名前をつける。3.ソケット・キューを作成する。4.ソケット・キューに入っているクライアントからの接続の最初の1つを受け付ける。5.クライアント側ではソケットファイルを作成する。6.クライアント側からサーバへ接続要求を出す。7.サーバ側で、受付用ソケットファイルとは別に、接続用ソケットファイルを作成する。通信確立の結果、パケット処理ＡＰＬ１は、kernel７１に対してread()やwrite()などのシステムコールを呼び出せるようになる。
　以上の構成において、Kernel７１は、NIC１１からのパケット到着の知らせを、ハードウェア割込（hardIRQ）により受け取り、パケット処理のためのソフトウェア割込（softIRQ）をスケジューリングする。
　上記、Linux kernel 2.5/2.6より実装されているNew API(NAPI)は、パケットが到着するとハードウェア割込（hardIRQ）の後、ソフトウェア割込（softIRQ）により、パケット処理を行う。図１３に示すように、割込モデルによるパケット転送は、割込処理（図１３の符号ａ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
　以下、NAPI Rx側パケット処理概要について説明する。
［New API(NAPI)によるＲｘ側パケット処理構成］
　図１４は、図１３の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。
 <Device driver>
　図１４に示すように、Device driverには、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、およびソフトウェア割込の処理機能部であるnetif_rx８２が配置される。
 <Networking layer>
　Networking layerには、netif_rx８２の処理要求の発生によって呼び出され要求された処理（ソフトウェア割込）を実行するハンドラであるsoftIRQ８３、ソフトウェア割込（softIRQ）の実体を行う制御機能部であるdo_softirq８４が配置される。また、ソフトウェア割込（softIRQ）を受けて実行するパケット処理機能部であるnet_rx_action８５、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を登録するpoll_list８６、sk_buff構造体（Kernel７１が、パケットがどうなっているかを知覚できるようにするための構造体）を作成するnetif_receive_skb８７、Ring Buffer７２が配置される。
 <Protocol layer>
　Protocol layerには、パケット処理機能部であるip_rcv８８、arp_rcv８９等が配置される。
　上記netif_rx８２、do_softirq８４、net_rx_action８５、netif_receive_skb８７、ip_rcv８８、およびarp_rcv８９は、Kernel７１の中でパケット処理のために用いられるプログラムの部品（関数の名称）である。
［New API(NAPI)によるＲｘ側パケット処理動作］
　図１４の矢印（符号）ｂ～ｍは、Ｒｘ側パケット処理の流れを示している。
　NIC１１のhardware機能部１１ａ（以下、NIC１１という）が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ（Direct Memory Access）転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１４の符号ｂ参照）。このRing Buffer７２は、サーバの中にあるメモリ空間で、Kernel７１（図１３参照）が管理している。
　しかし、NIC１１が、Ring Buffer７２へ到着したパケットをコピーしただけでは、Kernel７１は、そのパケットを認知できない。そこで、NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１に上げ（図１４の符号ｃ参照）、netif_rx８２が下記の処理を実行することで、Kernel７１は、当該パケットを認知する。なお、図１４の楕円で囲んで示すhardIRQ８１は、機能部ではなくハンドラを表記する。
　netif_rx８２は、実際に処理をする機能であり、hardIRQ８１（ハンドラ）が立ち上がると（図１４の符号ｄ参照）、poll_list８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存する。そして、netif_rx８２は、キューの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）を登録する（図１４の符号ｅ参照）。具体的には、netif_rx８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをpoll_list８６に登録する（図１４の符号ｅ参照）。これにより、poll_list８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取り情報が登録される。
　このように、図１４の<Device driver>において、NIC１１は、パケットを受信すると、ＤＭＡ転送によりRing Buffer７２へ到着したパケットをコピーする。また、NIC１１は、hardIRQ８１（ハンドラ）を上げ、netif_rx８２は、poll_list８６にnet_deviceを登録し、ソフトウェア割込（softIRQ）をスケジューリングする。
　ここまでで、図１４の<Device driver>におけるハードウェア割込の処理は停止する。
　その後、netif_rx８２は、poll_list８６に積まれているキューに入っている情報（具体的にはポインタ）を用いて、Ring Buffer７２に格納されているデータを刈取ることを、ソフトウェア割込（softIRQ）でsoftIRQ８３（ハンドラ）に上げ（図１４の符号ｆ参照）、ソフトウェア割込の制御機能部であるdo_softirq８４に通知する（図１４の符号ｇ参照）。
　do_softirq８４は、ソフトウェア割込制御機能部であり、ソフトウェア割込の各機能を定義（パケット処理は各種あり、割込処理はそのうちの一つ。割込処理を定義する）している。do_softirq８４は、この定義をもとに、実際にソフトウェア割込処理を行うnet_rx_action８５に、今回の（該当の）ソフトウェア割込の依頼を通知する（図１４の符号ｈ参照）。
　net_rx_action８５は、softIRQの順番がまわってくると、poll_list８６に登録されたnet_deviceをもとに（図１４の符号ｉ参照）、Ring Buffer７２からパケットを刈取るためのポーリングルーチンを呼び出し、パケットを刈取る（図１４の符号ｊ参照）。このとき、net_rx_action８５は、poll_list８６が空になるまで刈取りを続ける。
　その後、net_rx_action８５は、netif_receive_skb８７に通達をする（図１４の符号ｋ参照）。
　netif_receive_skb８７は、sk_buff構造体を作り、パケットの内容を解析し、タイプ毎に後段のプロトコル処理部７４（図１３参照）へ処理をまわす。すなわち、netif_receive_skb８７は、パケットの中身を解析し、パケットの中身に応じて処理をする場合には、<Protocol layer>のip_rcv８８に処理を回し（図１４の符号ｌ）、また、例えばＬ２であればarp_rcv８９に処理をまわす（図１４の符号ｍ）。
　特許文献１には、サーバ内ネットワーク遅延制御装置（ＫＢＰ：Kernel Busy Poll）が記載されている。ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視する。これにより、softIRQを抑止し、低遅延なパケット処理を実現する。
国際公開第２０２１／１３０８２８号
New API(NAPI), ［online］,［令和４年１月１１日検索］,インターネット 〈 URL : http:// http://lwn.net/2002/0321/a/napi-howto.php3〉
　しかしながら、割込モデルとポーリングモデルによるパケット転送のいずれについても下記課題がある。
　割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。
　例えば、割込モデルによるパケット転送は、割込処理によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
　割込モデルにおいて、遅延が発生するメカニズムについて補足する。
　一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
　パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、前記ソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
　上記条件では、前記ソフトウェア割込処理を即時に実行することができない。
　また、New API(NAPI)によるパケット処理についても同様に、図１４の破線囲みｎに示すように、割込処理（softIRQ）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。
　一方、特許文献１に記載の技術を用いると、パケット到着を常時監視することにより、ソフトウェア割込を抑止し、低遅延なパケット刈取を実現できる。しかしながら、パケット到着を監視するため、ＣＰＵコアを専有しＣＰＵタイムを使用するため、消費電力が高くなる。すなわち、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が大きくなる課題がある。図１５および図１６を参照して、ワークロードとＣＰＵ使用率の関係について説明する。
　図１５は、映像（３０ＦＰＳ）のデータ転送例である。図１５に示すワークロードは、転送レート３５０Ｍｂｐｓで、３０ｍｓごとに間欠的にデータ転送を行っている。
　図１６は、特許文献１に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
　図１６に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図１５に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
　このような背景を鑑みて本発明がなされたのであり、本発明は、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制し、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことを課題とする。
　前記した課題を解決するため、サーバ内遅延制御装置であって、OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備えることを特徴とするサーバ内遅延制御装置とした。
　本発明によれば、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制し、消費電力の低減を図りつつ、サーバ内の遅延を小さくしてパケット転送を行うことができる。
本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。 図１のpolling thread（サーバ内遅延制御装置）をkernel spaceに配置した構成例である。 図１のpolling thread（サーバ内遅延制御装置）をUser spaceに配置した構成例である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のpolling thread動作例を示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのパケット到着速度とhardIRQ回数の関係を表わすグラフである。 比較例のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。 パケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのpolling thread（サーバ内遅延制御装置）のＮＩＣおよびＨＷ割込処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のＨＷ割込頻度制御処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システムを適用した例を示す図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。 図１３の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。 映像（３０ＦＰＳ）のデータ転送例を示す図である。 特許文献１に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内遅延制御システム等について説明する。
［概要］
　図１は、本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。本実施形態は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理に適用した例である。図１３と同一構成部分には、同一符号を付している。
　図１に示すように、サーバ内遅延制御システム１０００は、OS（例えば、Host OS）を備えるサーバ上で、ユーザが使用可能なUser spaceに配置されたパケット処理ＡＰＬ１を実行し、OSに接続されたＨＷのNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
　サーバ内遅延制御システム１０００は、ネットワークインターフェースカードであるNIC１１（物理NIC）、NIC１１の処理要求の発生によって呼び出され要求された処理（ハードウェア割込）を実行するハンドラであるhardIRQ８１、ＨＷ割込の処理機能部であるＨＷ割込処理部１８２、receive list１８６、Ring_Buffer７２、polling thread（サーバ内遅延制御装置１００）と、プロトコル処理部７４と、を備える。
　Ring Buffer７２は、サーバの中にあるメモリ空間においてkernelが管理する。Ring Buffer７２は、kernelが出力するメッセージをログとして格納する一定サイズのバッファであり、上限サイズを超過すると先頭から上書きされる。
　プロトコル処理部７４は、Ethernet，IP，TCP/UDP等である。プロトコル処理部７４は、例えばＯＳＩ参照モデルが定義するＬ２／Ｌ３／Ｌ４のプロトコル処理を行う。
 <サーバ内遅延制御装置>
　サーバ内遅延制御装置１００は、kernel space またはUser spaceのいずれかに配置されるpolling threadである。
　サーバ内遅延制御装置１００は、パケット到着監視部１１０と、パケット刈取部１２０と、sleep管理部１３０と、CPU周波数/CPU idle設定部１４０と、ＨＷ割込回数管理テーブル１５０ａ（ＨＷ割込回数記憶部）を有するＨＷ割込頻度制御部１５０と、を備える。
　パケット到着監視部１１０は、パケットが到着していないかを監視するためのthreadである。パケット到着監視部１１０は、receive list１８６を監視（polling）する。
　パケット到着監視部１１０は、receive list１８６からRing_Buffer７２にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する。ここで、receive list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。
　パケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをRing Buffer７２から削除する刈取りを実行する（以下、単にRing Buffer７２からパケットを刈取るという場合がある）。パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、プロトコル処理部７４へパケットを伝達する。
　パケット刈取部１２０は、Ring_Buffer７２に複数のパケットが貯まっているときは、複数パケットをまとめて刈り取って、後続のプロトコル処理部７４へ渡す。なお、このまとめて刈り取る数をquotaと言い、バッチ処理という呼び方をすることも多い。プロトコル処理部７４は、プロトコル処理も複数パケットをまとめて処理するので高速である。
　sleep管理部１３０は、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行う（詳細後記）。
　CPU周波数/CPU idle設定部１４０は、スリープ中に、スレッド（polling thread）が使用するＣＰＵコアのＣＰＵ動作周波数を低く設定する。CPU周波数/CPU idle設定部１４０は、スリープ中に、このスレッド（polling thread）が使用するＣＰＵコアのＣＰＵアイドル（CPU idle）状態を省電力モードに設定する（詳細後記）。
　ＨＷ割込頻度制御部１５０は、ＨＷ割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御する。具体的には、ＨＷ割込頻度制御部１５０は、算出したＨＷ割込頻度と所定閾値とを比較し、当該ＨＷ割込頻度が所定閾値より小さい場合、sleep管理部１３０によるスリープを一定時間実行させない（詳細後記）。
　ＨＷ割込回数管理テーブル１５０ａは、ＨＷ割込回数として、ＨＷ割込が発生したタイムスタンプ（ＨＷ割込がいつ発生したかを示すタイムスタンプ）を記憶する。ＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａに記憶したタイムスタンプの回数をもとにＨＷ割込回数を算出する。
 <サーバ内遅延制御装置の配置>
　図２および図３は、図１のpolling thread（サーバ内遅延制御装置１００）の配置を説明する図である。
・polling threadのkernel space配置
　図２は、図１のpolling thread（サーバ内遅延制御装置１００）をkernel spaceに配置した構成例である。
　図２に示すサーバ内遅延制御システム１０００は、kernel spaceにpolling thread（サーバ内遅延制御装置１００）、プロトコル処理部７４が配置される。このpolling thread（サーバ内遅延制御装置１００）は、kernel space内で動作する。サーバ内遅延制御システム１０００は、OSを備えるサーバ上で、User spaceに配置されたパケット処理ＡＰＬ１を実行し、OSに接続されたDevice driverを介してＨＷのNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
　なお、図２に示すように、Device driverには、hardIRQ８１、ＨＷ割込処理部１８２、receive list１８６、Ring_Buffer７２が配置される。
　Device driverは、ハードウェアの監視を行うためのドライバである。
　本発明を、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合に適用することができる。
・polling threadのUser space配置
　図３は、図１のpolling thread（サーバ内遅延制御装置１００）をUser spaceに配置した構成例である。
　図３に示すサーバ内遅延制御システム１０００は、User spaceにpolling thread（サーバ内遅延制御装置１００）、プロトコル処理部７４が配置される。このpolling thread（サーバ内遅延制御装置１００）は、Kernel space内ではなく、User spaceで動作する。
　図３に示すサーバ内遅延制御システム１０００は、polling thread（サーバ内遅延制御装置１００）が、kernel spaceをバイパスして、Device driverおよびNIC１１とパケット処理ＡＰＬ１との間でパケット転送を行う。
　本発明を、ＤＰＤＫのように、user spaceにpolling threadがある場合に適用することができる。
　以下、サーバ内遅延制御システム１０００の動作を説明する。
［本発明によるＲｘ側パケット処理動作］
　図１～図３の矢印（符号）ａａ～ｊｊは、Ｒｘ側パケット処理の流れを示している。
　NIC１１が、対向装置からフレーム内にパケット（またはフレーム）を受信すると、ＤＭＡ転送によりＣＰＵを使用せずに、Ring Buffer７２へ到着したパケットをコピーする（図１～図３の符号ａａ参照）。このRing Buffer７２は、<Device driver>で管理している。
　NIC１１は、パケットが到着すると、ハードウェア割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げ（図１～図３の符号ｂｂ参照）、ＨＷ割込処理部１８２が下記の処理を実行することで、当該パケットを認知する。
　ＨＷ割込処理部１８２は、hardwire８１（ハンドラ）が立ち上がると（図１～図３の符号ｃｃ参照）、receive list１８６に、ハードウェア割込（hardIRQ）の中身の情報の１つである、ＮＩＣ１１からのハードウェア割込がどのデバイスのものであるかを示すネットデバイス（net_device）の情報を保存して、キューの刈取り情報を登録する。具体的には、ＨＷ割込処理部１８２は、Ring Buffer７２にパケットが詰め込まれたことを受けて、NIC１１のドライバを使って、以後のキューの刈取りをreceive list１８６に登録する（図１～図３の符号ｄｄ参照）。これにより、receive list１８６には、Ring Buffer７２にパケットが詰め込まれたことによる、キューの刈取りが登録される。
　ＨＷ割込処理部１８２は、receive list１８６にnet_deviceを登録するが、図１４のnetif_rx８２とは異なり、ソフトウェア割込（softIRQ）のスケジューリングは行わない。すなわち、ＨＷ割込処理部１８２は、ソフトウェア割込（softIRQ）のスケジューリングは行わない点で、図１４のnetif_rx８２とは異なる。
　また、ＨＷ割込処理部１８２は、sleepしているpolling threadを呼び起こすsleep解除を行う（図１～図３の符号ｅｅ参照）。
　ここまでで、図１～図３の<Device driver>におけるハードウェア割込の処理は停止する。
　本実施形態では、図１４に示す<Networking layer>において、softIRQ８３およびdo_softirq８４が削除され、これに伴い、図１４に示すnetif_rx８２が、softIRQ８３（ハンドラ）を立ち上げる通知（図１４の符号ｆ参照）も行わない。
　本実施形態では、サーバ内遅延制御システム１０００は、図１４に示すsoftIRQ８３およびdo_softirq８４を削除し、代わりに<kernel space>にpolling thread（サーバ内遅延制御装置１００）設ける（図２参照）。あるいは、サーバ内遅延制御システム１０００は、<User space>にpolling thread（サーバ内遅延制御装置１００）設ける（図３参照）。
　図２に示す<kernel space>または図３に示す<User space>において、サーバ内遅延制御装置１００のＨＷ割込頻度制御部１５０は、ＨＷ割込頻度を管理し、ＨＷ割込頻度に応じて、polling threadのsleepやＨＷ割込許可／禁止を制御する（図１～図３の符号ｆｆ参照）。
　パケット到着監視部１１０は、receive list１８６を監視（polling）し（図１～図３の符号ｇｇ参照）、パケット到着有無を確認する。
　パケット到着監視部１１０は、receive list１８６から、Ring_Buffer７２にパケットが存在するポインタ情報と、net_device情報とを取得し、パケット刈取部１２０へ当該情報（ポインタ情報およびnet_device情報）を伝達する（図１～図３の符号ｈｈ参照）。ここで、receive list１８６に複数パケット情報が存在する場合は、複数分当該情報を伝達する。
　サーバ内遅延制御装置１００のパケット刈取部１２０は、パケットが到着している場合は、Ring Buffer７２からパケットを刈取る（図１～図３の符号ｉｉ参照）。
　パケット刈取部１２０は、受信した情報をもとにRing_Buffer７２からパケットを取り出し、プロトコル処理部７４へパケットを伝達する（図１～図３の符号ｊｊ参照）。
［polling threadのsleep動作］
　サーバ内遅延制御システム１０００は、ＮＷ遅延発生の主要因であるパケット処理のsoftIRQを停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するpolling threadを実行する。そして、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。
　パケット到着時は、ハード割込ハンドラでpolling threadを起こすことで、softIRQ競合を回避して、即時にパケット転送処理が可能となる。言い換えれば、パケット到着監視機能を待機させておき、ハード割込で起こすことで、NAPI等のソフト割込によるパケット転送処理よりも低遅延化が可能になる。
　パケット到着を監視するpolling thread（サーバ内遅延制御装置１００）は、パケット到着がない間はsleep可能とする。
　polling thread（サーバ内遅延制御装置１００）は、パケット到着有無に応じてsleepし、パケット到着時はhardIRQ８１によりsleep解除を行う。具体的には、サーバ内遅延制御装置１００のsleep管理部１３０は、パケット到着有無に応じて、すなわち所定期間パケットの到着がないと、polling threadをsleepさせる。sleep管理部１３０は、パケット到着時はhardIRQ８１によりsleep解除を行う。これにより、softIRQ競合を回避して、低遅延化を実現する。
　サーバ内遅延制御装置１００のCPU周波数/CPU idle設定部１４０は、パケット到着有無に応じてＣＰＵ動作周波数やidle設定を変更する。具体的には、CPU周波数/CPU idle設定部１４０は、sleep時はＣＰＵ周波数を下げ、再度起動時はＣＰＵ周波数を高める（ＣＰＵ動作周波数をもとに戻す）。また、CPU周波数/CPU idle設定部１４０は、sleep時はCPU idle設定を省電力に変更する。sleep時にＣＰＵ動作周波数を低く変更する、また、CPU idle設定を省電力に変更することで省電力化も達成する。
　図４は、サーバ内遅延制御装置１００のpolling thread動作例を示す図である。縦軸は、polling threadが使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。なお、図４は、図１５に示す間欠的にパケットが受信される映像（３０ＦＰＳ）のデータ転送例に対応するパケット到着によるpolling thread動作例を示している。
　図４に示すように、サーバ内遅延制御装置１００のsleep管理部１３０は、所定期間パケットの到着がない場合（より詳細には、あるパケット到着してから、保守・運用者があらかじめ定めた固定値（一定期間）を経過しても次のパケット到着がない場合）に、polling threadをsleepさせる（図４の符号ｐ参照）。そして、sleep管理部１３０は、パケット到着のhardIRQ８１でpolling threadを起動させる（図４の符号ｑ参照）。
　なお、sleep 時には、kernelthreadがＣＰＵコアを専有していないため、polling threadが使用する以外にも、システム安定動作のためのタイマの割込みが該当ＣＰＵコアに入ったり、エラー処理等のためのmigration threadが該当ＣＰＵコアに入ったりすることで、polling threadが使用するＣＰＵコアのＣＰＵ使用率が変動する場合がある（図４の符号ｒ参照）。
［パケット到着速度とパケット受信速度の関係］
　上述したように、polling thread（サーバ内遅延制御装置１００）は、Ring Buffer７２に未受信のパケットがある場合は、ハードウェア割込要求（hardIRQ）を禁止しpollingによるパケット受信を行う。
　ここで、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たすと、パケット到着によるhardIRQ回数が多くなり、hardIRQオーバーヘッドにより、パケット転送遅延時間と消費電力が増大する場合がある。hardIRQオーバーヘッドについて述べる。ハードウェア割込は極めて高い優先度の処理であり、割り込まれたプロセスは処理を中断して、途中処理をメモリに退避する必要がある。hardIRQ回数が増えると、パケット受信処理（プロトコル処理等）がhardIRQにCPUタイムを奪われて中断されるため、パケット受信処理効率が下がってしまう。以下、パケット到着速度とパケット受信速度の関係について説明する。
　図５は、パケットが１秒間にどけだけ到着するかを示すパケット到着速度（Packets per second）とhardIRQ回数（Number of hardIRQ）の関係を表わすグラフである。
・パケット到着頻度が低い「疎」の場合（図５の中段に示す短い双方向矢印参照）
　図５の下図左に示すように、Ring Buffer７２にパケットが貯まる速度（図５の白抜き矢印ｔ参照）と、Ring Buffer７２から１パケットずつパケットを受信する速度（図５の白抜き矢印ｕ参照）とが同等である（拮抗している）場合、パケット到着頻度が低いため、Ring Buffer７２にパケットが貯まらず、パケット到着の度にhardIRQが発動される。
・パケット到着頻度が高い「密」の場合（図５の中段に示す長い双方向矢印参照）
　図５の下図右に示すように、Ring Buffer７２にパケットが貯まる速度（図５の白抜き矢印ｖ参照）が大きく、Ring Buffer７２からある程度貯まったらバッチ処理で複数受信する速度（図５の白抜き矢印ｗ参照）が小さい場合、パケット到着頻度が高く、Ring Buffer７２にパケットが貯まるため、hardIRQ禁止時間が長く、hardIRQ回数は小さくなる。
　図５の上図の破線楕円囲みｓに示すように、パケット到着速度とパケット受信速度が所定の条件を満たす際に、hardIRQ回数が多くなり、遅延時間と電力消費を増大させる。上記パケット到着速度とパケット受信速度が所定の条件を満たす場合は、図５の下図左に示すパケットが貯まる速度とパケットを受信する速度とが同等である場合である。パケット到着頻度が低いため、Ring Buffer７２にパケットが貯まらず、パケット到着の度にhardIRQが発動され、遅延時間と電力消費を増大させる。
［パケット到着頻度の補足説明］
　パケット到着頻度について補足して説明する。
　パケット到着頻度が低い状態は、それだけsleepできるチャンスが多く省電力効果が期待できる。
　ところが、パケット到着頻度がそこそこ低く、しかしハードウェア割込は都度発生してしまうような、Sleepと起床を繰り返す場合、パケット到着の度にhardIRQが発動され、遅延時間が増大させる。
　本実施形態は、パケット到着速度とパケット受信速度が拮抗するような状況において、polling threadをsleepさせることによるＨＷ割込の過剰な発生を抑制する技術を提供する。
［polling thread（サーバ内遅延制御装置１００）動作の基本的な考え方］
　図６および図７を参照して、polling thread（サーバ内遅延制御装置１００）動作の基本的な考え方について説明する。図６は、比較例のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。図７は、本実施形態のパケット到着によるＨＷ割込と、ＨＷ割込で立ち上がるpolling threadを示す図である。図中、「●」はパケット到着を示し、「↑」はＨＷ割込を示し、網掛けブロックはpolling状態を示す。
　図６の比較例において、パケット到着が中程度の場合、ＨＷ割込が大量に発生し（図６の符号ｘ参照）、大量に発生したＨＷ割込によりpolling threadはpolling状態となる。ＨＷ割込が過剰になり、オーバーヘッドによる遅延時間が増加する。なお、パケット到着が疎の場合やパケット到着が密の場合には、ＨＷ割込の発生が少なく、オーバーヘッドによる遅延時間は小さい。
　そこで、本実施形態では、polling thread（サーバ内遅延制御装置１００）が、単一時間当たりのＨＷ割込頻度ｆを計算し、計算したＨＷ割込頻度ｆを運用者が予め設定した閾値と比較評価する。そして、polling threadをsleepさせ、後続のＨＷ割込を許可してよいか判断するロジックを導入する。図７のパケット到着が中程度の場合を例にとる。図７の符号ｙに示すように、polling thread（サーバ内遅延制御装置１００）は、単一時間当たりのＨＷ割込回数を考慮し、ＨＷ割込頻度に応じて割込禁止／許可を制御する（図７の破線囲みｚ参照）。これにより、過度なＨＷ割込を抑止し、ＨＷ割込が過剰になり、オーバーヘッドによる遅延時間の増加する事象を抑制する。
［polling thread（サーバ内遅延制御装置１００）の動作フロー］
　図８は、polling thread（サーバ内遅延制御装置１００）のＮＩＣおよびＨＷ割込処理を示すフローチャートである。
　polling threadが起動している間は、本動作フローをループして実行する。
　NIC１１にパケットが到着すると、本フローがスタートする。ステップＳ１でNIC１１は、DMA(Direct Memory Access)により到着したパケットデータをメモリ領域へコピーする。
　ステップＳ２でpolling thread（サーバ内遅延制御装置１００）は、ＨＷ割込が許可されているか否かを判別する。ＨＷ割込が許可されている場合（Ｓ２：Ｙｅｓ）、ステップＳ３に進み、ＨＷ割込が許可されていない場合（Ｓ２：Ｎｏ）には本フローの処理を終了する。
　ステップＳ３でNIC１１は、ＨＷ割込（hardIRQ）をhardIRQ８１（ハンドラ）に立ち上げてＨＷ割込を起動し、receive list１８６にパケット到着情報（ＮＩＣデバイス情報等）を登録する。
　ステップＳ４でNIC１１は、polling thread（サーバ内遅延制御装置１００）がsleepしている場合、polling threadを起こして本フローの処理を終了する。
　図９は、polling thread（サーバ内遅延制御装置１００）のＨＷ割込頻度制御処理を示すフローチャートである。
　polling threadがsleepしているときに、パケットが到着し、ＨＷ割込により起こされ、本フローがスタートする。
　ステップＳ１１でＨＷ割込頻度制御部１５０は、NIC１１によるＨＷ割込を禁止する。処理している最中にＨＷ割込されると、処理が中断されてしまうので、ＨＷ割込頻度制御部１５０は、NIC１１によるＨＷ割込を一旦禁止する。
　ステップＳ１２でCPU周波数/CPU idle設定部１４０は、polling threadが動作するＣＰＵコアのCPU周波数を高く設定し、該当ＣＰＵをidle stateにしていた場合はidle stateを解除する。
　ステップＳ１３でＨＷ割込頻度制御部１５０は、ＨＷ割込が発生したタイムスタンプを、ＨＷ割込回数管理テーブル１５０ａに記録する。
　ステップＳ１４でpolling threadは、receive list１８６を参照する。polling threadは、どこのデバイスからＨＷ割込が起ったかを知り、次のステップＳ１５でreceive list１８６のパケット到着情報を確認する。
　なお、receive list１８６というControl Planeのlistを参照するのではなく、直接Ring Buffer７２を参照し、パケットの到着有無を確認してもよい。例えば、Linux kernelに実装されたNAPIでは、poll_listというControl Planeのlistを監視する。
　ステップＳ１５でパケット到着監視部１１０は、receive list１８６にパケット到着情報が存在するか否かを判別する。receive list１８６にパケット到着情報が存在しない場合（Ｓ１５：Ｎｏ）、すなわち、処理すべきパケットがない場合には、以下の処理をスキップしてステップＳ２０に進む。
　receive list１８６にパケット到着情報が存在する場合（Ｓ１５：Ｙｅｓ）、ステップＳ１６でpolling threadは、ring buffer７２からパケットデータを参照し、該当データを後続のプロトコル処理部７４へ転送する。ここで、複数のデータがある時は、一括で受信処理してもよい。
　ステップＳ１７でパケット刈取部１２０は、ring buffer７２に未受信のパケットが存在する否かを判別する。ring buffer７２に未受信のパケットが存在する場合（Ｓ１７：Ｙｅｓ）、上記ステップＳ１６に戻る。
　ring buffer７２に未受信のパケットが存在しない場合（Ｓ１７：Ｎｏ）、ステップＳ１８でＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａを参照し、単位時間当たりのＨＷ割込頻度ｆを計算する。ＨＷ割込回数管理テーブル１５０ａには、ＨＷ割込が発生したタイムスタンプが記録されている。ＨＷ割込頻度制御部１５０は、ＨＷ割込回数管理テーブル１５０ａに記録されたタイムスタンプの回数をもとに、単位時間当たりのＨＷ割込頻度ｆを計算する。
　ちなみに、ＨＷ割込を禁止している間にpollingループを回すことで、計算する毎にＨＷ割込頻度ｆは小さくなる。
　ステップＳ１９でＨＷ割込頻度制御部１５０は、ＨＷ割込頻度ｆが、運用者が設定した閾値よりも小さいか否かを判別する。ＨＷ割込頻度ｆが閾値以上（例えば、５０μｓでＨＷ割込が２回以上）の場合（Ｓ１９：Ｎｏ）、ステップＳ２４に進む。
　なお、ＨＷ割込頻度ｆによる判定は、運用者が設定する固定的な閾値でなく、流入トラヒックの特徴に応じて学習して動的に閾値を決定してもよい。
　ＨＷ割込頻度ｆが、運用者が設定した閾値よりも小さい場合（Ｓ１９：Ｙｅｓ）、ステップＳ２０以降のsleep制御に進む。ＨＷ割込頻度ｆが閾値よりも小さい場合は、図７に示すパケット到着が「疎」のときに該当する。
　ステップＳ２０でCPU周波数/CPU idle設定部１４０は、polling threadが動作するＣＰＵコアのCPU周波数を低く設定し、該当ＣＰＵをidle stateにする。
　ステップＳ２１でパケット到着監視部１１０は、receive list１８６から該当ＮＩＣ情報を削除する。
　ステップＳ２２でＨＷ割込頻度制御部１５０は、該当NICによるＨＷ割込を許可する。
　ステップＳ２３でsleep管理部１３０は、polling threadをsleepさせて本フローの処理を終了する。
　一方、上記ステップＳ１９でＨＷ割込頻度ｆが閾値以上の場合、ステップＳ２４に進む。ＨＷ割込頻度ｆが閾値以上の場合は、図７に示すパケット到着が「中」のときに該当し、ステップＳ２４の実行結果は、図７の破線囲みｚに示す割込禁止に対応する。
　ステップＳ２４で所定時間（例えば、一定時間ｔの経過後）polling threadをsleepさせて、ステップＳ１６に進む。
　上記一定時間ｔの間polling threadをsleepさせることについて説明する。図７のパケット到着が「中」の事例で述べたように、ＨＷ割込頻度ｆが閾値以上の場合は、polling threadをsleepしたとしても直ぐに、パケットが到着し、ＨＷ割込により起こされる。すなわち、polling threadでsleepしていなかったのであれば、ＨＷ割込により起こされることがなかった事象が発生し、過剰なＨＷ割込が生じる。そこで、本実施形態では、ＨＷ割込頻度ｆが閾値以上の場合、一定時間ｔが経過してから、polling threadをsleepさせる。換言すれば、本来、polling threadをsleepする条件になったとしてもＨＷ割込頻度ｆが閾値以上の場合は、sleepするまでに時間を置く（一定時間ｔが経過するまで待ってからsleepする）。これにより、図７に示すパケット到着が「中」のときのように、パケット到着速度とパケット受信速度が一定の条件を満たす場合（パケットがRing Buffer７２に貯まる速度とパケットを受信する速度とが同等である場合）に、過剰なＨＷ割込を抑制することができる。
　ここで、本来はsleepしていた場合に、一定時間ｔ経過後polling threadをsleepさせることで、sleepする時間が短くなる。しかしながら、ＨＷ割込は、遅延が大きいので、毎回、sleepからＨＷ割込により起こされることを考慮すれば、sleepに入るまでに猶予を持たせることの方がトータルの効率はよい。
　なお、一定時間ｔは、ゼロでもよい。一定時間ｔをゼロにすると、本実施形態が有する過剰なＨＷ割込の抑制効果は得られないものの、図９のフローを常に実行しておくことができる。すなわち、一定時間ｔをゼロにすると、本システムを適用しない場合と事実上同等の効果となる。これにより、図９のフローを実行する／実行しないの判断処理が不要となる。つまり、ｔの設定を変えるだけで済むので、既存のシステムを改変することなく、汎用的に実施が可能である。
　また、説明の便宜上、上記ｔを一定時間と呼称したが、ｔは一定時間に限らず、可変時間（所定時間）であってもよい。例えば、入力されるトラヒック特性から学習してｔを決定してもよいし、図９のフローのループを繰り返す毎（例えば、１μｓ毎）にｔの値を少しずつ増やしていってもよい。ｔの値を少しずつ増やす態様を採ると、ＨＷ割込頻度ｆが閾値以上の場合において、バケット到着の現況に合わせてsleepするまでの時間をより大きくすることができ、過剰なＨＷ割込抑制の実効を図ることができる。
　ちなみに、図９のsleep制御のフローを実行することによる遅延時間の悪化は、本発明者らの実測によれば、平均数マイクロ秒程度の遅延時間の悪化にとどまることが確認されており、ハードウェア割込による起床程度の単体で見れば小さなオーバーヘッドである。
　なお、図７のパケット到着が「中」の場合に効果を発揮する例について説明したが、図７のパケット到着が「密」の場合も同様に、sleepしてhardIRQで起床させる機会がある。このため、パケット到着が「密」の場合もhardIRQの頻度制御による本発明の効果が期待できる。
［ハードウェア構成］
　上記実施形態に係るサーバ内遅延制御装置１００は、例えば図１０に示すような構成のコンピュータ９００によって実現される。
　図１０は、サーバ内遅延制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
　コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。
　ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１乃至図３に示すサーバ内遅延制御装置１００の各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
　例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内遅延制御装置１００として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内遅延制御装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
［適用例］
　図２に示すpolling thread（サーバ内遅延制御装置１００）のように、Kernel内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置に適用できる。この場合、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内遅延制御システム１０００は、図１１および図１２に示す各構成に適用が可能である。
 <ＶＭ構成への適用例>
　図１１は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ａを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
　図１１に示すように、サーバ内遅延制御システム１０００Ａは、Guest OS７０のKernel１７１内にサーバ内遅延制御装置１００が配置され、Host OS９０のKernel９１内にサーバ内遅延制御装置１００が配置される。
　詳細には、サーバは、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS９０と、仮想マシン内で動作するGuest OS７０と、を備える。
　HostOS９０は、Kernel９１と、HostOS９０を備えるサーバ中のメモリ空間で、Kernel９１が管理するRing Buffer２２と、NIC11からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するreceive list１８６（図２）と、kernel threadであるvhost-netモジュール２２１と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２と、仮想スイッチ(br)２２３と、を有する。
　Kernel９１は、サーバ内遅延制御装置１００を備える。
　Kernel９１は、tapデバイス２２２を介して、仮想マシン３０へパケットを伝達する。
　一方、GuestOS７０は、Kernel１７１と、GuestOS７０を備えるサーバ中のメモリ空間で、Kernel１７１が管理するRing Buffer５２と、NIC１１からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するreceive list１８６（図２）と、Kernel１７１が、プロセス間通信を行うためのインターフェイスであるSocket７５と、を備える。
　Kernel１７１は、サーバ内遅延制御装置１００と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を備える。
　Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOS９０とGuestOS７０とのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <コンテナ構成への適用例>
　図１２は、コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内遅延制御システム１０００Ｂを適用した例を示す図である。図１と同一構成部分には、同一符号を付している。
　図１２に示すように、サーバ内遅延制御システム１０００Ｂは、Guest OS１８０と、OSをContainer２１０に代えた、コンテナ構成を備える。Container２１０は、vNIC（仮想NIC）２１１を有する。Guest OS１８０のKernel１８１内にサーバ内遅延制御装置１００が配置される。
　コンテナなどの仮想サーバ構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <ベアメタル構成（非仮想化構成）への適用例>
　本発明は、ベアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <スケールイン／アウト>
　トラヒック量が多く、複数のNICデバイスやNICポートを使用する場合に、これらと関連付けて複数のpolling threadを動作させることで、ＨＷ割込頻度制御を行いつつ、polling threadをスケールイン／アウトすることができる。
 <拡張技術>
　本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラフィックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。
［効果］
　以上説明したように、OSのカーネル空間（kernel space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図２参照）であって、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（receive list１８６）を監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）によりこのスレッド（polling thread）のスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備える。
　このようにすることで、サーバ内遅延制御装置１００は、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内遅延制御装置１００のパケット到着監視部１１０がパケット到着を監視するthreadを実行し、パケット刈取部１２０が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。そして、sleep管理部１３０が、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させることで、スレッド（polling thread）はパケット未到着時にsleepする。sleep管理部１３０は、パケット到着時はハードウェア割込（hardIRQ）によりスリープ解除を行う。さらに、ＨＷ割込頻度制御部１５０は、ＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）に記憶したＨＷ割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープ（sleep）による、ＨＷ割込許可または禁止を制御する。
　これにより、下記（１）～（４）の効果を奏する。
　（１）遅延発生の原因となるパケット到着時のソフトウェア割込（softIRQ）を停止し、カーネル（Kernel１７１）内でpollingモデルを実現する。すなわち、サーバ内遅延制御システム１０００は、既存技術のNAPIと異なり、ＮＷ遅延の主要因となる割込モデルではなく、pollingモデルを実現する。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる。
　（２）サーバ内遅延制御装置１００におけるpolling threadは、kernel threadとして動作し、pollingモードでパケット到着を監視している。パケット到着を監視するkernel thread（polling thread）は、パケット到着がない間はsleepする。パケット到着がない場合は、sleepによってＣＰＵを使用しないので、省電力の効果を得ることができる。
　そして、パケット到着時には、sleep中のpolling threadは、パケット到着時のhardIRQハンドラで起こされる（sleep解除される）。hardIRQハンドラでsleep解除されることで、softIRQ競合を回避しながら、polling threadを即時起動させることができる。ここで、sleep解除は、タイマを持っていてこのタイマにより起こすものではなく、hardIRQハンドラで起こす点に特徴がある。なお、あらかじめトラヒックロードが分かっている場合、例えば図１５に示すワークロード転送レートのように３０ｍｓsleepが分かっている場合は、このタイミング合わせてhardIRQハンドラで起こすようにしてもよい。
　（３）さらに、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御する。これにより、polling threadをsleepさせることによるオーバーヘッドの一つであるＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。
　（４）本発明を、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合に適用することができる。
　このように、サーバ内遅延制御装置１００（図２参照）は、kernel内部にpolling threadがある場合において、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、パケット到着によるＨＷ割込回数が多くなり、パケット転送遅延時間が増大することを未然に防ぐことができる。
　また、ユーザ空間（User space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図３参照）であって、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（receive list１８６）を監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）によりこのスレッド（polling thread）のスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備える。
　このようにすることで、サーバ内遅延制御装置１００（図３参照）は、ＤＰＤＫのように、user spaceにpolling threadがある場合において、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。
　また、仮想マシン内で動作するGuest OS（GuestOS７０）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数を記憶するＨＷ割込回数記憶部（ＨＷ割込回数管理テーブル１５０ａ）と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備えることを特徴とする。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（GuestOS７０）を備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。
　また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS（HostOS９０）が、カーネル（Kernel９１）と、Host OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer２２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list１８６）と、カーネル（Kernel９１）により作成される仮想インターフェイスであるtapデバイス２２２と、を備え、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、ポールリストを監視（polling）するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファ（Ring Buffer７２）から削除する刈取りを実行するパケット刈取部１２０と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep管理部１３０と、ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出したＨＷ割込頻度に基づいてsleep管理部１３０のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部１５０と、を備えることを特徴とする。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel１７１）とHost OS（HostOS９０）とを備えるサーバについて、消費電力の低減を図りつつ、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。さらに、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。
　サーバ内遅延制御装置１００において、ＨＷ割込頻度制御部１５０は、算出したＨＷ割込頻度と所定閾値とを比較し、このＨＷ割込頻度が所定閾値より小さい場合、sleep管理部１３０によるスリープを一定時間実行させないことを特徴とする。
　このようにすることにより、パケット到着速度とパケット受信速度が同等である等の所定の条件を満たした場合に、ＨＷ割込が過剰に発生することによる遅延時間の増加を抑制することができ、より一層低遅延を達成することができる。
 <その他の効果>
　サーバ内遅延制御装置１００を含むサーバ内遅延制御システムにおいて、インターフェイス部（NIC１１）は、ハードウェア割込を割込ハンドラ（hardIRQ８１）に立ち上げてポールリストにデバイスを登録する場合、ソフトウェア割込によるスケジューリングを停止する。
　このようにすることにより、遅延発生要因となるsoftIRQを停止し、その代わり、タイマ契機で、高い優先度であるhardIRQのコンテキストでパケット処理を行うことで、softIRQ競合を回避することができる。
　本実施形態では、サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数設定部（CPU周波数/CPU idle設定部１４０）を備える。
　このように、サーバ内遅延制御装置１００は、ＣＰＵ動作周波数をトラヒックに合わせて動的に変動させる、すなわち、スリープによりＣＰＵを使わないのであれば、スリープ中におけるＣＰＵ動作周波数を低く設定することで、より省電力の効果を高めることができる。
　本実施形態では、サーバ内遅延制御装置１００において、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部（CPU周波数/CPU idle設定部１４０）を備える。
　このようにすることにより、サーバ内遅延制御装置１００は、CPU idle状態（動作電圧を変更するなど、ＣＰＵ機種に応じた省電力機能）をトラヒックに合わせて動的に変動させることで、より省電力の効果を高めることができる。
　なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
　１　パケット処理ＡＰＬ（アプリケーション）
　１０　ＨＷ
　１１　NIC（物理NIC）(インターフェイス部)
　７０　Guest OS
　７４　プロトコル処理部
　６０　user space（ユーザスペース）
　７２　Ring Buffer（リングバッファ）
　９０　Host OS（OS）
　９１，１７１，１８１　Kernel（カーネル）
　１００　サーバ内遅延制御装置（polling thread）
　１１０　パケット到着監視部
　１２０　パケット刈取部
　１３０　sleep管理部
　１４０　CPU周波数/CPU idle設定部
　１５０　ＨＷ割込頻度制御部
　１５０ａ　ＨＷ割込回数管理テーブル（ＨＷ割込回数記憶部）
　１８０　Guest OS（OS）
　１８６　receive list（ポールリスト）
　２１０　Container
　１０００，１０００Ａ，１０００Ｂ　サーバ内遅延制御システム

Claims (7)

  1. 　OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
    　ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
    　前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  2. 　ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
    　ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
    　前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  3. 　サーバ内遅延制御装置であって、
    　仮想マシン内で動作するGuest OSが、
    　カーネルと、
    　前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
    　刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
    　前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
    　前記サーバ内遅延制御装置は、
    　前記ポールリストによりパケット到着を監視するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
    　ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
    　前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  4. 　サーバ内遅延制御装置であって、
    　仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
    　カーネルと、
    　前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
    　前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
    　前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
    　前記サーバ内遅延制御装置は、
    　前記ポールリストによりパケット到着を監視するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、
    　ハードウェア割込回数を記憶するＨＷ割込回数記憶部と、
    　前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理部のスリープによる、ＨＷ割込許可または禁止を制御するＨＷ割込頻度制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  5. 　前記ＨＷ割込頻度制御部は、算出した前記ＨＷ割込頻度と所定閾値とを比較し、当該ＨＷ割込頻度が所定閾値より小さい場合、前記スリープ管理部によるスリープを一定時間実行させない
    　ことを特徴とする請求項１乃至４のいずれか一項に記載のサーバ内遅延制御装置。
  6. 　OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置のサーバ内遅延制御方法であって、
    　前記サーバ内遅延制御装置は、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視するステップと、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するステップと、
    　パケットが所定期間到着しない場合は前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理ステップと、
    　ハードウェア割込回数を記憶するステップと、
    　前記ハードウェア割込回数をもとにＨＷ割込頻度を算出し、算出した前記ＨＷ割込頻度に基づいて前記スリープ管理ステップのスリープによる、ＨＷ割込許可または禁止を制御するステップと、を実行する
    　ことを特徴とするサーバ内遅延制御方法。
  7. 　コンピュータを、請求項１乃至５のいずれか１項に記載のサーバ内遅延制御装置として機能させるためのプログラム。
PCT/JP2022/002637 2022-01-25 2022-01-25 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム WO2023144878A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/002637 WO2023144878A1 (ja) 2022-01-25 2022-01-25 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/002637 WO2023144878A1 (ja) 2022-01-25 2022-01-25 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2023144878A1 true WO2023144878A1 (ja) 2023-08-03

Family

ID=87471135

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/002637 WO2023144878A1 (ja) 2022-01-25 2022-01-25 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Country Status (1)

Country Link
WO (1) WO2023144878A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009060530A1 (ja) * 2007-11-09 2009-05-14 Fujitsu Limited ネットワーク処理制御装置，プログラムおよび方法
JP2015036991A (ja) * 2013-08-14 2015-02-23 インテル コーポレイション 待ち時間低減パケット処理を備えたソケット管理
JP2015197874A (ja) * 2014-04-03 2015-11-09 日本電信電話株式会社 仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009060530A1 (ja) * 2007-11-09 2009-05-14 Fujitsu Limited ネットワーク処理制御装置，プログラムおよび方法
JP2015036991A (ja) * 2013-08-14 2015-02-23 インテル コーポレイション 待ち時間低減パケット処理を備えたソケット管理
JP2015197874A (ja) * 2014-04-03 2015-11-09 日本電信電話株式会社 仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラム

Similar Documents

Publication Publication Date Title
JP7310924B2 (ja) サーバ内遅延制御装置、サーバ、サーバ内遅延制御方法およびプログラム
US5903752A (en) Method and apparatus for embedding a real-time multi-tasking kernel in a non-real-time operating system
US7996593B2 (en) Interrupt handling using simultaneous multi-threading
US5875329A (en) Intelligent batching of distributed messages
US5721922A (en) Embedding a real-time multi-tasking kernel in a non-real-time operating system
TWI512619B (zh) 用於執行緒排程的方法以及系統
US9019826B2 (en) Hierarchical allocation of network bandwidth for quality of service
US20020091826A1 (en) Method and apparatus for interprocessor communication and peripheral sharing
US20210281618A1 (en) System, apparatus, and method for streaming input/output data
US10649914B1 (en) Scratchpad-based operating system for multi-core embedded systems
US8356299B2 (en) Interrupt processing method and system
US20140068165A1 (en) Splitting a real-time thread between the user and kernel space
CN112306652A (zh) 带有上下文提示的功能的唤醒和调度
JP2001282558A (ja) マルチオペレーティング計算機システム
WO2023144878A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP2010134698A (ja) 情報処理システム
WO2023218596A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2022195826A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023144958A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023199519A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023002547A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
JP7251648B2 (ja) サーバ内遅延制御システム、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2024013830A1 (ja) サーバ内データ転送装置、データ転送システム、サーバ内データ転送方法およびプログラム
WO2022172366A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023105578A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22923747

Country of ref document: EP

Kind code of ref document: A1