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

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

Info

Publication number
WO2023218596A1
WO2023218596A1 PCT/JP2022/020051 JP2022020051W WO2023218596A1 WO 2023218596 A1 WO2023218596 A1 WO 2023218596A1 JP 2022020051 W JP2022020051 W JP 2022020051W WO 2023218596 A1 WO2023218596 A1 WO 2023218596A1
Authority
WO
WIPO (PCT)
Prior art keywords
thread
mode
packet
sleep
delay control
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2022/020051
Other languages
English (en)
French (fr)
Inventor
圭 藤本
廣 名取
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to EP22941676.3A priority Critical patent/EP4524737A4/en
Priority to US18/864,727 priority patent/US20250328372A1/en
Priority to PCT/JP2022/020051 priority patent/WO2023218596A1/ja
Priority to JP2024520175A priority patent/JP7754299B2/ja
Priority to CN202280095899.2A priority patent/CN119173855A/zh
Publication of WO2023218596A1 publication Critical patent/WO2023218596A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/103—Active monitoring, e.g. heartbeat, ping or trace-route with adaptive polling, i.e. dynamically adapting the polling rate

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.
  • a Host OS with a built-in KVM module OS installed on a physical server is called a Host OS
  • a hypervisor in a memory area called kernel space that is different from user space.
  • a virtual machine operates in the user space, and a Guest OS (the OS installed on the virtual machine is called a Guest OS) operates within the virtual machine.
  • a virtual machine running a Guest OS is different from a physical server running a Host OS, in that all HW (hardware) including network devices (typified by Ethernet card devices, etc.) are allocated from the HW to the Guest OS.
  • This register control is necessary for processing and writing from the Guest OS to the hardware. With this kind of register control, the notifications and processes that should normally be executed by physical hardware are imitated by software, so performance is generally lower than in the Host OS environment.
  • virtio for data input/output such as console, file input/output, and network communication, data exchange using a queue designed with a ring buffer is defined as a unidirectional transport for transfer data using queue operations.
  • virtio's queue specifications and preparing the number and size of queues suitable for each device at startup of the Guest OS hardware emulation can be used to improve communication between the Guest OS and the outside of the own virtual machine. This can be achieved simply by using queue operations without execution.
  • DPDK is a framework for controlling NIC (Network Interface Card) in user space, which was conventionally performed by Linux kernel (registered trademark).
  • the biggest difference from processing in the Linux kernel is that it has a polling-based reception mechanism called PMD (Pull Mode Driver).
  • PMD Pull Mode Driver
  • PMD Pull Mode Driver
  • PMD a dedicated thread continuously performs data arrival confirmation and reception processing. By eliminating overhead such as context switches and interrupts, high-speed packet processing can be performed.
  • DPDK significantly increases packet processing performance and throughput, allowing more time for data-plane application processing.
  • DPDK exclusively uses computer resources such as the CPU (Central Processing Unit) and NIC. For this reason, it is difficult to apply it to applications such as SFC, where modules are flexibly reconnected.
  • SPP Soft Patch Panel
  • SPP provides a shared memory between VMs and configures each VM to directly reference the same memory space, thereby omitting packet copying in the virtualization layer.
  • DPDK is used to speed up the exchange of packets between the physical NIC and the shared memory.
  • SPP can change the input destination and output destination of packets using software by controlling the reference destination for memory exchange of each VM. Through this processing, SPP realizes dynamic connection switching between VMs and between VMs and physical NICs.
  • FIG. 18 is a schematic diagram of Rx side packet processing using New API (NAPI) implemented in Linux kernel 2.5/2.6 (see Non-Patent Document 1).
  • the New API (NAPI) executes the packet processing APL1 located in the User space 60 that can be used by the user on a server equipped with an OS 70 (for example, Host OS), and connects to the OS 70. Packet transfer is performed between the NIC 11 of the HW 10 and the packet processing APL 1.
  • OS 70 for example, Host OS
  • the OS 70 has a kernel 71, a Ring Buffer 72, and a driver 73, and the kernel 71 has a protocol processing section 74.
  • the Kernel 71 is a core function of the OS 70 (eg, Host OS), and monitors hardware and manages the execution status of programs on a process-by-process basis.
  • the kernel 71 responds to requests from the packet processing APL1 and transmits requests from the HW 10 to the packet processing APL1.
  • Kernel 71 processes requests from packet processing APL 1 through system calls (a "user program running in non-privileged mode" requests processing to "kernel running in privileged mode”). .
  • the Kernel 71 transmits the packet to the packet processing APL 1 via the Socket 75.
  • the Kernel 71 receives packets from the packet processing APL 1 via the Socket 75.
  • the Ring Buffer 72 is managed by the Kernel 71 and is located in the memory space of the server.
  • the Ring Buffer 72 is a 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.
  • Driver 73 is a device driver for monitoring hardware with kernel 71. Note that Driver73 depends on Kernel71, and will be different if the created (built) kernel source changes. In this case, you will need to obtain the relevant 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 perform inter-process communication. Socket 75 has a socket buffer and does not cause data copy processing to occur frequently.
  • the flow up to establishing communication via Socket 75 is as follows. 1.Create a socket file for the server side to accept clients. 2. Name the reception socket file. 3. Create a socket queue. 4.Accept the first connection from a 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.Create a connection socket file on the server side, separate from the reception socket file.
  • the packet processing APL1 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 using a hardware interrupt (hardIRQ), and schedules a software interrupt (softIRQ) for packet processing.
  • the New API (NAPI) which has been implemented since Linux kernel 2.5/2.6, performs packet processing using a hardware interrupt (hardIRQ) and then a software interrupt (softIRQ) when a packet arrives.
  • NPI New API
  • FIG. 18 in packet transfer using the interrupt model, packets are transferred by interrupt processing (see reference numeral a in FIG. 18), so a wait for interrupt processing occurs, resulting in a large delay in packet transfer. .
  • FIG. 19 is a diagram illustrating an overview of Rx side packet processing by New API (NAPI) in the area surrounded by the broken line in FIG. 18.
  • the device driver includes NIC11 (physical NIC) that is a network interface card, hardIRQ81 that is a handler that is called when a processing request for NIC11 occurs and executes the requested processing (hardware interrupt), and netif_rx 82, which is a software interrupt processing function unit.
  • the networking layer includes softIRQ83, which is a handler that is called upon the generation of a netif_rx82 processing request and executes the requested process (software interrupt), and do_softirq84, which is a control function unit that implements the actual software interrupt (softIRQ). Ru.
  • net_rx_action 85 is a packet processing function unit executed in response to a software interrupt (softIRQ)
  • poll_list 86 registers information on a net device (net_device) indicating which device the hardware interrupt from the NIC 11 belongs to.
  • a netif_receive_skb 87 and a Ring Buffer 72 that create a sk_buff structure (a structure that allows the Kernel 71 to recognize the status of packets) are arranged.
  • Protocol layer In the protocol layer, packet processing functional units such as ip_rcv88 and arp_rcv89 are arranged.
  • netif_rx82, do_softirq84, net_rx_action85, netif_receive_skb87, ip_rcv88, and arp_rcv89 are program components (function names) used for packet processing in the Kernel 71.
  • FIG. 19 [Rx side packet processing operation using New API (NAPI)] Arrows (symbols) b to m in FIG. 19 indicate the flow of packet processing on the Rx side.
  • the hardware function unit 11a of the NIC 11 hereinafter referred to as NIC 11
  • the packet arrives at the Ring Buffer 72 without using the CPU through DMA (Direct Memory Access) transfer.
  • DMA Direct Memory Access
  • This Ring Buffer 72 is a memory space within the server, and is managed by the Kernel 71 (see FIG. 18).
  • the Kernel 71 will not be able to recognize the packet. Therefore, when the packet arrives, the NIC 11 raises the hardware interrupt (hardIRQ) to the hardIRQ 81 (see reference numeral c in FIG. 19), and the netif_rx 82 executes the following process, so that the Kernel 71 recognizes the packet.
  • hardIRQ81 shown enclosed in an ellipse in FIG. 19 represents a handler rather than a functional unit.
  • netif_rx82 is a function that actually performs processing, and when hardIRQ81 (handler) starts up (see code d in Figure 19), poll_list86 contains information from NIC11, which is one of the information in the hardware interrupt (hardIRQ). Saves net device (net_device) information that indicates which device the hardware interrupt belongs to. Then, netif_rx82 registers queue reaping (refers to the contents of the packets accumulated in the buffer and deletes the corresponding queue entry from the buffer, taking into account the processing of that packet and the next processing). (See symbol e in FIG. 19). Specifically, in response to packets being packed into the Ring Buffer 72, the netif_rx 82 uses the NIC 11 driver to register future queue reaping in the poll_list 86. As a result, queue reaping information resulting from packets being stuffed into the Ring Buffer 72 is registered in the poll_list 86 .
  • ⁇ Device driver> of FIG. 19 when the NIC 11 receives a packet, it copies the packet that has arrived at the Ring Buffer 72 by DMA transfer. Further, the NIC 11 raises the hardIRQ 81 (handler), the netif_rx 82 registers net_device in the poll_list 86, and schedules a software interrupt (softIRQ). Up to this point, the hardware interrupt processing in ⁇ Device driver> in FIG. 19 is stopped.
  • the netif_rx82 uses a software interrupt (softIRQ) to reap the data stored in the Ring Buffer72 using the information (specifically, the pointer) stored in the queue stored in the poll_list86. (handler) (see reference numeral f in FIG. 19), and notifies the do_softirq 84, which is a software interrupt control function unit (see reference numeral g in FIG. 19).
  • softIRQ software interrupt
  • the do_softirq 84 is a software interrupt control function unit, and defines each software interrupt function (there are various types of packet processing, and interrupt processing is one of them. It defines interrupt processing). 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 reference numeral h in FIG. 19).
  • the net_rx_action 85 calls a polling routine for reaping packets from the Ring Buffer 72 based on the net_device registered in the poll_list 86 (see reference numeral i in FIG. 19), and reaps the packets ( (See symbol j in FIG. 19). At this time, net_rx_action 85 continues reaping until poll_list 86 becomes empty. Thereafter, net_rx_action 85 notifies netif_receive_skb 87 (see symbol k in FIG. 19).
  • the netif_receive_skb 87 creates a sk_buff structure, analyzes the contents of the packet, and sends processing to the subsequent protocol processing unit 74 (see FIG. 18) for each type.
  • netif_receive_skb 87 analyzes the contents of the packet, and when performing processing according to the contents of the packet, passes the processing to ip_rcv 88 of ⁇ Protocol layer> (symbol l in Figure 19).
  • the processing is passed to arp_rcv89 (symbol m in FIG. 19).
  • Patent Document 1 describes an in-server network delay control device (KBP: Kernel Busy Poll). KBP constantly monitors packet arrival using a polling model within the kernel. This suppresses softIRQ and achieves low-latency packet processing.
  • KBP Kernel Busy Poll
  • both the interrupt model and the polling model for packet transfer have the following problems.
  • the kernel receives an event (hardware interrupt) from the HW and transfers the packet through software interrupt processing for processing the packet. Therefore, in the interrupt model, packet transfer is performed by interrupt (software interrupt) processing, so if there is a conflict with other interrupts or if the interrupt destination CPU is being used by a process with a higher priority, waiting This poses the problem of increased packet transfer delay. In this case, if the interrupt processing becomes congested, the waiting delay will further increase.
  • NW delay on the order of ms occurs due to competition in interrupt processing (softIRQ), as shown in the broken line box n in FIG.
  • softIRQ interrupt processing
  • the technology described in Patent Document 1 when the technology described in Patent Document 1 is used, by constantly monitoring packet arrival, software interrupts can be suppressed and packet harvesting with low delay can be realized.
  • the CPU core is occupied and CPU time is used to monitor packet arrival, power consumption is high. That is, the kernel thread that constantly monitors packet arrivals monopolizes the CPU core and constantly uses CPU time, which poses a problem of increased power consumption. The relationship between workload and CPU usage rate will be described with reference to FIGS. 20 and 21.
  • FIG. 20 is an example of video (30 FPS) data transfer.
  • the workload shown in FIG. 20 has a transfer rate of 350 Mbps, and data is transferred intermittently every 30 ms.
  • FIG. 21 is a diagram showing the CPU usage rate used by the busy poll thread in the KBP described in Patent Document 1.
  • the kernel thread exclusively uses the CPU core to perform busy polls. Even with intermittent packet reception as shown in FIG. 20, KBP always uses the CPU regardless of whether or not a packet has arrived, so there is a problem of high power consumption.
  • the present invention was made in view of this background.
  • the present invention suppresses sleep and wake-up operations when the traffic inflow frequency is "dense", achieves low latency, and saves power.
  • the task is to achieve the following.
  • an in-server delay control device that is placed in the kernel space of the OS and starts up a thread that monitors packet arrival using a polling model, and the operation mode of the thread is to put the thread to sleep. It has a sleep control mode that allows the thread to be constantly polled, and a constant busy poll mode that constantly polls the thread, and includes a traffic frequency measurement unit that measures the traffic inflow frequency, and a traffic inflow frequency measured by the traffic frequency measurement unit.
  • This in-server delay control device is characterized by comprising a packet arrival monitoring unit that monitors a poll list that registers information on a network device indicating whether the device belongs to the device, and checks whether or not a packet has arrived.
  • the present invention it is possible to suppress sleep and wake-up operations when the traffic inflow frequency is "dense", thereby achieving low delay and power saving.
  • FIG. 1 is a schematic configuration diagram of an intra-server delay control system according to an embodiment of the present invention. This is a configuration example in which the polling thread (in-server delay control device) of FIG. 1 is placed in kernel space. This is a configuration example in which the polling thread (in-server delay control device) of FIG. 1 is placed in the user space.
  • FIG. 2 is a diagram illustrating the arrangement of a traffic frequency measurement unit of the polling thread (in-server delay control device) of FIG. 1;
  • FIG. 6 is a diagram showing an example of polling thread operation when the traffic inflow frequency of the server delay control device of the server delay control system according to the embodiment of the present invention is “sparse”;
  • FIG. 1 is a schematic configuration diagram of an intra-server delay control system according to an embodiment of the present invention.
  • FIG. 4 is an example of data transfer when the traffic inflow frequency of the intra-server delay control system according to the embodiment of the present invention is "dense.”
  • FIG. 7 is a diagram illustrating an example of polling thread operation in the data transfer example when the traffic inflow frequency is "dense" in FIG. 6; It is a figure explaining the operation mode switching point of the delay control device in a server of the delay control system in a server concerning an embodiment of the present invention.
  • FIG. 3 is a table showing an example of switching determination logic of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
  • 2 is a flowchart showing NIC and HW interrupt processing of the intra-server delay control device of the intra-server delay control system according to the embodiment of the present invention.
  • FIG. 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. 2 is a diagram illustrating an example in which an intra-server delay control system that places a polling thread in the kernel is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration.
  • FIG. 2 is a diagram illustrating an example in which an intra-server delay control system that places polling threads in the kernel is applied to an interrupt model in a container-configured server virtualization environment.
  • FIG. 2 is a diagram illustrating an example in which an intra-server delay control system that places a polling thread in user space is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration.
  • FIG. 2 is a diagram illustrating an example in which an intra-server delay control system that places polling threads in user space is applied to an interrupt model in a container-configured server virtualization environment. It is a schematic diagram of Rx side packet processing by New API (NAPI) implemented from Linux kernel 2.5/2.6.
  • NAPI New API
  • FIG. 19 is a diagram illustrating an overview of Rx-side packet processing by New API (NAPI) in a portion surrounded by a broken line in FIG. 18.
  • NAPI New API
  • FIG. It is a diagram showing an example of data transfer of video (30 FPS).
  • FIG. 2 is a diagram showing a CPU usage rate used by a busy poll thread in 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 in which the New API (NAPI) implemented in Linux kernel 2.5/2.6 is applied to Rx side packet processing. Components that are the same as those in FIG. 18 are given the same reference numerals. As shown in FIG.
  • the in-server delay control system 1000 executes a packet processing APL1 placed in a user space that can be used by a user on a server equipped with an OS (for example, a Host OS), and is connected to the OS. Packet transfer is performed between the NIC 11 of the HW and the packet processing APL 1.
  • OS for example, a Host OS
  • the intra-server delay control system 1000 includes a NIC 11 (physical NIC) which is a network interface card, a hardIRQ 81 which is a handler that is called upon the generation of a processing request of the NIC 11 and executes the requested processing (hardware interrupt), and a handler for HW interrupts. It includes a HW interrupt processing section 182, a receive list 186, a Ring_Buffer 72, a polling thread (server delay control device 100), and a protocol processing section 74, which are processing function sections.
  • the Ring Buffer 72 is managed by the kernel in a memory space within 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 upper limit size is exceeded.
  • the protocol processing unit 74 is Ethernet, IP, TCP/UDP, etc.
  • the protocol processing unit 74 performs, for example, L2/L3/L4 protocol processing defined by the OSI reference model.
  • the intra-server delay control device 100 is a polling thread placed in either the kernel space or the user space.
  • the intra-server delay control device 100 includes a packet arrival monitoring section 110, a packet harvesting section 120, a sleep management section 130, a CPU frequency/CPU idle setting section 140, a mode switching control section 150, and a traffic frequency measurement section 160. , is provided.
  • the packet arrival monitoring section 110 includes a traffic frequency measuring section 160.
  • the packet arrival monitoring unit 110 is a thread for monitoring whether a packet has arrived.
  • the packet arrival monitoring unit 110 monitors (polles) the receive list 186.
  • the packet arrival monitoring unit 110 acquires pointer information indicating that the 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 for multiple pieces is transmitted.
  • the packet reaping unit 120 refers to the packet held in the Ring Buffer 72 and performs reaping to delete the corresponding queue entry from the Ring Buffer 72 based on the next processing (hereinafter referred to as There are cases where the packets are simply harvested from the Ring Buffer 72).
  • the packet harvesting unit 120 extracts the packet from the Ring_Buffer 72 based on the received information and transmits the packet to the protocol processing unit 74.
  • the packet harvesting section 120 harvests the plurality of packets at once and passes the harvested packets to the subsequent protocol processing section 74. Note that this number to be harvested at once is called a quota, and is often called batch processing.
  • the protocol processing unit 74 also performs high-speed protocol processing because it processes multiple packets at once.
  • the sleep management unit 130 causes a thread (polling thread) to go to sleep if a packet does not arrive for a predetermined period of time, and causes the thread (polling thread) to wake up from sleep using a hardware interrupt (hardIRQ) when a packet arrives. (details later).
  • the CPU frequency/CPU idle setting unit 140 sets the CPU operating frequency of the CPU core used by the thread (polling thread) to a low value during sleep.
  • the CPU frequency/CPU idle setting unit 140 sets the CPU idle state of the CPU core used by this thread (polling thread) to power saving mode during sleep (details will be described later).
  • the mode switching control unit 150 switches the operation mode of the polling thread to either the sleep control mode or the always busy poll mode based on the traffic inflow frequency measured by the traffic frequency measurement unit 160. For example, the mode switching control unit 150 changes the operation mode of the polling thread to a "sleep control mode (polling Mode switching control is performed to switch the thread to a mode that allows the thread to sleep (a mode that allows the thread to sleep), or to an always busy poll mode (a mode in which the polling thread is always busy polling) if the frequency of traffic inflow is high.
  • a single control mode polyling Mode switching control is performed to switch the thread to a mode that allows the thread to sleep (a mode that allows the thread to sleep)
  • an always busy poll mode a mode in which the polling thread is always busy polling
  • the operation mode of the polling thread is either “sleep control mode” or “always busy poll mode”; if it is not “sleep control mode”, it is set to “always busy poll mode” or “always busy poll mode”. If the mode is not "poll mode”, it is switched to "sleep control mode".
  • the above-mentioned “case where the traffic inflow frequency is low” refers to the case where the bucket inflow frequency is smaller than the threshold T (Fig. 8), such as when the traffic inflow frequency is "sparse” (Fig. 20), and the above-mentioned “traffic "When the inflow frequency is high” refers to a case where the traffic inflow frequency is equal to or higher than the threshold value T (FIG. 8), as in the case where the traffic inflow frequency is "dense” (FIG. 6) (described later).
  • the traffic frequency measurement unit 160 measures the traffic inflow frequency and transmits it to the mode switching control unit 150.
  • the traffic frequency measurement unit 160 may measure the traffic frequency by approximately estimating the traffic frequency using the number of HW interruptions (recorded as statistical information in the kernel) or the like.
  • FIG. 2 and 3 are diagrams illustrating the arrangement of the polling thread (in-server delay control device 100) in FIG. 1.
  • - Arrangement of polling thread in kernel space FIG. 2 is a configuration example in which the polling thread (in-server delay control device 100) of FIG. 1 is arranged in kernel space.
  • a polling thread (server delay control device 100) and a protocol processing unit 74 are arranged in a kernel space. This polling thread (server delay control device 100) operates within the kernel space.
  • the intra-server delay control system 1000 executes a packet processing APL1 placed in the user space on a server equipped with an OS, and transfers packets between the NIC 11 of the HW and the packet processing APL1 via a device driver connected to the OS. Make a transfer.
  • a hardIRQ 81, a HW interrupt processing unit 182, a receive list 186, and a Ring_Buffer 72 are arranged in the Device driver.
  • the Device driver is a driver for monitoring hardware.
  • the mode switching control unit 150 of the intra-server delay control device 100 periodically wakes up the polling thread during sleep, or immediately before the packet arrives in accordance with the packet arrival timing. wake up the thread.
  • the mode switching control unit 150 manages HW interrupts and controls polling thread sleep and HW interrupt enable/disable for the hardIRQ 81 (see reference numeral xx in FIG. 2).
  • the present invention can be applied to cases where there is a polling thread inside the kernel, such as 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) and a protocol processing unit 74 are arranged in the user space.
  • This polling thread (in-server delay control device 100) operates not in Kernel space but in User space.
  • the polling thread (server delay control device 100) bypasses the kernel space and transfers packets between the device driver and NIC 11 and the packet processing APL 1.
  • the mode switching control unit 150 of the intra-server delay control device 100 periodically wakes up the polling thread during sleep, or immediately before the packet arrives in accordance with the packet arrival timing. wake up the thread.
  • the mode switching control unit 150 manages HW interrupts and controls the HW interrupt processing unit 182 to sleep the polling thread and enable/disable HW interrupts (see reference numeral yy in FIG. 3).
  • the present invention can be applied when there is a polling thread in the user space, such as in DPDK.
  • FIG. 4 is a diagram illustrating the arrangement of the traffic frequency measurement unit 160 of the polling thread (in-server delay control device 100) in FIG. 1.
  • the traffic frequency measurement unit 160 of the intra-server delay control device 100 may be arranged as a thread independent from the packet arrival monitoring unit 110 to measure the traffic frequency.
  • the traffic frequency measuring unit 160 cannot directly measure the traffic frequency, but can estimate the traffic frequency by approximating the traffic frequency using the number of HW interruptions (recorded as statistical information in the kernel), etc. can be measured.
  • the operation of the intra-server delay control system 1000 configured as described above will be described below.
  • the present invention can be applied to cases where there is a polling thread inside the kernel, such as NAPI and KBP, or cases where there is a polling thread in user space, such as DPDK. This will be explained using an example where there is a polling thread inside the kernel.
  • FIGS. 1 to 4 Arrows (symbols) aa to ii in FIGS. 1 to 4 indicate the flow of packet processing on the Rx side.
  • the NIC 11 When the NIC 11 receives a packet (or frame) in a frame from the opposite device, it copies the arrived packet to the Ring Buffer 72 by DMA transfer without using the CPU (see reference numeral aa in FIGS. 1 to 4).
  • This Ring Buffer 72 is managed by ⁇ Device driver>.
  • the NIC 11 launches a hardware interrupt (hardIRQ) to the hardIRQ 81 (handler) (see symbol bb in Figures 1 to 4), and the HW interrupt processing unit 182 executes the following processing. , recognizes the packet.
  • hardIRQ hardware interrupt
  • the HW interrupt processing unit 182 executes the following processing. , recognizes the packet.
  • the HW interrupt processing unit 182 When the hardwire 81 (handler) starts up (see cc in FIG. 1), the HW interrupt processing unit 182 adds the hardware from the NIC 11, which is one of the information in the hardware interrupt (hardIRQ), to the receive list 186. Save the net device (net_device) information that indicates which device the interrupt belongs to, and register the queue reaping information. Specifically, in response to packets being packed into the Ring Buffer 72, the HW interrupt processing unit 182 uses the driver of the NIC 11 to register future queue reaping in the receive list 186 (Figs. 1 to 4). (see code dd). As a result, queue reaping due to packets being stuffed into the Ring Buffer 72 is registered in the receive list 186.
  • the HW interrupt processing unit 182 registers net_device in the receive list 186, but unlike the netif_rx 82 in FIG. 19, it does not schedule software interrupts (softIRQ). That is, the HW interrupt processing unit 182 differs from the netif_rx 82 in FIG. 19 in that it does not schedule software interrupts (softIRQ).
  • the HW interrupt processing unit 182 performs sleep release to wake up the sleeping polling thread (see reference numeral ee in FIGS. 1 to 4). Up to this point, the hardware interrupt processing in ⁇ Device driver> in FIGS. 1 to 4 has stopped.
  • softIRQ83 and do_softirq84 are deleted in ⁇ Networking layer> shown in FIG. 19, and accordingly, netif_rx82 shown in FIG. Not performed.
  • the intra-server delay control system 1000 deletes the softIRQ 83 and do_softirq 84 shown in FIG. 19, and instead provides a polling thread (intra-server delay control device 100) in ⁇ kernel space> (see FIG. 2).
  • the server delay control system 1000 provides a polling thread (server delay control device 100) in ⁇ User space> (see FIG. 3).
  • the packet arrival monitoring unit 110 monitors (polles) the receive list 186 (see reference numeral ff in FIGS. 1 to 4) and checks whether or not a packet has arrived.
  • the packet arrival monitoring unit 110 acquires pointer information indicating that the 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 (see FIGS. 4 (see code gg).
  • the information for the plurality of packets is transmitted.
  • the packet reaping unit 120 of the intra-server delay control device 100 reaps the packet from the Ring Buffer 72 if the packet has arrived (see symbol hh in FIGS. 1 to 4).
  • the packet harvesting unit 120 extracts the packet from the Ring_Buffer 72 based on the received information and transmits the packet to the protocol processing unit 74 (see reference numeral ii in FIGS. 1 to 4).
  • the intra-server delay control system 1000 stops softIRQ for packet processing, which is the main cause of NW delay occurrence, and the packet arrival monitoring unit 110 of the intra-server delay control device 100 executes a polling thread for monitoring packet arrival. Then, the packet harvesting unit 120 processes the packet using the polling model (without softIRQ) when the packet arrives.
  • the polling thread (in-server delay control device 100) that monitors the arrival of packets can sleep while no packets arrive.
  • the polling thread (server delay control device 100) sleeps depending on whether or not a packet arrives, and releases the sleep state using the 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 depending on whether or not a packet has arrived, that is, if no packet has arrived for a predetermined period of time.
  • the sleep management unit 130 cancels sleep using the 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 setting depending on whether or not a packet has arrived. Specifically, the CPU frequency/CPU idle setting unit 140 lowers the CPU frequency during sleep, and increases the CPU frequency when restarting (returns the CPU operating frequency to the original). Further, the CPU frequency/CPU idle setting unit 140 changes the CPU idle setting to power saving during sleep. Power savings can also be achieved by lowering the CPU operating frequency during sleep and by changing the CPU idle setting to a power-saving setting.
  • FIG. 5 is a diagram showing an example of polling thread operation when the traffic inflow frequency of the intra-server delay control device 100 is "sparse".
  • the vertical axis shows the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis shows time.
  • FIG. 5 shows an example of polling thread operation based on packet arrival corresponding to the data transfer example of video (30 FPS) in which packets are received intermittently shown in FIG.
  • FIG. 5 is an example where the traffic inflow frequency is "sparse", as in the example of video (30 FPS) data transfer in FIG. 20. Note that an example where the traffic inflow frequency is "dense" will be described later with reference to FIG.
  • the sleep management unit 130 of the intra-server delay control device 100 controls the sleep management unit 130 when no packet arrives for a predetermined period of time (more specifically, after a certain packet arrives, If the next packet does not arrive after a certain period of time), the polling thread is put to sleep (see symbol p: sleep in FIG. 5). Then, the sleep management unit 130 activates the polling thread at the hardIRQ 81 upon arrival of the packet (see q: wake up in FIG. 5).
  • the kernel thread does not exclusively use the CPU core, so in addition to being used by the polling thread, timer interrupts for stable system operation enter the corresponding CPU core, and the migration thread is used for error handling, 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. 5).
  • the method of putting the polling thread to sleep can achieve a sufficient power saving effect when the amount of traffic inflow is small.
  • FIG. 6 is an example of data transfer when the traffic inflow frequency is "dense".
  • the workload shown in FIG. 6 has a high traffic inflow frequency, that is, the traffic inflow frequency is "dense" in the time axis direction.
  • FIG. 7 is a diagram showing an example of polling thread operation in the data transfer example when the traffic inflow frequency is "dense" in FIG. 6.
  • the vertical axis shows the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis shows time.
  • the same polling thread operations as in FIG. 5 are given the same reference numerals.
  • the traffic inflow frequency is "dense" as shown in FIG. (See r:sleep/q:wake up).
  • the polling thread When the traffic inflow frequency is "sparse", the polling thread is controlled to sleep. When the traffic inflow frequency is "dense”, the polling thread always polls busy. When the traffic inflow frequency is "dense”, constantly busy polling can reduce the number of CPU cycles rather than repeating sleep/wake up frequently.
  • the low-latency polling thread includes a packet arrival monitoring unit 110 and a packet harvesting unit 120, and performs packet arrival monitoring and reception processing using a polling model to generate low-latency packets. Realize reception processing. Specifically, the polling thread (in-server delay control device 100) performs packet arrival monitoring and reception processing using a low-delay polling model (see reference numeral ff in FIGS. 1 to 4). Therefore, softIRQ contention does not occur and the delay is small. Additionally, when a packet arrives during sleep, the polling thread is started using high-priority hardIRQ, so the overhead caused by sleep can be suppressed as much as possible.
  • the polling thread includes a sleep management unit 130, and the sleep management unit 130 causes the polling thread to sleep while no packet has arrived, thereby reducing power consumption due to wasteful busy polling by the polling thread. prevent waste. Furthermore, the polling thread (server delay control device 100) includes a CPU frequency/CPU idle setting section 140, and the CPU frequency/CPU idle setting section 140 dynamically controls the CPU operating frequency. This dynamic control of the CPU operating frequency is used in conjunction with sleep control.
  • the polling thread goes to sleep and controls the CPU frequency to be set low while no power-saving packets arrive, so it is possible to suppress the increase in power consumption due to busy polling.
  • the polling thread (server delay control device 100) includes a mode switching control section 150 and a traffic frequency measurement section 160.
  • the mode switching control section 150 measures the traffic inflow frequency and transmits it to the mode switching control section 150.
  • the mode switching control unit 150 switches the operation mode of the polling thread between "always busy poll mode" and "sleep control mode” depending on the traffic inflow frequency. Specifically, the mode switching control unit 150 switches the operation mode of the polling thread to "sleep control mode" when the traffic inflow frequency is "sparse", and switches the operation mode of the polling thread to "sleep control mode" when the traffic inflow frequency is “dense”. Switch the operation mode to "always busy poll mode”.
  • FIG. 8 is a diagram illustrating operation mode switching points.
  • the vertical axis shows the power consumption by the polling thread
  • the horizontal axis shows the packet inflow frequency (traffic inflow frequency).
  • the power consumption by the polling thread is constant.
  • the power consumption by the polling thread increases as the frequency of packet inflow increases.
  • the packet inflow frequency reaches a certain threshold value T
  • the power consumption by the polling thread becomes equal, and when the packet inflow frequency exceeds the threshold value T, when sleep control is performed, the power consumption by the polling thread increases on the contrary.
  • the range from low packet inflow frequency to the threshold T is the "area where sleep control mode should be used" (see symbol jj in Figure 8), and above the threshold T is the "always busy poll mode”. ” (see reference numeral kk in FIG. 8).
  • the threshold value T becomes the operating mode switching point between the "sleep control mode" and the "always busy poll mode".
  • the threshold value T differs depending on the type of server used.
  • the operator measures the threshold value T in advance through experiments using the server used for the service.
  • FIG. 9 is a diagram illustrating an example of switching determination logic in the form of a table. As shown in FIG. 9, the switching judgment logic consists of a category and a logic outline for each category.
  • Simple threshold judgment A method that measures the amount of traffic inflow and switches the operation mode when the frequency of traffic inflow per unit time exceeds the threshold T.
  • FIG. 10 is a flowchart showing the NIC and HW interrupt processing of the polling thread (in-server delay control device 100). While the polling thread is activated, this operation flow is executed in a loop. When a packet arrives at the NIC 11, this flow starts. In step S1, the NIC 11 copies the arrived packet data to a memory area by DMA (Direct Memory Access).
  • DMA Direct Memory Access
  • step S2 the polling thread (in-server delay control device 100) determines whether HW interrupts are permitted. If HW interrupts are permitted (S2: Yes), the process advances to step S3, and if HW interrupts are not permitted (S2: No), the process of this flow is ended.
  • step S3 the NIC 11 activates the HW interrupt (hardIRQ) to the hardIRQ 81 (handler), activates the HW interrupt, and registers packet arrival information (NIC device information, etc.) in the receive list 186.
  • step S4 if the polling thread (in-server delay control device 100) is sleeping, the NIC 11 wakes up the polling thread and ends the processing of this flow.
  • FIG. 11 is a flowchart showing the operation mode switching process of the mode switching control unit 150 of the polling thread (server delay control device 100).
  • the mode switching control unit 150 receives traffic inflow frequency information from the traffic frequency measurement unit 160.
  • the mode switching control unit 150 determines which of the "sleep control mode" and the “constantly busy poll mode” is suitable based on the received traffic inflow frequency information and according to the switching determination logic described in FIG. .
  • the mode switching control unit 150 controls each unit (packet arrival monitoring unit 110, packet harvesting unit 120, sleep management unit 130, and CPU frequency/CPU idle setting unit 140). Instructs the operation mode after determination. If the current operating mode is the same as the determined operating mode, no instruction is given to each part regarding the operating mode. This causes the current mode of operation to continue.
  • FIG. 12 is a flowchart showing the polling thread operation mode switching process of the polling thread (server delay control device 100). While the polling thread is sleeping, a packet arrives, it is woken up by a HW interrupt, and this flow starts. In step S21, the mode switching control unit 150 prohibits HW interrupts by the NIC 11. If a HW interrupt occurs during processing, the processing will be interrupted, so the mode switching control unit 150 temporarily prohibits HW interrupts by the NIC 11.
  • step S22 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 releases the idle state if the CPU is in the idle state.
  • step S23 the polling thread refers to the receive list 186.
  • the polling thread knows from which device the HW interrupt has occurred, and checks the packet arrival information in the receive list 186 in the next step S24.
  • the Ring Buffer 72 may be directly referred to to confirm whether or not a packet has arrived.
  • NAPI implemented in the Linux kernel monitors a Control Plane list called poll_list.
  • step S24 the packet arrival monitoring unit 110 determines whether packet arrival information exists in the receive list 186. If the packet arrival information exists in the receive list 186 (S24: Yes), the process advances to step S25, and if the packet arrival information does not exist in the receive list 186 (S24: No), that is, if there is no packet to be processed, The process skips the following process and proceeds to step S30.
  • the polling thread refers to the packet data from the ring buffer 72 and transfers the corresponding data to the subsequent protocol processing unit 74.
  • the polling thread may be received and processed all at once.
  • step S26 the traffic frequency measurement unit 160 measures the traffic inflow frequency and transmits it to the mode switching control unit 150.
  • the traffic frequency measurement unit 160 may measure the traffic frequency by approximately estimating the traffic frequency using the number of HW interruptions (recorded as statistical information in the kernel). Furthermore, if the operation mode switching judgment logic is a light process such as a simple threshold value judgment shown in FIG. (In that case, the traffic frequency measurement section 160 also functions as the mode switching control section 150.)
  • step S27 the sleep management unit 130 causes the polling thread to sleep for a short time to match the traffic inflow frequency. For example, if the traffic inflow frequency is 5 us, the device will sleep for about 3 us.
  • step S28 the packet arrival monitoring unit 110 determines whether the operation mode instructed by the mode switching control unit is the “sleep control mode”. If the operation mode instructed by the mode switching control section is not the "sleep control mode" (S28: No), the process returns to step S25.
  • the packet harvesting unit 120 determines whether or not there are unreceived packets in the ring buffer 72 in step S29. If there is an unreceived packet in the ring buffer 72 (S29: Yes), the process returns to step S25.
  • step S25 to step S28 is always a busy poll loop (see dashed line box mm in FIG. 12) (other loops are sleep control mode loops).
  • step S30 the CPU frequency/CPU idle setting unit 140 sets the CPU frequency of the CPU core on which the polling thread operates to a low value, and puts the corresponding CPU into the idle state. Make it.
  • step S31 the packet arrival monitoring unit 110 deletes the corresponding NIC information from the receive list 186.
  • step S32 the packet arrival monitoring unit 110 allows the HW interrupt by the corresponding NIC.
  • step S33 the sleep management unit 130 puts the polling thread to sleep and ends the processing of this flow.
  • FIG. 13 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the intra-server delay control device 100.
  • the computer 900 has a CPU 901, a ROM 902, a RAM 903, an HDD 904, a communication interface (I/F) 906, an input/output interface (I/F) 905, and a media interface (I/F) 907.
  • the CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and controls each part of the intra-server delay control device 100 shown in FIGS. 1 to 4.
  • the ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs depending on the hardware of the computer 900, and the like.
  • the CPU 901 controls an input device 910 such as a mouse and a keyboard, and an output device 911 such as a display via an input/output I/F 905.
  • the CPU 901 acquires data from the input device 910 via the input/output I/F 905 and outputs the generated data to the output device 911.
  • a GPU Graphics Processing Unit
  • a GPU Graphics Processing Unit
  • the HDD 904 stores programs executed by the CPU 901 and data used by the programs.
  • the communication I/F 906 receives data from other devices via a communication network (for example, NW (Network) 920) and outputs it to the CPU 901, and also sends data generated by the CPU 901 to other devices via the communication network. Send to device.
  • NW Network
  • the media I/F 907 reads the program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903.
  • the CPU 901 loads 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 conductive memory tape medium, a semiconductor memory, or the like. It is.
  • the CPU 901 of the computer 900 executes the intra-server delay control device by executing a program loaded on the RAM 903. Realizes 100 functions. Furthermore, 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 a communication network (NW 920).
  • NW 920 communication network
  • the present invention can be applied to an in-server delay control device that starts a thread in the kernel that monitors packet arrival using a polling model, such as a polling thread (in-server delay control device 100) shown in FIG.
  • a polling thread in-server delay control device 100
  • the OS is not limited.
  • it is not limited to being under a server virtualization environment. Therefore, the intra-server delay control system can be applied to each of the configurations shown in FIGS. 14 and 15.
  • FIG. 14 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. Components that are the same as those in FIGS. 1 and 18 are given the same reference numerals.
  • the server delay control device 100 is placed in the Kernel 171 of the Guest OS 70, and the server delay control device 100 is placed in the Kernel 91 of the Host OS 90.
  • the server includes a Host OS 90 in which a virtual machine and an external process formed outside the virtual machine can operate, and a Guest OS 70 that operates within the virtual machine.
  • HostOS90 is a memory space in a server equipped with Kernel91 and HostOS90, and registers Ring Buffer22 managed by Kernel91 and net device information indicating which device the hardware interrupt (hardIRQ) from NIC11 belongs to. It has a receive list 186 (FIG. 2), a vhost-net module 221 which is a kernel thread, a tap device 222 which is a virtual interface created by Kernel 91, and a virtual switch (br) 223.
  • the Kernel 91 includes an intra-server delay control device 100. Kernel 91 transmits the packet to virtual machine 40 configured with Linux (registered trademark) and KVM 30 via tap device 222 .
  • the GuestOS 70 includes a kernel 171, a Ring Buffer 52, and a Driver 53, and the Driver 53 includes a virtio-driver 531.
  • the Kernel 171 includes an intra-server delay control device 100 and a protocol processing unit 74 that performs protocol processing on packets that have been harvested.
  • the Kernel 171 transmits the packet to the packet processing APL1 via the protocol processing unit 74.
  • packet transfer can be performed with the delay within the server reduced without modifying the APL in either the HostOS 90 or GuestOS 70 OS.
  • FIG. 15 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. Components that are the same as those in FIGS. 1 and 14 are given the same reference numerals.
  • the intra-server delay control system 1000B has a container configuration in which GuestOS 70 is replaced with Container 211.
  • Container 211 has vNIC (virtual NIC) 212.
  • the present invention can be applied to a configuration example in which a polling thread (server delay control device 100) is arranged in the user space.
  • the OS is not limited.
  • it is not limited to being under a server virtualization environment. Therefore, the intra-server delay control system can be applied to each of the configurations shown in FIGS. 16 and 17.
  • FIG. 16 is a diagram showing an example in which the intra-server delay control system 1000C is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration. Components that are the same as those in FIGS. 1 and 14 are given the same reference numerals.
  • the intra-server delay control system 1000C includes a Host OS 20 in which a virtual machine and an external process formed outside the virtual machine can operate, and the Host OS 20 includes a Kernel 21 and a Driver 23.
  • the server delay control system 1000C includes a NIC 11 of the HW connected to the Host OS 20, a polling thread (server delay control device 100) placed in the User space 60, a virtual switch 53, a Guest OS 50 operating within the virtual machine, A polling thread (server delay control device 100) connected to the host OS 20 and placed in the user space 60 is provided.
  • packet transfer can be performed with the delay within the server reduced without changing the APL in either the Host OS 20 or Guest OS 1 (50). be able to.
  • FIG. 17 is a diagram showing an example in which the intra-server delay control system 1000D is applied to an interrupt model in a container-configured server virtualization environment. Components that are the same as those in FIGS. 1, 14, and 16 are designated by the same reference numerals.
  • the intra-server delay control system 1000D has a container configuration in which the Guest OS 50 in FIG. 16 is replaced with a Container 211.
  • Container 211 has vNIC (virtual NIC) 212.
  • the present invention can be applied to a system with a non-virtualized configuration such as a bare metal configuration.
  • packet transfer can be performed with reduced delay within the server without modifying the APL.
  • the present invention works with RSS (Receive-Side Scaling), which can process inbound network traffic using multiple CPUs, to increase the number of CPUs allocated to the packet arrival monitoring thread when the number of traffic flows increases. It becomes possible to scale out the load.
  • RSS Receive-Side Scaling
  • NIC Network Interface Card
  • FEC Forward Error Correction
  • processors other than CPU are similarly applicable to processors other than CPUs, such as GPUs, FPGAs, and ASICs (application specific integrated circuits), if they have an idle state function.
  • processors other than CPUs such as GPUs, FPGAs, and ASICs (application specific integrated circuits), if they have an idle state function.
  • the in-server delay control device 100 which is placed in the kernel space of the OS and starts up a thread that monitors packet arrival using a polling model
  • the operation mode of a thread is a sleep control mode in which the thread can be put to sleep, and a always busy poll mode in which the thread is always busy polling. It includes a frequency measurement unit 160 and a mode switching control unit 150 that switches the operation mode of a thread to either a sleep control mode or a constantly busy poll mode based on the traffic inflow frequency measured by the traffic frequency measurement unit 160.
  • the mode switching control unit 150 changes the operation mode of the thread (polling thread) to sleep based on the traffic inflow frequency, for example, when the traffic inflow frequency is a predetermined threshold (threshold T in FIG. 8). Switch between control mode and always busy poll mode. Thereby, when the traffic inflow frequency is "dense", sleep and sleep release operations can be suppressed, and power saving can be achieved while achieving low delay. Specifically, by dynamically switching the appropriate packet reception mode (sleep control mode/always busy poll mode) according to the frequency of traffic inflow, the system can enjoy the power saving effect of sleep while the frequency of traffic inflow is low. When the traffic inflow frequency becomes "dense”, even if the interrupt overhead becomes greater than the power saving effect of sleep, by constantly performing busy poll, it is possible to prevent the deterioration of power consumption.
  • the following effects can be obtained by switching between the "sleep control mode" and the "always busy poll mode” rather than controlling the sleep time etc. in the sleep control.
  • sleep control logic, etc. which is not necessary for simple busy poll, in simple busy poll mode, so unnecessary control logic operations can be omitted, potentially reducing power consumption.
  • the polling thread goes to sleep and controls the CPU frequency to be set low, so it is possible to suppress the increase in power consumption due to busy polling (power saving).
  • the present invention can be applied to cases where there is a polling thread inside the kernel, such as NAPI or KBP.
  • an in-server delay control device 100 (see FIGS. 1 and 3) that is placed in the user space and starts up a thread that monitors packet arrival using a polling model.
  • the operation mode of thread has a sleep control mode in which the thread can be put to sleep, and an always busy poll mode in which the thread is always busy polling, and a traffic frequency measurement unit 160 that measures the frequency of traffic inflow;
  • a mode switching control unit 150 is provided that switches the operation mode of the thread to either a sleep control mode or a constantly busy poll mode based on the traffic inflow frequency measured by the traffic frequency measurement unit 160.
  • the present invention can be applied to cases where there is a polling thread in the user space, such as in DPDK.
  • the Guest OS (GuestOS70) (see Figure 14) running inside the virtual machine uses the kernel (Kernel171) and a ring buffer (Ring Buffer72) ( Figure 14) managed by the kernel in the memory space of the server equipped with the Guest OS. ), and a packet arrival monitoring unit 110 that monitors a poll list that registers network device information indicating which device the hardware interrupt from the interface unit (NIC 11) belongs to, and checks whether or not a packet has arrived. , if a packet has arrived, the packet reaping unit 120 refers to the packet held in the ring buffer (Ring Buffer 72) and deletes the corresponding queue entry from the ring buffer.
  • a protocol processing unit that performs packet protocol processing, and an intra-server delay control device 100 that launches a thread that monitors packet arrival using a polling model in the kernel.
  • the control device 100 has a sleep control mode in which the thread (polling thread) can be put to sleep, and an always busy poll mode in which the thread is always busy polling, and the control device 100 measures the frequency of traffic inflow.
  • a mode switching control unit 150 that switches the thread operation mode between a sleep control mode and a always busy poll mode based on the traffic inflow frequency measured by the traffic frequency measurement unit 160. Be prepared.
  • the Host OS (HostOS90) (see Figure 14) (HostOS20) (see Figures 16 and 17), on which virtual machines and external processes formed outside the virtual machine can run, runs the kernel (Kernel91) and the Host OS.
  • a ring buffer (Ring Buffer 72) (see Figure 18) managed by the kernel in the memory space of the server equipped with it, and net device information indicating which device the hardware interrupt from the interface unit (NIC 11) belongs to.
  • a packet arrival monitoring unit 110 monitors a poll list in which a packet is registered and checks whether a packet has arrived, and if a packet has arrived, refers to the packet held in the ring buffer and removes the corresponding queue entry from the ring buffer.
  • the in-server delay control device 100 has an in-server delay control device 100 that starts up a thread to perform a thread, and the in-server delay control device 100 has two operation modes: a sleep control mode in which the thread can be put to sleep, and a busy polling mode in which the thread is constantly polled.
  • a traffic frequency measurement unit 160 measures the traffic inflow frequency, and a thread operation mode is set to sleep control mode based on the traffic inflow frequency measured by the traffic frequency measurement unit 160.
  • a mode switching control unit 150 that switches to either the always busy poll mode or the busy poll mode is provided.
  • sleep and wake operations can be performed when the traffic inflow frequency is "dense" for a server equipped with a kernel (Kernel171) and a host OS (HostOS90). It is possible to achieve power savings while achieving low latency.
  • kernel Kernel171
  • HostOS90 host OS
  • the mode switching control unit 150 controls the polling thread from an area where the traffic inflow frequency is low until a predetermined threshold (threshold T in FIG. 8) is reached.
  • the operation mode is switched to a sleep control mode, and when the traffic inflow frequency exceeds a predetermined threshold value (threshold value T in FIG. 8), the operation mode is always switched to a busy poll mode.
  • the thread (polling thread) is In addition to switching the operation mode to the sleep control mode, it is possible to switch to the always busy poll mode when the threshold value T or higher is in the "area where the always busy poll mode should be used" (see symbol kk in FIG. 8).
  • the optimal value of the threshold value T is selected using the switching determination logic shown in the table of FIG.
  • a packet arrival monitoring unit 110 monitors (polles) packet arrival from the interface unit (NIC 11) and checks whether or not the packet has arrived.
  • the thread (polling thread) is put to sleep when a packet does not arrive for a predetermined period of time, and when a packet arrives, this thread (polling thread) is put to sleep by a hardware interrupt (hardIRQ).
  • a sleep management unit 130 that performs cancellation is provided.
  • the packet arrival monitoring unit 110 performs packet arrival monitoring and reception processing using the polling model, so softIRQ contention does not occur and delays can be reduced. Furthermore, in the sleep control mode, when a packet arrives during sleep, the sleep management unit 130 wakes up a polling thread using high-priority hardIRQ, so the overhead caused by sleep can be suppressed as much as possible.
  • each of the above-mentioned configurations, functions, processing units, processing means, etc. may be partially or entirely realized by hardware, for example, by designing an integrated circuit.
  • each of the above-mentioned configurations, functions, etc. 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, storage devices such as hard disks, SSDs (Solid State Drives), IC (Integrated Circuit) cards, SD (Secure Digital) cards, optical disks, etc. It can be held on a recording medium.
  • Packet processing APL application
  • HW 11 NIC physical NIC
  • Interface part 20,90 Host OS 22, 52, 72 Ring Buffer 50,70 Guest OS 60 user space
  • Protocol processing unit 86,186 receive list (poll list) 91,171 Kernel 100
  • In-server delay control device polyling thread
  • Packet arrival monitoring unit 120
  • Packet harvesting unit 130
  • sleep management unit 140
  • Mode switching control section 160
  • Traffic frequency measurement section 211 Container 1000, 1000A, 1000B, 1000C, 1000D Server delay control system T Threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

サーバ内遅延制御装置（１００）は、OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部（１６０）と、トラヒック頻度計測部（１６０）が計測したトラヒック流入頻度に基づいて、スレッドの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替えるモード切替制御部（１５０）と、を備える。

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を行うために、ＣＰＵコアを専有する。図２０に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
　このような背景を鑑みて本発明がなされたのであり、本発明は、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することを課題とする。
　前記した課題を解決するため、OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、前記スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部と、前記トラヒック頻度計測部が計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるモード切替制御部と、前記常時busy pollモードの場合、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視し、パケット到着有無を確認するパケット到着監視部と、を備えることを特徴とするサーバ内遅延制御装置とした。
　本発明によれば、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することができる。
本発明の実施形態に係るサーバ内遅延制御システムの概略構成図である。 図１のpolling thread（サーバ内遅延制御装置）をkernel spaceに配置した構成例である。 図１のpolling thread（サーバ内遅延制御装置）をUser spaceに配置した構成例である。 図１のpolling thread（サーバ内遅延制御装置）のトラヒック頻度計測部の配置を説明する図である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のトラヒック流入頻度が「疎」の場合のpolling thread動作例を示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのトラヒック流入頻度が「密」の場合のデータ転送例である。 図６のトラヒック流入頻度が「密」の場合のデータ転送例におけるpolling thread動作例を示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の動作モード切替ポイントを説明する図である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の切り替え判断ロジックの例を表にして示す図である。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のＮＩＣおよびＨＷ割込処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のモード切替制御部の動作モード切替処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置のpolling threadの動作モード切替処理を示すフローチャートである。 本発明の実施形態に係るサーバ内遅延制御システムのサーバ内遅延制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における割込モデルに、kernel内にpolling threadを配置するサーバ内遅延制御システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における割込モデルに、kernel内にpolling threadを配置するサーバ内遅延制御システムを適用した例を示す図である。 汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における割込モデルに、user spaceにpolling threadを配置するサーバ内遅延制御システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における割込モデルに、user spaceにpolling threadを配置するサーバ内遅延制御システムを適用した例を示す図である。 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）状態を省電力モードに設定する（詳細後記）。
　モード切替制御部１５０は、トラヒック頻度計測部１６０が計測したトラヒック流入頻度に基づいて、polling threadの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替える。例えば、モード切替制御部１５０は、トラヒック頻度計測部１６０が計測したトラヒック流入頻度情報に応じて、polling threadの動作モードをトラヒック流入頻度（バケット流入頻度）が低い場合は、「sleep制御モード(polling threadをsleep可能なモード)」に、またトラヒック流入頻度が高い場合は、「常時busy pollモード(polling threadを常時busy pollingさせるモード)」に切り替えるモード切替制御を行う。
　ここで、polling threadの動作モードは、「sleep制御モード」と「常時busy pollモード」のいずれかであり、「sleep制御モード」でない場合は、「常時busy pollモード」に、また、「常時busy pollモード」でない場合は、「sleep制御モード」に切り替えられる。
　また、上記「トラヒック流入頻度が低い場合」とは、トラヒック流入頻度が「疎」(図２０)の場合のように、バケット流入頻度が閾値Ｔ（図８）より小さい場合をいい、上記「トラヒック流入頻度が高い場合」とは、トラヒック流入頻度が「密」(図６)の場合のように、トラヒック流入頻度が閾値Ｔ（図８）以上の場合をいう（後記）。
　トラヒック頻度計測部１６０は、トラヒック流入頻度を計測し、モード切替制御部１５０へ伝達する。トラヒック頻度計測部１６０は、ＨＷ割込回数（kernel内に統計情報として記録されている）等により近似的にトラヒック頻度を類推することで、トラヒック頻度を計測してもよい。
 <サーバ内遅延制御装置の配置>
　図２および図３は、図１の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を配置する形態では、スリープ時、定期的に当該スレッドを起床させる、または、パケット到着タイミングに合わせて当該パケット到着の直前に当該スレッドを起床させる。モード切替制御部１５０は、ＨＷ割込を管理し、hardIRQ８１に対し、polling threadのsleepやＨＷ割込許可／禁止を制御する（図２の符号ｘｘ参照）。
　本発明を、ＮＡＰＩやＫＢＰのように、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を配置する形態では、スリープ時、定期的に当該スレッドを起床させる、または、パケット到着タイミングに合わせて当該パケット到着の直前に当該スレッドを起床させる。モード切替制御部１５０は、ＨＷ割込を管理し、ＨＷ割込処理部１８２に対しpolling threadのsleepやＨＷ割込許可／禁止を制御する（図３の符号ｙｙ参照）。
　本発明を、ＤＰＤＫのように、user spaceにpolling threadがある場合に適用することができる。
 <トラヒック頻度計測部１６０の配置>
　図４は、図１のpolling thread（サーバ内遅延制御装置１００）のトラヒック頻度計測部１６０の配置を説明する図である。
　図４に示すように、サーバ内遅延制御装置１００のトラヒック頻度計測部１６０は、パケット到着監視部１１０から独立したスレッドとして配置し、トラヒック頻度を計測してもよい。この場合、トラヒック頻度計測部１６０は、直接トラヒック頻度を計測できなくなるが、ＨＷ割込回数（kernel内に統計情報として記録されている）等で近似的にトラヒック頻度を類推することで、トラヒック頻度を計測可能である。
　以下、上述のように構成されたサーバ内遅延制御システム１０００の動作を説明する。
　本発明は、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合、または、ＤＰＤＫのように、user spaceにpolling threadがある場合のいずれにも適用することができる。kernel内部に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（サーバ内遅延制御装置１００）設ける（図３参照）。
　パケット到着監視部１１０は、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が使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。なお、図５は、図２０に示す間欠的にパケットが受信される映像（３０ＦＰＳ）のデータ転送例に対応するパケット到着によるpolling thread動作例を示している。
　図５は、図２０の映像（３０ＦＰＳ）のデータ転送例のように、トラヒック流入頻度が「疎」の場合の例である。なお、トラヒック流入頻度が「密」の場合の例は、図６で後記する。
　図５に示すように、サーバ内遅延制御装置１００のsleep管理部１３０は、所定期間パケットの到着がない場合（より詳細には、あるパケット到着してから、保守・運用者があらかじめ定めた固定値（一定期間）を経過しても次のパケット到着がない場合）に、polling threadをsleepさせる（図５の符号ｐ：sleep参照）。そして、sleep管理部１３０は、パケット到着のhardIRQ８１でpolling threadを起動させる（図５の符号ｑ：wake up参照）。
　なお、sleep 時には、kernelthreadがＣＰＵコアを専有していないため、polling threadが使用する以外にも、システム安定動作のためのタイマの割込みが該当ＣＰＵコアに入ったり、エラー処理等のためのmigration threadが該当ＣＰＵコアに入ったりすることで、polling threadが使用するＣＰＵコアのＣＰＵ使用率が変動する場合がある（図５の符号ｒ参照）。
　図５のpolling thread動作例に示すように、polling threadをsleepさせる方式は、トラヒック流入量が少ない場合は省電力効果を十分に得ることができる。
 <トラヒック流入頻度が「密」の場合>
　次に、トラヒック流入頻度が「密」の場合について説明する。
　図６は、トラヒック流入頻度が「密」の場合のデータ転送例である。図６に示すワークロードは、図２０と対比して分かるように、トラヒック流入頻度が高い、すなわち時間軸方向にトラヒック流入頻度が「密」である。
　例えば、vRAN（virtual Radio Access Network） vDU（virtual Distributed Unit）システムにおけるnumerology=3or4のように、時間方向のsymbol間隔が短い（例えば、8.92us,4.46us間隔）でデータが到着する場合等が該当する。
　図７は、図６のトラヒック流入頻度が「密」の場合のデータ転送例におけるpolling thread動作例を示す図である。縦軸は、polling threadが使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。図５と同じpolling thread動作には、同一符号を付している。
　図６に示すトラヒック流入量が多い、すなわちトラヒック流入頻度が「密」の場合は、図７に示すように、sleepできる時間が短くなり、sleepとwake upとが高頻度に繰り返される（図７の符号ｒ：sleep/ｑ：wake up参照）。
　トラヒック流入頻度が「密」の場合は、sleepとwake upとが高頻度に繰り返されることで、CPU使用率を低下させられない。このため、sleepすることによるCPU cycleの消費電力削減効果よりも、wake up時の割込オーバーヘッドによるCPU cycleの消費電力増加の方が大きくなり、結果としてsleepすることにより消費電力が高くなってしまう場合がある。
　このように、トラヒック流入頻度が「疎」の場合（図５参照）は、省電力効果を十分に得ることができるが、トラヒック流入頻度が「密」の場合は、polling threadをsleepさせずに、単純に常時busy pollさせた方が電力消費を小さくできる場合がある。
 <「sleep制御モード」と「常時busy pollモード」の消費電力比較>
　次に、sleep/wake upを繰り返すよりも、単純busy pollの方が、消費電力が小さくなる理由について説明する。
　sleep/wake upを行う「sleep制御モード」では、sleep時にパケットを受信すると、下記処理が発生し、この処理の演算のためのCPU cycleを必要とする。
・ハードウェア割込発動
・ハードウェア割込ハンドラ処理（receive listへの登録、sleepしているスレッドの起床）
・polling threadがuser spaceに配置されている場合は、ハードウェア割込処理のkernel特権モードから、polling threadの起床処理のための一般モードへの切替に伴うコンテキストスイッチ
　これらの「sleep制御モード」における演算量（仕事量）と、単純にbusy pollを行う「常時busy pollモード」における演算量（仕事量）とを比較した場合、トラヒック流入頻度が「密」の場合には、「sleep制御モード」における演算量の方が、「常時busy pollモード」における演算量よりも増大する。このように、トラヒック流入頻度が「密」の場合には、polling threadをsleepさせずに、単純に常時busy pollさせた方が電力消費を小さくできる場合がある。
 <モード切り替えまとめ>
　トラヒック流入頻度が「疎」の場合は、polling threadをsleepさせることによる省電力効果が見込めるため、sleep制御を行う。一方で、トラヒック流入頻度が「密」の場合は、polling threadをsleepさせると、高頻度にsleep/wake upを繰り返すことになる。この場合、sleepによる省電力効果よりも、割込オーバーヘッドの方が大きくなり、sleep制御を行うことで消費電力が悪化する場合がある。このため、「常時busy pollモード」とする（「sleep制御モード」としない）。
　トラヒック流入頻度が「疎」の場合は、polling threadのsleep制御を行う。
　トラヒック流入頻度が「密」の場合は、polling threadは常時busy pollする。トラヒック流入頻度が「密」の場合、常にbusy pollする方が、sleep/wake upを高頻度で繰り返すよりも、CPU cycle数を削減できる。
　このように、トラヒック流入頻度に応じて、これらの受信方式モードを切り替えることで、省電力と低遅延の両立を達成する。
［発明概要］
　　　・　低遅延
　polling thread（サーバ内遅延制御装置１００）は、パケット到着監視部１１０と、パケット刈取部１２０と、を備え、pollingモデルによりパケットの到着監視と受信処理を行うことで、低遅延なパケット受信処理を実現する。具体的には、polling thread（サーバ内遅延制御装置１００）は、低遅延pollingモデルによりパケットの到着監視および受信処理を行う（図１～図４の符号ｆｆ参照）。このため、softIRQ競合が発生せず、遅延が小さい効果がある。また、sleep時にパケットが到着した際は、高優先のhardIRQによりpolling threadを起こすため、sleepによるオーバーヘッドをできる限り抑制できる。
（２）省電力（その１）
　polling thread（サーバ内遅延制御装置１００）は、sleep管理部１３０を備え、sleep管理部１３０がパケットが到着していない間はpolling threadをsleepさせることで、polling threadによる無駄なbusy pollingによる消費電力の浪費を防ぐ。
　また、polling thread（サーバ内遅延制御装置１００）は、CPU周波数/CPU idle設定部１４０を備え、CPU周波数/CPU idle設定部１４０がCPU動作周波数の動的制御を行う。このCPU動作周波数の動的制御は、sleep制御と併用する。
　このように、省電力パケットが到着していない間は、polling threadがsleepし、CPU周波数を低く設定する制御をするので、busy pollingによる消費電力増加を抑制できる。
（３）省電力（その２）
　polling thread（サーバ内遅延制御装置１００）は、モード切替制御部１５０と、トラヒック頻度計測部１６０と、を備える。モード切替制御部１５０は、トラヒック流入頻度を計測し、モード切替制御部１５０に伝達する。モード切替制御部１５０は、トラヒック流入頻度に応じて、polling threadの動作モードを、「常時busy pollモード」と、「sleep制御モード」のいずれかに切り替える。具体的には、モード切替制御部１５０は、トラヒック流入頻度が「疎」の場合は、polling threadの動作モードを「sleep制御モード」に切り替え、トラヒック流入頻度が「密」の場合は、polling threadの動作モードを「常時busy pollモード」に切り替える。
［「sleep制御モード」と「常時busy pollモード」の切替制御の特徴］
　次に、sleep時間等の制御を行うのではなく、モードを分けることのメリットについて説明する。
　sleep/wake upを行う「sleep制御モード」と、単純busy pollを行う「常時busy pollモード」とで、モードを分ける。これにより、単純busy pollには必要のないsleep制御ロジック等を単純busy pollモードに実装する必要がない。このため、余計な制御ロジックの演算を省略することができ、余計な演算が減り、消費電力を削減できる可能性がある。逆に、動作モードを分けない場合は、単純busy pollを行うモードであっても、sleep制御時間等の判断ロジックを実装し、この演算コストを要することになる。
　また、モードごとに独立したプログラムを作りやすくなるため、各モードに特化した制御を導入しやすくなる。
［動作モード切替ポイント］
　図８は、動作モード切替ポイントを説明する図である。縦軸は、polling threadによる消費電力を示し、横軸は、パケット流入頻度（トラヒック流入頻度）を示す。
　図８に示すように、polling threadが常にbusy pollする場合、polling threadによる消費電力は一定である。sleep制御を行う場合、パケット流入頻度が高くなるに従ってpolling threadによる消費電力も上昇していく。パケット流入頻度がある閾値Ｔのところでpolling threadによる消費電力は等しくなり、パケット流入頻度が閾値Ｔを超えると、sleep制御を行うと、polling threadによる消費電力は却って増大する。polling threadによる消費電力の観点からは、パケット流入頻度低から閾値Ｔまでは、「sleep制御モードを使用すべき領域」（図８の符号ｊｊ参照）であり、閾値Ｔ以上は「常時busy pollモードを使用すべき領域」（図８の符号ｋｋ参照）となる。
　すなわち、パケット流入頻度が閾値Ｔに達すると、sleep制御をしても、sleepする時間が短く、割込オーバーヘッドの方が上回るため、常時busy pollよりも消費電力が高くなる（図８の双方向矢印ｌｌ参照）。したがって、閾値Ｔが「sleep制御モード」と「常時busy pollモード」との動作モード切替ポイントとなる。
　ところで、polling threadのsleepによる省電力効果や、割込オーバーヘッドは、使用するサーバスペックに依って異なる。つまり、上記閾値Ｔは使用するサーバ機種に依って異なることになる。一方で、流入するパケットサイズにはあまり相関は無いため、運用者が予めサービスに使用するサーバを用いて、閾値Ｔを実験により計測しておくことが考えられる。
［切り替え判断ロジックの例］
　図９は、切り替え判断ロジックの例を表にして示す図である。
　図９に示すように、切り替え判断ロジックは、カテゴリと、カテゴリごとのロジック概要からなる。
１．単純な閾値判定
　トラヒック流入量を計測しておき、単一時間当たりのトラヒック流入頻度が閾値Ｔを超えた際に動作モードを切り替える方式
２．時間帯と閾値による判定
　日中帯は人が活発に活動するため、夜間に比べてトラヒック量が多い傾向にある。このトラヒック量の特徴を考慮し、下記のように時間帯を考慮した動作モード切り替えを行う。
・日中帯：トラヒック流入頻度が閾値Ｔより高くなった場合、常時busy pollモードへ移行する。この場合、一時的に閾値Ｔを下回っても、sleep制御モードへは移行しないことで、閾値Ｔを境に動作モードが頻繁に切り替わるハンチングを防止する。
・夜間帯：トラヒック頻度が閾値Ｔより低くなった場合、sleep制御モードへ移行する。この場合、一時的に閾値Ｔを超えても、常時busy pollモードへは移行しないことで、閾値Ｔを境に動作モードが頻繁に切り替わるハンチングを防止する。
３．企画型イベント情報や立地情報と閾値による判定
　花火大会等のイベントや、店舗の営業時間等に依って、在圏内の人数が変動し、トラヒック量が特徴的な場合がある。このような企画型イベント情報や立地情報を入手しておき、そのイベントによって予想される時間帯別のトラヒック量に応じて、上記２．と同様の制御を行うことで、効果の高い動作モードの切り替えが可能である。
４．機械学習によるトラヒック予測による判定
　トラヒック量の推移を機械学習により学習しておき、流入するトラヒックパターンから、将来のトラヒック頻度を推論することによって予想し、適する動作モードへ切り替える。
［フローチャート］
 <ＮＩＣおよびＨＷ割込処理>
　図１０は、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制御モード」と「常時busy pollモード」のどちらが適するかを判断する。モード切替制御部１５０は、現在の動作モードが判断後の動作モードと異なる場合は、各部（パケット到着監視部１１０、パケット刈取部１２０、sleep管理部１３０、およびCPU周波数/CPU idle設定部１４０）へ判断後の動作モードを指示する。現在の動作モードが判断後の動作モードと同じ場合は、各部への動作モードを指示は行わない。これにより、現在の動作モードが継続される。
 <polling threadの動作フロー>
　図１２は、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７２からパケットデータを参照し、該当データを後続のプロトコル処理部７４へ転送する。ここで、複数のデータがある時は、一括で受信処理してもよい。
　ステップＳ２６でトラヒック頻度計測部１６０は、トラヒック流入頻度を計測し、モード切替制御部１５０に伝達する。
　トラヒック頻度計測部１６０は、ＨＷ割込回数（kernel内に統計情報として記録されている）等により近似的にトラヒック頻度を類推することで、トラヒック頻度を計測してもよい。また、動作モード切替判断ロジックが、図９に記載の単純な閾値判定等の軽い処理の場合には、モード切替制御部１５０に判断を移譲せずに、トラヒック頻度計測部１６０が、動作モードを判断してもよい（その場合は、トラヒック頻度計測部１６０がモード切替制御部１５０の機能を兼ねる）。
　ステップＳ２７でsleep管理部１３０は、トラヒック流入頻度に適合するように、polling threadを短時間スリープ（sleep）させる。例えば、トラヒック流入頻度が５ｕｓであれば、３ｕｓ程度sleepさせる。
　ステップＳ２８でパケット到着監視部１１０は、モード切替制御部から指示された動作モードが「sleep制御モード」であるか否かを判別する。モード切替制御部から指示された動作モードが「sleep制御モード」でない場合（Ｓ２８：Ｎｏ）、上記ステップＳ２５に戻る。
　モード切替制御部から指示された動作モードが「sleep制御モード」である場合（Ｓ２８：Ｙｅｓ）、ステップＳ２９でパケット刈取部１２０は、ring buffer７２に未受信のパケットが存在する否かを判別する。ring buffer７２に未受信のパケットが存在する場合（Ｓ２９：Ｙｅｓ）、上記ステップＳ２５に戻る。
　ここで、上記ステップＳ２５乃至ステップＳ２８のループが常時busy pollのループとなる（図１２の破線囲みｍｍ参照）（これ以外のループは、sleep制御モードのループとなる）。
　ring buffer７２に未受信のパケットが存在しない場合（Ｓ２９：Ｎｏ）、ステップＳ３０でCPU周波数/CPU idle設定部１４０は、polling threadが動作するＣＰＵコアのＣＰＵ周波数を低く設定し、該当ＣＰＵをidle stateにする。
　ステップＳ３１でパケット到着監視部１１０は、receive list１８６から該当ＮＩＣ情報を削除する。
　ステップＳ３２でパケット到着監視部１１０は、該当NICによるＨＷ割込を許可する。
　ステップＳ３３でsleep管理部１３０は、polling threadをsleepさせて本フローの処理を終了する。
［ハードウェア構成］
　上記実施形態に係るサーバ内遅延制御装置１００は、例えば図１３に示すような構成のコンピュータ９００によって実現される。
　図１３は、サーバ内遅延制御装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
　コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。
　ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１乃至図４に示すサーバ内遅延制御装置１００の各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
　例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内遅延制御装置１００として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内遅延制御装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
［適用例］
（kernel内にpolling threadを配置する形態）
　図２に示す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デバイス２２２を介して、Linux（登録商標）とＫＶＭ３０で構成された仮想マシン４０へパケットを伝達する。
　一方、GuestOS７０は、kernel１７１、Ring Buffer５２、およびDriver５３を有し、Driver５３は、virtio-driver５３１を備える。
　Kernel１７１は、サーバ内遅延制御装置１００と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を備える。
　Kernel１７１は、プロトコル処理部７４を介して、パケット処理ＡＰＬ１へパケットを伝達する。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOS９０とGuestOS７０とのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <コンテナ構成への適用例>
　図１５は、コンテナ構成のサーバ仮想化環境における割込モデルに、サーバ内遅延制御システム１０００Ｂを適用した例を示す図である。図１および図１４と同一構成部分には、同一符号を付している。
　図１５に示すように、サーバ内遅延制御システム１０００Ｂは、GuestOS７０をContainer２１１に代えた、コンテナ構成を備える。Container２１１は、vNIC（仮想NIC）２１２を有する。
　コンテナなどの仮想サーバ構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
　以上、kernel内にpolling threadを配置する形態について説明した。次に、user spaceにpolling threadを配置する形態について説明する。
（user spaceにpolling threadを配置する形態）
　図３に示すように、User spaceにpolling thread（サーバ内遅延制御装置１００）を配置した構成例に適用できる。この場合、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内遅延制御システムは、図１６および図１７に示す各構成に適用が可能である。
 <ＶＭ構成への適用例>
　図１６は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における割込モデルに、サーバ内遅延制御システム１０００Ｃを適用した例を示す図である。図１および図１４と同一構成部分には、同一符号を付している。
　図１６に示すように、サーバ内遅延制御システム１０００Ｃは、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS２０を備え、Host OS２０は、Kernel２１およびDriver２３を有する。さらに、サーバ内遅延制御システム１０００Ｃは、Host OS２０に接続されたＨＷのNIC１１、User space６０に配置されたpolling thread（サーバ内遅延制御装置１００）、仮想スイッチ５３、仮想マシン内で動作するGuest OS５０、Host OS２０に接続されUser space６０に配置されたpolling thread（サーバ内遅延制御装置１００）を備える。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、HostOS２０とGuest OS1（５０）とのいずれのOSにおいても、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <コンテナ構成への適用例>
　図１７は、コンテナ構成のサーバ仮想化環境における割込モデルに、サーバ内遅延制御システム１０００Ｄを適用した例を示す図である。図１、図１４、および図１６と同一構成部分には、同一符号を付している。
　図１７に示すように、サーバ内遅延制御システム１０００Ｄは、図１６のGuest OS５０をContainer２１１に代えた、コンテナ構成を備える。Container２１１は、vNIC（仮想NIC）２１２を有する。
　コンテナなどの仮想サーバ構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <ベアメタル構成（非仮想化構成）への適用例>
　本発明は、ベアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <スケールイン／アウト>
　トラヒック量が多く、複数のNICデバイスやNICポートを使用する場合に、これらと関連付けて複数のpolling threadを動作させることで、ＨＷ割込頻度制御を行いつつ、polling threadをスケールイン／アウトすることができる。
 <拡張技術>
　本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラヒックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。
 <アクセラレータ等のＰＣＩデバイス I/Oへの適用>
　ＮＩＣ（Network interface Card）I/Oについて例示したが、本技術は、アクセラレータ（FPGA/GPU等）のＰＣＩデバイスのI/Oに対しても、適用可能である。特に、vRANにおけるＦＥＣ（Forward Error Correction）のアクセラレータへのオフロード結果の返答受信時のpolling等へ活用が可能である。
 <ＣＰＵ以外のプロセッサへの適用>
　本発明は、ＣＰＵ以外にも、ＧＰＵ／ＦＰＧＡ／ＡＳＩＣ（application specific integrated circuit）等のプロセッサに、idle stateの機能がある場合には、同様に適用可能である。
［効果］
　以上説明したように、OSのカーネル空間（kernel space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図２参照）であって、スレッド（polling thread）の動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部１６０と、トラヒック頻度計測部１６０が計測したトラヒック流入頻度に基づいて、スレッドの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替えるモード切替制御部１５０と、を備える。
　従来例では、図８の双方向矢印ｌｌに示すように、パケット流入頻度が閾値Ｔに達すると、sleep制御をしても、sleepする時間が短く、割込オーバーヘッドの方が上回るため、常時busy pollよりも消費電力が高くなる課題があった。
　サーバ内遅延制御装置１００は、モード切替制御部１５０が、トラヒック流入頻度に基づいて、例えばトラヒック流入頻度が所定閾値（図８の閾値Ｔ）の場合に、スレッド（polling thread）の動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替える。これにより、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することができる。具体的には、トラヒック流入頻度に応じて、適するパケット受信モード（sleep制御モード／常時busy pollモード）を動的に切り替えることで、トラヒック流入頻度が疎な間はsleepによる省電力効果を享受し、トラヒック流入頻度が「密」になると、sleepによる省電力効果よりも割込オーバーヘッドの方が大きくなる場合でも、常時busy pollを行うことで、消費電力の悪化を防ぐことができる。
　また、sleep制御内におけるsleep時間等の制御ではなく、「sleep制御モード」と「常時busy pollモード」のモードの切替であることで、下記効果を得ることができる。すなわち、単純busy pollには必要のないsleep制御ロジック等を単純busy pollモードに実装する必要がないので、余計な制御ロジックの演算を省略することができ、消費電力を削減できる可能性がある。また、モードごとに独立したプログラムを作りやすくなるため、各モードに特化した制御を導入しやすくなる。
　また、pollingモデルによりパケットの到着監視および受信処理を行うので、softIRQ競合が発生せず、遅延を小さくできる。また、sleep時にパケットが到着した際は、高優先のhardIRQによりpolling threadを起こすので、sleepによるオーバーヘッドをできる限り抑制することができる。
　また、パケットが到着していない間は、polling threadがsleepし、CPU周波数を低く設定する制御をするため、busy pollingによる消費電力増加を抑制することができる（省電力）。
　また、本発明を、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合に適用することができる。
　また、ユーザ空間（User space）に配置され、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００（図１および図３参照）であって、スレッド（polling thread）の動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部１６０と、トラヒック頻度計測部１６０が計測したトラヒック流入頻度に基づいて、スレッドの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替えるモード切替制御部１５０と、を備える。
　このようにすることで、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することができる。
　また、本発明を、ＤＰＤＫのように、user spaceにpolling threadがある場合に適用することができる。
　また、仮想マシン内で動作するGuest OS（GuestOS７０）（図１４参照）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）（図１４参照）と、インターフェイス部（NIC１１）からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視し、パケット到着有無を確認するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファ（Ring Buffer７２）に保持したパケットを参照し、該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、スレッド（polling thread）の動作モードが、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部１６０と、トラヒック頻度計測部１６０が計測したトラヒック流入頻度に基づいて、スレッドの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替えるモード切替制御部１５０と、を備える。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（GuestOS７０）を備えるサーバについて、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することができる。
　また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS（HostOS９０）（図１４参照）（HostOS２０）（図１６および図１７参照）が、カーネル（Kernel９１）と、Host OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）（図１８参照）と、インターフェイス部（NIC１１）からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視し、パケット到着有無を確認するパケット到着監視部１１０と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部１２０と、カーネル（Kernel２１）により作成される仮想インターフェイスであるtapデバイス２２２（図１４参照）と、を備え、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるサーバ内遅延制御装置１００を備えており、サーバ内遅延制御装置１００は、スレッドの動作モードが、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、トラヒック流入頻度を計測するトラヒック頻度計測部１６０と、トラヒック頻度計測部１６０が計測したトラヒック流入頻度に基づいて、スレッドの動作モードをsleep制御モードと常時busy pollモードとのいずれかに切り替えるモード切替制御部１５０と、を備える。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel１７１）とHost OS（HostOS９０）とを備えるサーバについて、トラヒック流入頻度が「密」の場合における、スリープとスリープ解除の動作を抑制し、低遅延性を達成しつつ、省電力を達成することができる。
　サーバ内遅延制御装置１００（図１～図４参照）において、モード切替制御部１５０は、トラヒック流入頻度が低い領域から所定閾値（図８の閾値Ｔ）に達するまでは、スレッド（polling thread）の動作モードをsleep制御モードに切り替え、トラヒック流入頻度が所定閾値（図８の閾値Ｔ）以上になると常時busy pollモード切り替えることを特徴とする。
　このようにすることにより、図８に示すように、パケット流入頻度低から閾値Ｔまでは、「sleep制御モードを使用すべき領域」（図８の符号ｊｊ参照）では、スレッド（polling thread）の動作モードをsleep制御モードに切り替えるとともに、閾値Ｔ以上は「常時busy pollモードを使用すべき領域」（図８の符号ｋｋ参照）では、常時busy pollモード切り替えることができる。これにより、閾値Ｔ以上のトラヒック流入頻度が「密」の場合には、常時busy pollモード切り替えることで、消費電力を抑制することができる。なお、閾値Ｔは、図９の表に示す切り替え判断ロジックで最適値が選択される。
　サーバ内遅延制御装置１００（図１～図４参照）において、常時busy pollモードの場合、インターフェイス部（NIC１１）からのパケット到着を監視（polling）し、パケット到着有無を確認するパケット到着監視部１１０と、sleep制御モードの場合、パケットが所定期間到着しないときにスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はハードウェア割込（hardIRQ）によりこのスレッド（polling thread）のスリープ解除を行うsleep管理部１３０と、を備える。
　このようにすることにより、常時busy pollモードの場合、パケット到着監視部１１０が、pollingモデルによりパケットの到着監視および受信処理を行うので、softIRQ競合が発生せず、遅延を小さくできる。また、sleep制御モードの場合、sleep管理部１３０が、sleep時にパケットが到着した際は、高優先のhardIRQによりpolling threadを起こすので、sleepによるオーバーヘッドをできる限り抑制することができる。
　なお、上記実施形態では、ＮＡＰＩやＫＢＰのように、kernel内部にpolling threadがある場合について説明したが、polling threadをＤＰＤＫのように、user spaceに配置した形態（図３、図１７参照）をとってもよい。
　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
　１　パケット処理ＡＰＬ（アプリケーション）
　１０　ＨＷ
　１１　NIC（物理NIC）(インターフェイス部)
　２０，９０　Host OS（OS）
　２２，５２，７２　Ring Buffer（リングバッファ）
　５０，７０　Guest OS（OS）
　６０　user space（ユーザスペース）
　７４　プロトコル処理部
　８６，１８６　receive list（ポールリスト）
　９１，１７１　Kernel（カーネル）
　１００　サーバ内遅延制御装置（polling thread）
　１１０　パケット到着監視部
　１２０　パケット刈取部
　１３０　sleep管理部（スリープ管理部）
　１４０　CPU周波数/CPU idle設定部
　１５０　モード切替制御部
　１６０　トラヒック頻度計測部
　２１１　Container
　１０００，１０００Ａ，１０００Ｂ，１０００Ｃ，１０００Ｄ　サーバ内遅延制御システム
　Ｔ　閾値

Claims (9)

  1. 　OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
    　前記スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するトラヒック頻度計測部と、
    　前記トラヒック頻度計測部が計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるモード切替制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  2. 　ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置であって、
    　前記スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するトラヒック頻度計測部と、
    　前記トラヒック頻度計測部が計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるモード切替制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  3. 　サーバ内遅延制御装置であって、
    　仮想マシン内で動作するGuest OSが、
    　カーネルと、
    　前記Guest OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視し、パケット到着有無を確認するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部と、を有し、
    　前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
    　前記サーバ内遅延制御装置は、
    　前記スレッドの動作モードが、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するトラヒック頻度計測部と、
    　前記トラヒック頻度計測部が計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるモード切替制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  4. 　サーバ内遅延制御装置であって、
    　仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
    　カーネルと、
    　前記Host OSを備えるサーバ中のメモリ空間で、前記カーネルが管理するリングバッファと、
    　インターフェイス部からのパケット到着を監視し、パケット到着有無を確認するパケット到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を備え、
    　前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げる前記サーバ内遅延制御装置を備えており、
    　前記サーバ内遅延制御装置は、
    　前記スレッドの動作モードが、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するトラヒック頻度計測部と、
    　前記トラヒック頻度計測部が計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるモード切替制御部と、を備える
    　ことを特徴とするサーバ内遅延制御装置。
  5. 　前記モード切替制御部は、トラヒック流入頻度が低い領域から所定閾値に達するまでは、前記スレッドの動作モードを前記sleep制御モードに切り替え、トラヒック流入頻度が前記所定閾値以上になると前記常時busy pollモード切り替える
    　ことを特徴とする請求項１乃至４のいずれか一項に記載のサーバ内遅延制御装置。
  6. 　前記常時busy pollモードの場合、インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストを監視し、、パケット到着有無を確認するパケット到着監視部と、
    　前記sleep制御モードの場合、パケットが所定期間到着しないときに前記スレッドをスリープさせ、かつ、パケット到着時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ管理部と、を備える
    　ことを特徴とする請求項１または請求項２に記載のサーバ内遅延制御装置。
  7. 　OSのカーネル空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置のサーバ内遅延制御方法であって、
    　前記スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するステップと、
    　計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるステップと、を実行する
    　ことを特徴とするサーバ内遅延制御方法。
  8. 　ユーザ空間に配置され、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内遅延制御装置のサーバ内遅延制御方法であって、
    　前記スレッドの動作モードは、当該スレッドをsleep可能なsleep制御モードと、当該スレッドを常時busy pollingさせる常時busy pollモードと、を有しており、
    　トラヒック流入頻度を計測するステップと、
    　計測した前記トラヒック流入頻度に基づいて、前記スレッドの動作モードを前記sleep制御モードと前記常時busy pollモードとのいずれかに切り替えるステップと、を実行する
    　ことを特徴とするサーバ内遅延制御方法。
  9. 　コンピュータを、請求項１乃至４のいずれか一項に記載のサーバ内遅延制御装置として機能させるためのプログラム。
PCT/JP2022/020051 2022-05-12 2022-05-12 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム Ceased WO2023218596A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP22941676.3A EP4524737A4 (en) 2022-05-12 2022-05-12 Intra-server delay control device and method, and associated program
US18/864,727 US20250328372A1 (en) 2022-05-12 2022-05-12 Server delay control device, server delay control method and program
PCT/JP2022/020051 WO2023218596A1 (ja) 2022-05-12 2022-05-12 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP2024520175A JP7754299B2 (ja) 2022-05-12 2022-05-12 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
CN202280095899.2A CN119173855A (zh) 2022-05-12 2022-05-12 服务器内延迟控制装置、服务器内延迟控制方法以及程序

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
WO2023218596A1 true WO2023218596A1 (ja) 2023-11-16

Family

ID=88730011

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/020051 Ceased WO2023218596A1 (ja) 2022-05-12 2022-05-12 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Country Status (5)

Country Link
US (1) US20250328372A1 (ja)
EP (1) EP4524737A4 (ja)
JP (1) JP7754299B2 (ja)
CN (1) CN119173855A (ja)
WO (1) WO2023218596A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240160468A1 (en) * 2021-03-18 2024-05-16 Nippon Telegraph And Telephone Corporation Server delay control device, server delay control method, and program

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021130828A1 (ja) 2019-12-23 2021-07-01 日本電信電話株式会社 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12001895B2 (en) * 2019-10-08 2024-06-04 Nippon Telegraph And Telephone Corporation Server delay control system, server delay control device, server delay control method, and program

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021130828A1 (ja) 2019-12-23 2021-07-01 日本電信電話株式会社 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NEW API(NAPI, 4 April 2022 (2022-04-04), Retrieved from the Internet <URL:http://lwn.net/2002/0321/a/napi-howto.php3>
See also references of EP4524737A4

Also Published As

Publication number Publication date
US20250328372A1 (en) 2025-10-23
JPWO2023218596A1 (ja) 2023-11-16
JP7754299B2 (ja) 2025-10-15
EP4524737A1 (en) 2025-03-19
CN119173855A (zh) 2024-12-20
EP4524737A4 (en) 2026-03-18

Similar Documents

Publication Publication Date Title
JP7310924B2 (ja) サーバ内遅延制御装置、サーバ、サーバ内遅延制御方法およびプログラム
JP7251648B2 (ja) サーバ内遅延制御システム、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP2025100826A (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
JP2024180507A (ja) サーバおよびプログラム
JP7485101B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7754299B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7816498B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7662062B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7574902B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7852718B2 (ja) サーバ内データ転送装置、データ転送システム、サーバ内データ転送方法およびプログラム
JP2026074185A (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7740368B2 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
JP7709645B2 (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: 22941676

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024520175

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18864727

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022941676

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022941676

Country of ref document: EP

Effective date: 20241212

WWP Wipo information: published in national office

Ref document number: 18864727

Country of ref document: US