WO2023002547A1 - サーバ内データ転送装置、サーバ内データ転送方法およびプログラム - Google Patents

サーバ内データ転送装置、サーバ内データ転送方法およびプログラム Download PDF

Info

Publication number
WO2023002547A1
WO2023002547A1 PCT/JP2021/027049 JP2021027049W WO2023002547A1 WO 2023002547 A1 WO2023002547 A1 WO 2023002547A1 JP 2021027049 W JP2021027049 W JP 2021027049W WO 2023002547 A1 WO2023002547 A1 WO 2023002547A1
Authority
WO
WIPO (PCT)
Prior art keywords
data transfer
data
unit
thread
server
Prior art date
Application number
PCT/JP2021/027049
Other languages
English (en)
French (fr)
Inventor
圭 藤本
奨悟 斎藤
哲朗 中村
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/027049 priority Critical patent/WO2023002547A1/ja
Priority to JP2023536248A priority patent/JPWO2023002547A1/ja
Publication of WO2023002547A1 publication Critical patent/WO2023002547A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt

Definitions

  • the present invention relates to an intra-server data transfer device, an intra-server data transfer method, and a program.
  • NFV Network Functions Virtualization
  • SFC Service Function Chaining
  • a hypervisor environment composed of Linux (registered trademark) and KVM (kernel-based virtual machine) is known as a technology for configuring virtual machines.
  • the Host OS with the KVM module installed (the OS installed on the physical server is called the Host OS) operates as a hypervisor in a memory area called the kernel space, which is different from the user space.
  • the kernel space which is different from the user space.
  • a virtual machine runs in the user space
  • a Guest OS an OS installed on the virtual machine is called a Guest OS
  • a virtual machine running a Guest OS differs from a physical server running a Host OS in that all HW (hardware) including network devices (represented by Ethernet card devices)
  • HW hardware
  • network devices represented by Ethernet card devices
  • Virtio defines data exchange using a queue designed with a ring buffer as a unidirectional transfer transport for transfer data with respect to data input/output such as console, file input/output, and network communication. Then, using the virtio queue specifications, by preparing the number and size of queues suitable for each device when starting the Guest OS, communication between the Guest OS and the outside of the virtual machine can be performed using hardware emulation. It can be realized only by operations by queue without execution.
  • FIG. 19 is a diagram illustrating packet transfer based on an interrupt model in a server virtualization environment configured with a general-purpose Linux kernel (registered trademark) and a VM.
  • the HW 10 has a NIC (Network Interface Card) 11 (physical NIC) (interface), and is constructed by a Host OS 20, a KVM 30 that is a hypervisor that constructs virtual machines, virtual machines (VM1, VM2) 40, and a Guest OS 50.
  • Data transmission/reception communication is performed with the data processing APL (Application) 1 on the user space 60 via the virtual communication channel.
  • the data flow in which the data processing APL1 receives packets from the HW10 is referred to as Rx side reception, and the data flow in which the data processing APL1 transmits packets to the HW10. is called the Tx side transmission.
  • the Host OS 20 has a kernel 21, a Ring Buffer 22, and a Driver 23, and the kernel 21 has a kernel thread vhost-net module 221A, a tap device 222A, and a virtual switch (br) 223A.
  • the tap device 222A is a virtual network kernel device and is supported by software.
  • the virtual machine (VM1) 40 can communicate with the Guest OS 50 and the Host OS 20 via the virtual switch (br) 223A created in the virtual bridge (bridge).
  • the tap device 222A is a device connected to the virtual NIC (vNIC) of the Guest OS 50 created in this virtual bridge.
  • the Host OS 20 copies the configuration information (size of shared buffer queue, number of queues, identifier, start address information for accessing the ring buffer, etc.) built in the virtual machine of Guest OS 50 to the vhost-net module 221A. Then, the information of the end point on the virtual machine side is constructed inside the host OS 20 .
  • This vhost-net module 221A is a kernel-level backend for virtio networking, and can reduce virtualization overhead by moving virtio packet processing tasks from user space to vhost-net module 221A in kernel 21. .
  • the Guest OS 50 has a Guest OS (Guest1) installed on the virtual machine (VM1) and a Guest OS (Guest2) installed on the virtual machine (VM2).
  • Guest OS 50 (Guest1, Guest2) operates inside.
  • Guest OS 50 (Guest 1 ) has kernel 51 , Ring Buffer 52 and Driver 53 , and Driver 53 has virtio-driver 531 .
  • PCI Peripheral Component Interconnect
  • virtio-console for the console
  • virtio-blk for file input/output
  • virtio-blk for the network
  • a device called virtio-net and the corresponding driver of the OS are defined in the virtio queue
  • two data transfer endpoints transmit and receive endpoints
  • the parent-child relationship consists of the virtual machine side (child side) and the Guest OS (parent side).
  • the child side exists as device configuration information in the virtual machine, and requests the parent side for the size of each data area, the number of required end point combinations, and the device type.
  • the parent side allocates and secures memory for a shared buffer queue for storing and transferring the required amount of data according to the request from the child side, and returns its address to the child side so that the child side can access it.
  • All shared buffer queue operations required for data transfer are common in virtio and are executed as agreed upon by both the parent and child sides.
  • both parties agree on the size of the shared buffer queue (that is, it is determined for each device). This makes it possible to operate a queue shared by both the parent side and the child side only by informing the child side of the address.
  • a virtual network device called a virtio-net device consists of three Ring Buffers 52 for transmission, reception, and control.
  • Parent-child communication is realized by writing to the shared buffer queue and buffer update notification, and after writing to the Ring Buffer 52, notifies the other party.
  • the other party uses common operations of virtio to check how much new data is in which shared buffer queue, and takes out the new buffer area. This establishes the transfer of data from the parent to the child or from the child to the parent.
  • the child side When the Guest OS 50 in the virtual machine communicates with the outside, the child side must connect to the outside, and the child side must act as an intermediary between the outside and the parent side to send and receive data.
  • communication between Guest OS 50 and Host OS 20 is one example.
  • the outside is the host OS 20
  • the first method (hereafter referred to as external communication method 1) builds a child-side endpoint in the virtual machine, communicates between the Guest OS 50 and the virtual machine, and communicates with the communication endpoint provided by the Host OS 20 (usually tap/ tun device) inside the virtual machine. With this connection, the following connection is constructed and communication from the Guest OS 50 to the Host OS 20 is realized.
  • the Guest OS 50 operates in a memory area that is a user space that has different privileges from the memory area that is the kernel space in which the tap driver and the host OS 20 operate. Therefore, at least one memory copy occurs in communication from the Guest OS 50 to the Host OS 20 .
  • the second method (hereinafter referred to as external communication method 2) has a technology called vhost-net as a means of solving this problem.
  • vhost-net the configuration information on the parent side (shared buffer queue size, number of queues, identifiers, top address information for accessing the ring buffer, etc.) once built in the virtual machine is transferred to the vhost- It is copied to the net module 221A, and information of the end point on the child side is constructed inside the host.
  • This construction makes it possible to directly operate the shared buffer queue between the Guest OS 50 and the Host OS 20 .
  • the number of copies is practically 0, and the number of copies is reduced by one compared to virtio-net, so data transfer can be realized at a higher speed than external communication method 1.
  • packet transfer processing can be sped up by reducing the number of virtio-net-related memory copies in the Host OS 20 and Guest OS 50 connected by virtio.
  • DPDK is a framework for controlling the NIC (Network Interface Card), which was conventionally performed by the Linux kernel (registered trademark), in user space.
  • the biggest difference from the processing in the Linux kernel is that it has a polling-based reception mechanism called PMD (Pull Mode Driver).
  • PMD Pull Mode Driver
  • PMD a dedicated thread continuously performs data arrival confirmation and reception processing.
  • High-speed packet processing can be achieved by eliminating overhead such as context switches and interrupts.
  • DPDK greatly enhances packet processing performance and throughput, allowing more time for data plane application processing.
  • DPDK exclusively uses computer resources such as CPU (Central Processing Unit) and NIC. For this reason, it is difficult to apply it to applications such as SFC that flexibly switch connections on a module-by-module basis.
  • SPP Soft Patch Panel
  • the SPP omits packet copying in the virtualization layer by preparing a shared memory between VMs so that each VM can directly refer to the same memory space.
  • DPDK is used for packet exchange between the physical NIC and the shared memory to achieve high speed.
  • the SPP can change the packet input destination and output destination by software by controlling the reference destination of memory exchange of each VM. Through this processing, the SPP realizes dynamic connection switching between VMs and between VMs and physical NICs (see Non-Patent Document 2).
  • FIG. 20 is a diagram illustrating packet transfer according to the polling model in the configuration of OvS-DPDK (Open vSwitch with DPDK).
  • the Host OS 20 includes OvS-DPDK 70, which is software for packet processing.
  • a dpdk (PMD) 72 which is a functional unit for connecting to the NIC (DPDK) 11 (physical NIC).
  • the data processing APL 1A has a dpdk (PMD) 2 which is a functional unit that performs polling in the Guest OS 50 section. That is, the data processing APL1A is an APL obtained by modifying the data processing APL1 of FIG. 19 by adding dpdk(PMD)2 to the data processing APL1.
  • packet transfer by polling model enables path operation by GUI in SPP that performs high-speed packet copy between Host OS 20 and Guest OS 50 and between Guest OS 50 with zero copy via shared memory. .
  • FIG. 21 is a schematic diagram of Rx-side packet processing by New API (NAPI) implemented by Linux kernel 2.5/2.6 (see Non-Patent Document 1). The same components as those in FIG. 19 are given the same reference numerals.
  • New API (NAPI) executes data processing APL1 located in user space 60 available to users on a server equipped with OS 70 (for example, Host OS), and is connected to OS 70. Packet transfer is performed between the NIC 11 of the HW 10 and the data processing APL1.
  • OS 70 for example, Host OS
  • OS 70 has kernel 71 , Ring Buffer 72 and Driver 73 , and kernel 71 has protocol processor 74 .
  • the Kernel 71 is a function of the core part of the OS 70 (for example, the host OS), and monitors hardware and manages the execution state of programs on a process-by-process basis.
  • the kernel 71 responds to the request from the data processing APL1 and transmits the request from the HW 10 to the data processing APL1.
  • Kernel 71 processes requests from data processing APL 1 through system calls (“user program operating in non-privileged mode” requests processing to “kernel operating in privileged mode”).
  • Kernel 71 transmits the packet to data processing APL 1 via Socket 75 .
  • Kernel 71 receives packets from data processing APL 1 via Socket 75 .
  • the Ring Buffer 72 is managed by the Kernel 71 and resides in the memory space of the server.
  • the Ring Buffer 72 is a buffer of a fixed size that stores messages output by the Kernel 71 as a log, and is overwritten from the beginning when the upper limit size is exceeded.
  • the Driver 73 is a device driver for monitoring hardware in the kernel 71. Note that the Driver 73 depends on the kernel 71, and if the created (built) kernel source changes, it becomes a different entity. In this case, obtain the corresponding driver source, rebuild it on the OS that uses the driver, and create the driver.
  • the protocol processing unit 74 performs L2 (data link layer)/L3 (network layer)/L4 (transport layer) protocol processing defined by the OSI (Open Systems Interconnection) reference model.
  • Socket 75 is an interface for kernel 71 to communicate between processes. Socket 75 has a socket buffer and does not generate data copy processing frequently.
  • the flow up to establishment of communication via Socket 75 is as follows. 1. The server side creates a socket file that accepts clients. 2. Name the reception socket file. 3. Create a socket queue. 4. Accept the first one of the connections from the client in the socket queue. 5. Create a socket file on the client side. 6. Send a connection request from the client side to the server. 7. On the server side, create a socket file for connection separately from the socket file for reception.
  • the data processing APL 1 can call system calls such as read( ) and write( ) to the kernel 71 .
  • the Kernel 71 receives notification of packet arrival from the NIC 11 by means of a hardware interrupt (hardIRQ) and schedules a software interrupt (softIRQ) for packet processing.
  • the above New API (NAPI) implemented from Linux kernel 2.5/2.6 performs packet processing by software interrupt (softIRQ) after hardware interrupt (hardIRQ) when a packet arrives.
  • FIG. 21 in packet transfer based on the interrupt model, packets are transferred by interrupt processing (see symbol c in FIG. 21), so waiting for interrupt processing occurs and the delay in packet transfer increases. .
  • FIG. 22 is a diagram for explaining the outline of Rx side packet processing by New API (NAPI) in the portion surrounded by the dashed line in FIG. ⁇ Device drivers>
  • the device driver includes a NIC 11 (physical NIC) that is a network interface card, hardIRQ 81 that is a handler that is called and executes requested processing (hardware interrupt) when a processing request is generated from the NIC 11, and netif_rx 82, which is a software interrupt processing functional unit.
  • NIC 11 physical NIC
  • hardIRQ 81 that is a handler that is called and executes requested processing (hardware interrupt) when a processing request is generated from the NIC 11
  • netif_rx 82 which is a software interrupt processing functional unit.
  • softIRQ 83 which is a handler that is invoked by generation of a processing request of netif_rx 82 and executes the requested processing (software interrupt)
  • do_softirq 84 which is a control function unit that performs the substance of the software interrupt (softIRQ)
  • net_rx_action 85 which is a packet processing function unit that receives and executes a software interrupt (softIRQ)
  • a netif_receive_skb 87 and a Ring Buffer 72 that create an sk_buff structure (a structure that allows the Kernel 71 to perceive what is happening with the packet) are arranged.
  • the protocol layer includes ip_rcv 88, arp_rcv 89, etc., which are packet processing functional units.
  • netif_rx82, do_softirq84, net_rx_action85, netif_receive_skb87, ip_rcv88, and arp_rcv89 are program parts (function names) used for packet processing in Kernel71.
  • FIG. 22 [Rx side packet processing operation by New API (NAPI)] Arrows (codes) d to o in FIG. 22 indicate the flow of packet processing on the Rx side.
  • the hardware function unit 11a of the NIC 11 hereinafter referred to as the NIC 11
  • the packet arrives at the Ring Buffer 72 without using the CPU by DMA (Direct Memory Access) transfer. is copied (see symbol d in FIG. 22).
  • This Ring Buffer 72 is a memory space in the server and is managed by the Kernel 71 (see FIG. 21).
  • the Kernel 71 cannot recognize the packet if the NIC 11 just copies the packet that has arrived to the Ring Buffer 72. Therefore, when the packet arrives, the NIC 11 raises a hardware interrupt (hardIRQ) to the hardIRQ 81 (see symbol e in FIG. 22), and the netif_rx 82 executes the following processing, so that the Kernel 71 recognizes the packet.
  • hardIRQ hardware interrupt
  • the hardIRQ 81 surrounded by an ellipse in FIG. 22 represents a handler rather than a functional unit.
  • netif_rx 82 is a function that actually performs processing. Save the information of the net device (net_device) that indicates which device the hardware interrupt belongs to, and prune the queue (refer to the contents of the packet accumulated in the buffer, process the packet, delete the corresponding queue entry from the buffer in consideration of the next processing) is registered (see symbol g in FIG. 22). Specifically, netif_rx 82 uses the driver of NIC 11 to register subsequent queue pruning in poll_list 86 in response to the packets being packed in Ring Buffer 72 (see symbol g in FIG. 22). As a result, the poll_list 86 is registered with the queue reaping information due to the packets stuffed into the Ring Buffer 72 .
  • NIC 11 when the NIC 11 receives a packet, it copies the packet that has arrived to the Ring Buffer 72 by DMA transfer. In addition, NIC 11 raises hardIRQ 81 (handler), netif_rx 82 registers net_device in poll_list 86, and schedules software interrupts (softIRQ). Up to this point, hardware interrupt processing in ⁇ Device driver> in FIG. 22 stops.
  • netif_rx 82 uses the queued information (specifically, the pointer) loaded in poll_list 86 to reap the data stored in Ring Buffer 72 with a software interrupt (softIRQ). (handler) (see symbol h in FIG. 22), and notify do_softirq 84, which is the software interrupt control function unit (see symbol i in FIG. 22).
  • the do_softirq 84 is a software interrupt control function unit that defines each function of software interrupts (there are various types of packet processing, interrupt processing is one of them; interrupt processing is defined). Based on this definition, do_softirq 84 notifies net_rx_action 85, which actually performs software interrupt processing, of the current (corresponding) software interrupt request (see symbol j in FIG. 22).
  • 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 symbol k in FIG. 22), and reaps the packets ( See symbol l in FIG. 22). At this time, net_rx_action 85 continues to reap until poll_list 86 is empty. After that, net_rx_action 85 notifies netif_receive_skb 87 (see symbol m in FIG. 22).
  • the netif_receive_skb 87 creates an sk_buff structure, analyzes the contents of the packet, and forwards the processing to the subsequent protocol processing unit 74 (see FIG. 21) for each type. That is, 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 n in FIG. 22), and for example, if it is L2 The processing is passed to arp_rcv 89 (symbol o in FIG. 22).
  • Non-Patent Document 3 describes an in-server network delay control device (KBP: Kernel Busy Poll).
  • KBP Kernel Busy Poll
  • the KBP constantly monitors packet arrivals through a polling model within the kernel. This suppresses softIRQ and realizes low-delay packet processing.
  • FIG. 23 is an example of video (30 FPS) data transfer.
  • the workload shown in FIG. 23 intermittently transfers data every 30 ms at a transfer rate of 350 Mbps.
  • FIG. 24 is a diagram showing the CPU usage rate used by the busy poll thread in the KBP described in Non-Patent Document 3.
  • FIG. 24 As shown in FIG. 24, in KBP, a kernel thread occupies a CPU core in order to perform busy polling. Even with the intermittent packet reception shown in FIG. 23, the KBP always uses the CPU regardless of whether packets arrive or not, so there is a problem of increased power consumption.
  • FIG. 25 is a diagram showing the configuration of the DPDK system that controls the HW 110 including the accelerator 120.
  • the DPDK system has HW 110 , OS 140 , DPDK 150 which is high-speed data transfer middleware placed on user space 160 , and data processing APL 1 .
  • Data processing APL1 is packet processing performed prior to execution of APL.
  • the HW 110 performs data transmission/reception communication with the data processing APL1.
  • the data flow for receiving packets from HW 110 by data processing APL 1 is referred to as Rx side reception, and the data flow for data processing APL 1 to transmit packets to HW 110 is referred to as Tx side reception. Called send.
  • the HW 110 includes an accelerator 120 and a NIC 130 (physical NIC) for connecting to a communication network.
  • the accelerator 120 is computing unit hardware that performs specific operations at high speed based on inputs from the CPU.
  • the accelerator 120 is a PLD (Programmable Logic Device) such as a GPU (Graphics Processing Unit) or FPGA (Field Programmable Gate Array).
  • the accelerator 120 includes a plurality of cores (core processors) 121, Rx queues 122 and Tx queues 133 that hold data in a first-in, first-out list structure.
  • a part of the processing of the data processing APL1 is offloaded to the accelerator 120 to achieve performance and power efficiency that cannot be achieved by software (CPU processing) alone.
  • a case is assumed in which the accelerator 120 as described above is applied to a large-scale server cluster such as a data center that constitutes NFV (Network Functions Virtualization) or SDN (Software Defined Network).
  • NFV Network Functions Virtualization
  • SDN Software Defined Network
  • the NIC 130 is NIC hardware that implements a NW interface, and includes an Rx queue 131 and a Tx queue 132 that hold data in a first-in, first-out list structure.
  • the NIC 130 is connected to the counterpart device 170 via a communication network, for example, and performs packet transmission/reception.
  • the NIC 130 may be, for example, a SmartNIC, which is a NIC with an accelerator.
  • the SmartNIC is a NIC that can reduce the load on the CPU by offloading load-intensive processing such as IP packet processing that causes a drop in processing performance.
  • the DPDK 150 is a framework for controlling the NIC in the user space 160, and specifically consists of high-speed data transfer middleware.
  • the DPDK 150 has a PMD (Poll Mode Driver) 151 (a driver that can select polling mode or interrupt mode for data arrival), which is a polling-based reception mechanism.
  • PMD 151 Policy Mode Driver
  • a dedicated thread continuously performs data arrival confirmation and reception processing.
  • the DPDK 150 implements a packet processing function in the user space 160 where APL operates, and immediately reaps packets as they arrive from the user space 160 in a polling model, making it possible to reduce packet transfer delays. That is, since the DPDK 150 harvests packets by polling (the CPU is busy polling the queue), there is no waiting and the delay is small.
  • both the interrupt model and polling model packet transfer have the following problems.
  • packets are transferred by software interrupt processing for packet processing by the kernel that receives an event (hardware interrupt) from the HW. Therefore, in the interrupt model, packet transfer is performed by interrupt (software interrupt) processing. is generated, and there is a problem that the delay in packet transfer increases. In this case, if the interrupt process is congested, the waiting delay will increase. For example, as shown in FIG. 19, in packet transfer based on the interrupt model, packets are transferred by interrupt processing (see symbols a and b in FIG. 19). delay increases.
  • NW delays on the order of ms occur due to contention of interrupt processing (softIRQ).
  • the KBP can suppress softIRQs and achieve low-delay packet processing by constantly monitoring packet arrivals in the kernel using the polling model.
  • the kernel thread that constantly monitors the packet arrival monopolizes the CPU core and always uses the CPU time, there is a problem of high power consumption.
  • FIGS. 23 and 24 The relationship between workload and CPU utilization will be described with reference to FIGS. 23 and 24.
  • FIG. 24 As shown in FIG. 24, in KBP, a kernel thread occupies a CPU core in order to perform busy polling. Even with the intermittent packet reception shown in FIG. 23, the KBP always uses the CPU regardless of whether packets arrive or not, so there is a problem of increased power consumption.
  • the DPDK also has the same problems as the KBP described above. ⁇ Problem of DPDK>
  • the kernel thread occupies the CPU core in order to perform polling (busy polling of the queue by the CPU). Therefore, even with intermittent packet reception shown in FIG. , the CPU is always used 100%, so there is a problem that power consumption increases.
  • DPDK realizes a polling model in the user space, so softIRQ conflicts do not occur
  • KBP realizes a polling model in the kernel, so softIRQ conflicts do not occur, enabling low-latency packet transfer.
  • both DPDK and KBP have the problem of wasting CPU resources and increasing power consumption for packet arrival monitoring regardless of packet arrival.
  • the present invention has been made in view of such a background, and an object of the present invention is to reduce the CPU usage rate while maintaining low latency, thereby enabling power saving.
  • a data transfer device within a server that performs data transfer control of an interface unit in a user space
  • an OS comprises a kernel and a buffer with a ring structure in a memory space in a server provided with the OS.
  • a driver that can select polling mode or interrupt mode for data arrival from the interface section
  • a data transfer section that launches a thread that monitors packet arrival using the polling model, and manages data arrival schedule information.
  • a sleep control management unit that distributes the data arrival schedule information to the data transfer unit and performs sleep control of the data transfer unit, wherein the data transfer unit is distributed from the sleep control management unit.
  • the intra-server data transfer device is characterized by putting the thread to sleep based on the received data arrival schedule information, and activating a timer immediately before the data arrival to wake up the thread. .
  • FIG. 1 is a schematic configuration diagram of an intra-server data transfer system according to a first embodiment of the present invention
  • FIG. FIG. 4 is a diagram showing an example of polling thread operation of the intra-server data transfer system according to the first embodiment of the present invention
  • 1 is a schematic configuration diagram of an intra-server data transfer system of Acquisition Example 1 of an intra-server data transfer system according to the first embodiment of the present invention
  • FIG. 3 is a schematic configuration diagram of the intra-server data transfer system of Acquisition Example 2 of the intra-server data transfer system according to the first embodiment of the present invention
  • 10 is a schematic configuration diagram of the intra-server data transfer system of Acquisition Example 3 of the intra-server data transfer system according to the first embodiment of the present invention
  • 7 is a flow chart showing the operation of the sleep control manager when there is a change in data arrival schedule information in the intra-server data transfer system according to the first embodiment of the present invention
  • 7 is a flow chart showing the operation of the sleep control management section when the data transfer section is added/removed in the intra-server data transfer system according to the first embodiment of the present invention
  • 4 is a flow chart showing the operation of a sleep control section of the data transfer section of the intra-server data transfer system according to the first embodiment of the present invention
  • 4 is a flow chart showing the operation of a data arrival monitoring unit of the data transfer unit of the intra-server data transfer system according to the first embodiment of the present invention
  • 4 is a flow chart showing the operation of a Tx data transfer section of the data transfer section of the intra-server data transfer system according to the first embodiment of the present invention
  • 7 is a flow chart
  • FIG. 7 is a schematic configuration diagram of an intra-server data transfer system according to a second embodiment of the present invention
  • 13 is a flow chart showing the operation of a data arrival monitoring unit of the data transfer unit of the intra-server data transfer system according to the second embodiment of the present invention
  • FIG. 10 is a diagram showing an example in which an in-server data transfer system is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel and a VM configuration
  • FIG. 10 is a diagram showing an example in which an intra-server data transfer system is applied to an interrupt model in a container-configured server virtualization environment
  • FIG. 11 is a schematic configuration diagram of an intra-server data transfer system according to a third embodiment of the present invention
  • 1 is a hardware configuration diagram showing an example of a computer realizing functions of an intra-server data transfer device of an intra-server data transfer system according to an embodiment of the present invention
  • FIG. FIG. 2 is a diagram illustrating packet transfer based on an interrupt model in a server virtualization environment with a general-purpose Linux kernel and a VM configuration
  • FIG. 4 is a diagram for explaining packet transfer according to a polling model in the OvS-DPDK configuration
  • FIG. 4 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. 22 is a diagram for explaining an overview of Rx-side packet processing by New API (NAPI) in a portion surrounded by a dashed line in FIG. 21;
  • FIG. 10 is a diagram showing an example of data transfer of video (30 FPS);
  • FIG. 10 is a diagram showing the CPU usage rate used by busy poll threads in the KBP described in Non-Patent Document 3;
  • 1 is a diagram showing the configuration of a DPDK system that controls HW with an accelerator;
  • FIG. 1 is a schematic configuration diagram of an intra-server data transfer system according to the first embodiment of the present invention.
  • the intra-server data transfer system 1000 includes HW 110 , OS 140 , and intra-server data transfer device 200 that is high-speed data transfer middleware placed in user space 160 .
  • a data processing APL 1 and a data flow time slot management scheduler 2 are further arranged in the user space 160 .
  • Data processing APL1 is a program executed in user space 160 .
  • the data flow time slot management scheduler 2 transmits schedule information to the data processing APL 1 (see symbol q in FIG. 1).
  • the data flow time slot management scheduler 2 also transmits data arrival schedule information to the sleep control management unit 210 (described later) (see symbol r in FIG. 1).
  • the HW 110 performs data transmission/reception communication with the data processing APL1.
  • the data flow in which data processing APL1 receives packets from HW 110 is referred to as Rx-side reception, and the data flow in which data processing APL1 transmits packets to HW 110 is referred to as Tx-side transmission.
  • the HW 110 includes an accelerator 120 and a NIC 130 (physical NIC) for connecting to a communication network.
  • Accelerator 120 is computing unit hardware such as a GPU or FPGA.
  • the accelerator 120 includes a plurality of cores (core processors) 121, Rx queues 122 and Tx queues 123 that hold data in a first-in, first-out list structure.
  • cores core processors
  • Rx queues 122 Rx queues 122
  • Tx queues 123 that hold data in a first-in, first-out list structure.
  • a part of the processing of the data processing APL1 is offloaded to the accelerator 120 to achieve performance and power efficiency that cannot be achieved by software (CPU processing) alone.
  • the NIC 130 is NIC hardware that implements the NW interface, and includes an Rx queue 131 and a Tx queue 132 that hold data in a first-in, first-out list structure.
  • the NIC 130 is connected to the counterpart device 170 via a communication network, for example, and performs packet transmission/reception.
  • the OS 140 is Linux (registered trademark), for example.
  • the OS 140 has a high resolution timer 141 that manages the timer in more detail than the kernel timer.
  • the high-resolution timer 141 uses, for example, Linux (registered trademark) hrtimer. hrtimer allows you to specify the time at which the callback will occur using the unit ktime_t.
  • the high-resolution timer 141 notifies the sleep control unit 221 of the data transfer unit 220, which will be described later, of the data arrival timing at the specified time (see symbol u in FIG. 1).
  • the intra-server data transfer device 200 is a DPDK for controlling the NIC in the user space 160, and specifically consists of high-speed data transfer middleware.
  • the intra-server data transfer device 200 includes a sleep control management unit 210 and a data transfer unit 220 .
  • the intra-server data transfer device 200 has a PMD 151 (a driver that can select polling mode or interrupt mode for data arrival) (see FIG. 25) like the DPDK arranged on the user space 160 .
  • the PMD 151 is a driver that can select data arrival in polling mode or interrupt mode, and a dedicated thread continuously performs data arrival confirmation and reception processing.
  • the sleep control management unit 210 manages the data arrival schedule and performs sleep control of the data transfer unit 220 in accordance with the data arrival timing.
  • the sleep control management unit 210 collectively performs sleep/activation timing control of each data transfer unit 220 (see symbol t in FIG. 1).
  • the sleep control management unit 210 manages data arrival schedule information, distributes the data arrival schedule information to the data transfer unit 220, and performs sleep control of the data transfer unit 220.
  • FIG. The sleep control manager 210 includes a data transfer manager 211 , a data arrival schedule manager 212 , and a data arrival schedule distributor 213 .
  • the data transfer unit management unit 211 holds information such as the number of data transfer units 220 and process ID (PID: Process IDentification) as a list.
  • the data transfer unit management unit 211 transmits information such as the number of data transfer units 220 and process IDs to the data transfer unit 220 in response to a request from the data arrival schedule distribution unit 213 .
  • the data arrival schedule management unit 212 manages data arrival schedules.
  • the data arrival schedule management unit 212 acquires data arrival schedule information from the data flow time slot management scheduler 2 (see symbol r in FIG. 1).
  • the data arrival schedule management unit 212 receives a change notification of the data arrival schedule information from the data flow time slot management scheduler 2 and detects the change of the data arrival schedule information.
  • the data arrival schedule management unit 212 detects by snooping data containing data arrival schedule information (see FIGS. 4 and 5).
  • the data arrival schedule management unit 212 transmits data arrival schedule information to the data arrival schedule distribution unit 213 (see symbol s in FIG. 1).
  • the data arrival schedule distribution unit 213 acquires information such as the number of data transfer units 220 and process IDs from the data transfer unit management unit 211 .
  • the data arrival schedule distribution unit 213 distributes data arrival schedule information to each data transfer unit 220 (see symbol t in FIG. 1).
  • the data transfer unit 220 spawns a polling thread that monitors packet arrivals using a polling model.
  • the data transfer unit 220 puts the thread to sleep based on the data arrival schedule information distributed from the sleep control management unit 210, and activates a timer immediately before the arrival of the data to wake up the thread. conduct.
  • the data transfer unit 220 cancels the sleep of the relevant thread by a hardware interrupt when canceling the sleep, in case the packet is received at an unintended timing by the timer. Sleep/Wake-up will be described later under [Sleep/Wake-up].
  • the data transfer section 220 includes a sleep control section 221 , a data arrival monitoring section 222 , an Rx data transfer section 223 (packet harvesting section), and a Tx data transfer section 224 .
  • the data arrival monitoring unit 222 and the Rx data transfer unit 223 are functional units on the Rx side
  • the Tx data transfer unit 224 is a functional unit on the Tx side.
  • ⁇ sleep control unit 221> Based on the data arrival schedule information from the sleep control management unit 210, the sleep control unit 221 performs sleep control to stop data arrival monitoring and sleep when no data arrives. Sleep control unit 221 holds the data arrival schedule information received from data arrival schedule distribution unit 213 .
  • the sleep control unit 221 sets a data arrival timing timer for the data arrival monitoring unit 222 (see symbol v in FIG. 1). That is, the sleep control unit 221 sets a timer so that the data arrival monitoring unit 222 can start polling immediately before data arrival.
  • the sleep control unit 221 uses hrtimers or the like, which is the high-resolution timer 141 owned by the Linux kernel, and activates the data arrival monitoring unit 222 at the hardware interrupt trigger when the timer is activated by the hardware clock. good too.
  • FIG. 2 is a diagram showing an example of the polling thread operation of the intra-server data transfer device 200.
  • the vertical axis indicates the CPU usage rate [%] of the CPU core used by the polling thread, and the horizontal axis indicates time.
  • 3 shows a polling thread operation example due to packet arrival corresponding to the data transfer example of video (30 FPS) in which packets are intermittently received shown in FIG.
  • the data transfer unit 220 puts the polling thread to sleep based on the data arrival schedule information received from the sleep control management unit 210 (see symbol w in FIG. 3). , the sleep is canceled by a hardware interrupt (hardIRQ) (see symbol w in FIG. 3).
  • symbol y in FIG. 3 indicates fluctuations in the wiring voltage due to congested use of the core CPU (core processor).
  • the data arrival monitoring unit 222 is activated immediately before data arrives according to the data arrival schedule information managed by the sleep control unit 221 .
  • the data arrival monitoring unit 222 monitors the Rx queues 122 and 131 of the accelerator 120 or the NIC 130 and confirms whether or not data has arrived.
  • the data arrival monitoring unit 222 monopolizes the CPU core to monitor whether data has arrived or not by polling, regardless of whether data has arrived or not. By the way, if this is an interrupt model, the delay described in the prior art in FIG. delay) occurs.
  • the feature of this embodiment is that the sleep control of the polling model is performed on the Rx side.
  • the data arrival monitoring unit 222 cuts the queues stored in the Rx queues 122 and 131 (refers to the contents of the packets accumulated in the buffers, and processes the packets). , delete the corresponding queue entry from the buffer in consideration of the next processing), and transfer to the Rx data transfer unit 223 .
  • the Rx data transfer unit 223 transfers the received data to the data processing APL1. As with the Tx data transfer unit 224, it operates only when data arrives, so the CPU is not wasted.
  • the Tx data transfer unit 224 stores the received data in the Tx queues 123 and 132 of the accelerator 120 or NIC 130 .
  • the Tx data transfer unit 224 is activated by inter-process communication when the data processing APL1 sends out data, and returns to CPU idle when the data transfer ends. no.
  • the data transfer unit 220 puts the thread to sleep based on the data arrival schedule information received from the sleep control unit 221, and wakes it from sleep at the timing of a timer.
  • ⁇ Normal time> Based on data arrival timing scheduling information (data arrival schedule information), the data transfer unit 220 activates a timer immediately before data arrival, and wakes up a data arrival monitoring unit thread of the data transfer unit 220 .
  • hr_timer which is a standard feature of the Linux kernel, when the timer expires, a timer hardware interrupt is activated, and the data arrival monitoring unit 222 wakes up a thread.
  • An example of data arrival schedule information acquisition in the intra-server data transfer system according to this embodiment will be described.
  • An example of a data flow with a fixed data arrival schedule is signal processing in a RAN (Radio Access Network).
  • a MAC scheduler of MAC4 (described later) manages data arrival timing by time division multiplexing.
  • vRAN virtual RAN
  • vDU virtual distributed unit
  • DPDK data transfer unit
  • ⁇ data arrival schedule information acquisition from MAC scheduler> obtained directly from MAC scheduler
  • ⁇ data arrival schedule information acquisition by snooping FAPI P7> obtained by snooping FAPI P7 IF
  • ⁇ acquiring data arrival schedule information by snooping CTI> obtained by snooping O-RAN CTI
  • FIG. 3 is a schematic configuration diagram of an intra-server data transfer system of Acquisition Example 1.
  • Acquisition example 1 is an example applied to a vDU system.
  • the same components as those in FIG. 1 are denoted by the same reference numerals, and descriptions of overlapping portions are omitted.
  • the intra-server data transfer system 1000A of acquisition example 1 further includes PHY (High) (PHYsical) 3, MAC (Medium Access Control) 4, and RLC (Radio Link Control) in user space 160. ) 5 and are placed.
  • PHY High
  • MAC Medium Access Control
  • RLC Radio Link Control
  • the sleep control management unit 210 of the intra-server data transfer system 1000A modifies the MAC scheduler of MAC4 and acquires data arrival schedule information from MAC4 (see symbol z in FIG. 3).
  • vDU the example applied to the vDU system
  • the present invention may be applied not only to vDU but also to vRAN system such as vCU.
  • FIG. 4 is a schematic configuration diagram of an intra-server data transfer system of Acquisition Example 2.
  • Acquisition example 2 is an example applied to a vCU system.
  • the same components as those in FIG. 3 are denoted by the same reference numerals, and descriptions of overlapping portions are omitted.
  • FAPI FAPI P7 6
  • FIG. 4 in the intra-server data transfer system 1000B of Acquisition Example 2, FAPI (FAPI P7) 6 is arranged between PHY (High) 3 and MAC 4 in user space 160 .
  • the FAPI 6 is shown inside the server data transfer device 200 for notational reasons, the FAPI 6 is arranged outside the server data transfer device 200 .
  • FAPI 6 is an IF (interface) that exchanges data schedule information and the like for connecting PHY (High) 3 and MAC 4 defined by SCF (Small Cell Forum) (see symbol aa in FIG. 4).
  • the sleep control management unit 210 of the intra-server data transfer system 1000B snoops the FAPI 6 and then acquires the data arrival schedule information (see symbol bb in FIG. 4).
  • FIG. 5 is a schematic configuration diagram of an intra-server data transfer system of Acquisition Example 3.
  • Acquisition example 3 is an example applied to a vCU system.
  • the same components as those in FIG. 3 are denoted by the same reference numerals, and descriptions of overlapping portions are omitted.
  • a transmission device 173 is arranged outside the user space 160 .
  • a transmission device 173 is a transmission device defined in the O-RAN community.
  • MAC 4 of user space 160 and transmission device 173 are connected via CTI (Collaborative Transport Interface) 7 .
  • CTI 7 is an IF that exchanges data schedule information and the like with transmission equipment defined in the O-RAN community (see symbol cc in FIG. 5).
  • the sleep control management unit 210 of the intra-server data transfer system 1000C snoops CTI7 and then acquires data arrival schedule information (see symbol dd in FIG. 5).
  • FIG. 6 is a flow chart showing the operation of the sleep control manager 210 when the data arrival schedule information is changed.
  • Step S10 enclosed by a broken line in FIG. 6 represents an external factor for starting the operation of sleep control management unit 210 (in the present specification, a broken line enclosed in a flow chart represents an external factor for starting operation).
  • the data flow time slot management scheduler 2 when there is a change in the data arrival schedule information, notifies the data arrival schedule management unit 212 of the sleep control management unit 210 of the change (See symbol r in FIG. 1).
  • the data arrival schedule management unit 212 (see FIG. 1) of the sleep control management unit 210 detects by snooping data containing data arrival schedule information.
  • the data arrival schedule manager 212 (see FIG. 1) of the sleep control manager 210 acquires data arrival schedule information from the data flow time slot management scheduler 2 (see FIG. 1).
  • the data arrival schedule management unit 212 transmits the data arrival schedule information to the data arrival schedule distribution unit 213 (see FIG. 1).
  • step S13 the data arrival schedule distribution unit 213 of the sleep control management unit 210 acquires information such as the number of data transfer units 220 (see FIG. 1) and process IDs from the data transfer unit management unit 211 (see FIG. 1). do.
  • step S14 the data arrival schedule distribution unit 213 distributes the data arrival schedule information to each data transfer unit 220 (see FIG. 1), and ends the processing of this flow.
  • FIG. 7 is a flow chart showing the operation of the sleep control management unit 210 when the data transfer unit 220 is added/removed.
  • step S20 [external factor] when the data transfer unit 220 (see FIG. 1) is added/reduced, the operation system of this system, the maintenance operator, etc. may Information such as the number of data transfer units 220 and process IDs is set in the management unit 211 (see FIG. 1).
  • step S21 the data transfer unit management unit 211 of the sleep control management unit 210 holds information such as the number of data transfer units 220 and process IDs as a list.
  • step S22 the data transfer unit management unit 211 transmits information such as the number of data transfer units 220 and process ID in response to a request from the data arrival schedule distribution unit 213, and ends the process of this flow.
  • the operation of the sleep control management unit 210 has been described above. Next, the operation of the data transfer section 220 will be described.
  • FIG. 8 is a flow chart showing the operation of the sleep control section 221 of the data transfer section 220.
  • the sleep control unit 221 (see FIG. 1) of the data transfer unit 220 holds the data arrival schedule information received from the data arrival schedule delivery unit 213 (see FIG. 1) of the sleep control management unit 210.
  • FIG. 1 the sleep control unit 221 (see FIG. 1) of the data transfer unit 220 holds the data arrival schedule information received from the data arrival schedule delivery unit 213 (see FIG. 1) of the sleep control management unit 210.
  • the data arrival timing managed by the sleep control management unit 210 (see FIG. 1) and the actual data arrival timing are constantly changing. There may be differences. In this case, the difference from the data arrival timing is stored in the data transfer unit 220, and if the difference data is constant, the sleep control management unit 210 may correct the constant difference time. (Details will be described later in FIGS. 11 and 12).
  • step S32 the sleep control unit 221 (see FIG. 1) of the data transfer unit 220 sets a data arrival timing timer for the data arrival monitoring unit 222 (see FIG. 1). That is, the sleep control unit 221 sets a timer so that the data arrival monitoring unit 222 can start polling immediately before data arrival.
  • the high-resolution timer 141 such as hrtimers (registered trademark) possessed by the Linux kernel (registered trademark) is used, and data is generated at the hardware interrupt trigger when the timer is activated by the hardware clock.
  • the arrival monitoring unit 222 may be activated.
  • the operation of the sleep control unit 221 has been described above.
  • ⁇ Rx side> and ⁇ Tx side> operations of the data transfer unit 220 will be described.
  • the present invention has a feature that the operation differs between ⁇ Rx side> and ⁇ Tx side>.
  • FIG. 9 is a flow chart showing the operation of the data arrival monitoring unit 222 of the data transfer unit 220. As shown in FIG. In step S41, the data arrival monitoring unit 222 (see FIG. 1) of the data transfer unit 220 is activated immediately before data arrives according to the data arrival schedule information managed by the sleep control unit 221 (see FIG. 1).
  • a hardware interrupt is activated at the time of data reception, and this hardware interrupt handler
  • the data arrival monitoring unit 222 may be activated within the same. This method is effective when data arrives at a timing that deviates from the data arrival schedule managed by the sleep control management unit 210 .
  • step S42 the data arrival monitoring unit 222 monitors the Rx queues 122 and 131 (see FIG. 1) of the accelerator 120 or NIC 130 to check whether data has arrived. At this time, regardless of whether data arrives or not, the CPU core is monopolized to monitor whether or not data has arrived by polling. If this is an interrupt model, the delay described in the prior art of FIG. 22 (that is, when softIRQ conflicts with other softIRQ, waiting occurs for execution of softIRQ, NW delay of ms order caused by this waiting) occurs.
  • the feature of this embodiment is that the sleep control of the polling model is performed on the Rx side.
  • step S43 the data arrival monitoring unit 222 determines whether or not data has arrived in the Rx queues 122 and 131.
  • step S44 the data arrival monitoring unit 222 harvests the data (queue) stored in the Rx queues 122 and 131 (removes the packets accumulated in the buffer). The content is referred to, and the corresponding queue entry is deleted from the buffer in consideration of the processing to be performed next), and is transferred to the Rx data transfer unit 223 (see FIG. 1). If no data arrives in the Rx queues 122 and 131 (S43: No), the process returns to step S42.
  • the Rx data transfer unit 223 transfers the received data to the data processing APL1 (see FIG. 1). Like the Tx data transfer unit 224 (see FIG. 1), which will be described later, the Rx data transfer unit 223 operates only when data arrives, so the CPU is not wasted.
  • step S46 the sleep control management unit 210 (see FIG. 1) puts the data arrival monitoring unit 222 (see FIG. 1) to sleep when no data arrives after a certain period specified by the operator. End the processing of this flow.
  • FIG. 10 is a flow chart showing the operation of the Tx data transfer section 224 of the data transfer section 220.
  • the data processing APL1 transfers data to the data transfer section 220 of the intra-server data transfer device 200 (see FIG. 1).
  • step S51 the Tx data transfer unit 224 of the data transfer unit 220 stores the received data in the Tx queues 123 and 132 (see FIG. 1) of the accelerator 120 or NIC 130 (see FIG. 1), and executes the process of this flow. Finish.
  • the Tx data transfer unit 224 is activated by inter-process communication when the data processing APL1 sends out data, and returns to CPU idle when the data transfer ends. It is not wasted. The operation of the data transfer unit 220 has been described above.
  • step S31 the correspondence when there is a certain time difference between the data arrival schedule grasped by the sleep control management unit 210 and the data arrival schedule that actually arrives will be described. It is a supplementary description of step S31 in FIG.
  • This embodiment assumes a use case in which a data arrival schedule such as RAN is predetermined. Since the RAN system (APL side) does not allow data arrival with an irregular time difference, it is excluded.
  • FIG. 11 is a flow chart showing the operation of the data transfer unit 220 when there is a difference in the data arrival schedule.
  • the data arrival monitoring unit 222 (see FIG. 1) of the data transfer unit 220 monitors the Rx queues 122 and 131 (see FIG. 1) of the accelerator 120 or the NIC 130, and monitors data from the data arrival schedule to the actual data arrival. is recorded in a memory (not shown).
  • step S62 the data arrival monitoring unit 222 (see FIG. 1) sends the data arrival schedule of ⁇ T to the sleep control unit 221 (see FIG. 1) when there is a data arrival difference of ⁇ T consecutively a plurality of times. Communicate progress.
  • the term “multiple consecutive times” is arbitrarily set by the system operator.
  • step S63 the sleep control unit 221 (see FIG. 1) of the data transfer unit 220 receives the notification that the data arrival schedule is advanced by ⁇ T, delays the data arrival schedule by ⁇ T, and executes this flow. Finish processing. As a result, it is possible to correct the schedule when the data arrival schedule is early for a certain period of time.
  • FIG. 12 is a flow chart showing the operation of the data transfer unit 220 when there is a difference in the data arrival schedule.
  • the data arrival monitoring unit 222 (see FIG. 1) of the data transfer unit 220 monitors the Rx queues 122 and 131 (see FIG. 1) of the accelerator 120 or the NIC 130, and performs the first polling when data arrival monitoring is started. If the data has already arrived at , it is recorded in a memory (not shown). A supplementary explanation will be given.
  • the data arrival monitoring unit 222 is activated immediately before data arrives (see the process of step S32 in FIG. 8).
  • step S72 the data arrival monitoring unit 222 notifies the sleep control unit 221 (see FIG. 1) to delay the data arrival schedule by a minute time ⁇ S when data has already arrived at the start of polling for a plurality of consecutive times. do.
  • the schedule is adjusted little by little by repeatedly delaying ⁇ S, which is arbitrarily set by the operator.
  • step S73 the sleep control unit 221 receives the notification that the data arrival schedule should be advanced by ⁇ S, advances the data arrival schedule by ⁇ S, and ends the processing of this flow.
  • ⁇ S the time correction of ⁇ S
  • the server data transfer device 200 is arranged on the user space 160 .
  • the data transfer unit 220 of the intra-server data transfer device 200 bypasses the kernel, and when a packet arrives at the ring-structured buffer (the accelerator 120 or the NIC 130, it uses DMA (Direct Memory Access) to It is possible to refer to a ring-configured buffer created in the memory space managed by the DPDK. That is, the intra-server data transfer device 200 does not use the ring buffer (Ring Buffer 72) (see FIG. 22) or the poll list (Ring Buffer 72) (see FIG. 22) within the kernel.
  • DMA Direct Memory Access
  • the polling thread constantly monitors a ring-structured buffer (mbuf; a ring-structured buffer in which the PMD 151 copies data by DMA) created in the memory space managed by the DPDK. can be grasped instantaneously (that is, it is a polling model, not an interrupt model).
  • a ring-structured buffer mbuf; a ring-structured buffer in which the PMD 151 copies data by DMA
  • the intra-server data transfer device 200 has the following features regarding the polling thread wake-up method.
  • the intra-server data transfer device 200 wakes up the polling thread with a timer based on the scheduling information of the data arrival timing (data arrival schedule information) for a workload whose data arrival timing is determined.
  • the intra-server data transfer device 200B (see FIG. 17) of the third embodiment, which will be described later, provides a polling thread in the kernel and wakes up the polling thread with a hardware interrupt trigger from the NIC 11 .
  • the operation of the intra-server data transfer device 200 will be supplementarily explained.
  • ⁇ Normal operation: polling mode> the polling thread of the user space 160 monitors the ring buffer developed in the memory space from the accelerator 120 or NIC 130 (see FIG. 1).
  • the PMD 151 (see FIG. 25) of the intra-server data transfer device 200 is a driver that can select data arrival in polling mode or interrupt mode.
  • mbuf exists in the memory space, data is copied to this ring-structured buffer mbuf by DMA.
  • a polling thread of the user space 160 monitors this buffer mbuf of the ring structure. Therefore, the in-server data transfer device 200 does not use the poll_list prepared by the kernel.
  • the normal operation has been described above. Next, the operation of the unexpected interrupt mode will be described.
  • the intra-server data transfer device 200 has a driver (hardIRQ) so that a hardware interrupt (hardIRQ) can be issued from the accelerator 120 or the NIC 130 (see FIG. 1) when data arrives while the polling thread is sleeping.
  • a hardware interrupt By changing the mode of the PMD 151), when data arrives at the accelerator 120 or the NIC 130, a hardware interrupt can be activated and the polling thread can be awakened.
  • the driver (PMD 151) of the intra-server data transfer device 200 has two modes, the polling mode and the interrupt mode.
  • FIG. 13 is a schematic configuration diagram of an intra-server data transfer system according to the second embodiment of the present invention.
  • the intra-server data transfer system 1000D includes HW 110, OS 140, and intra-server data transfer device 200A, which is high-speed data transfer middleware arranged in user space 160.
  • FIG. The intra-server data transfer device 200A is composed of high-speed data transfer middleware, like the intra-server data transfer device 200 of FIG.
  • the intra-server data transfer device 200A includes a sleep control management unit 210 and a data transfer unit 220A.
  • the data transfer unit 220A further includes a CPU frequency/CPU idle control unit 225 (CPU frequency control unit, CPU idle control unit) in addition to the configuration of the data transfer unit 220 in FIG.
  • a CPU frequency/CPU idle control unit 225 performs control to vary the CPU operating frequency and CPU idle setting.
  • the CPU frequency/CPU idle control unit 225 of the polling thread activated by the hardware interrupt handler sets the CPU operating frequency of the CPU core used by the polling thread to set low compared to
  • the kernel can change the operating frequency of the CPU core by setting the governor. Can be set lower.
  • the CPU idle setting depends on the CPU model. Note that if the CPU core has enabled the CPU idle setting, it can also be canceled.
  • FIG. 14 is a flow chart showing the operation of the data arrival monitor 222 of the data transfer unit 220A. Portions that perform the same processing as in the flowchart shown in FIG.
  • the data arrival monitoring unit 222 (see FIG. 13) is activated immediately before data arrives. Restore the operating frequency of the CPU core to be used (increase the CPU operating frequency of the CPU core). Also, the CPU frequency/CPU idle control unit 225 restores the CPU idle state (depending on CPU architecture such as C-State) setting, and proceeds to step S42.
  • the CPU frequency/CPU idle control unit 225 is used by the data transfer unit 220A in step S82. Set the operating frequency of the CPU core to be low. In addition, the CPU frequency/CPU idle control unit 225 sets the CPU idle state (depending on the CPU architecture such as C-State), sets the corresponding CPU core to the CPU idle setting, and ends the processing of this flow.
  • the data transfer section 220A is provided with the CPU frequency/CPU idle control section 225, and together with the sleep control of the data arrival monitoring section 222, the setting of the CPU frequency/CPU idle state is performed. By doing so, it is also possible to achieve further power saving. Note that the process of lowering the CPU frequency setting and the process of dropping to the sleep state may be executed at the same time. Also, sleep may be performed after confirming that the packet transfer process is completed.
  • the intra-server data transfer devices 200 and 200A may be intra-server data transfer devices that start a thread for monitoring packet arrival using a polling model in the Kernel, and the OS is not limited. Moreover, it is not limited to being under a server virtualization environment. Therefore, the intra-server data transfer systems 1000 to 1000D are applicable to each configuration shown in FIGS. 15 and 16. FIG.
  • FIG. 15 is a diagram showing an example in which the in-server data transfer system 1000E is applied to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration. 1, 13 and 19 are denoted by the same reference numerals.
  • the intra-server data transfer system 1000E includes an HW 10, a HostOS 20, intra-server data transfer devices 200 and 200A, which are high-speed data transfer middleware arranged in a user space 160, virtual It has a switch 184 and a Guest OS 70 .
  • the server includes a Host OS 20 on which a virtual machine and an external process formed outside the virtual machine can operate, and a Guest OS 70 that operates within the virtual machine.
  • the Host OS 20 identifies which device the Ring Buffer 22 (see FIG. 19) managed by the Kernel 91 and the hardware interrupt (hardIRQ) from the NIC 11 belong to in the memory space in the server comprising the Kernel 91 and the Host OS 20.
  • a poll_list 86 for registering information of net devices to be displayed
  • a vhost-net module 221A see FIG. 19
  • a tap device 222A see FIG. 19
  • FIG. 19 a virtual interface created by the kernel 91.
  • a virtual switch (br) 223A see FIG. 19).
  • the Guest OS 70 is a memory space in the server that includes the Kernel 181, the Driver 73, and the Guest OS 70.
  • server data transfer devices 200 and 200A are arranged on user space 160 . Therefore, like the DPDK, the data transfer unit 220 of the intra-server data transfer devices 200 and 200A can bypass the kernel and refer to the ring-structured buffer. That is, the intra-server data transfer devices 200 and 200A do not use the ring buffer (Ring Buffer 72) (see FIG. 22) or the poll list (Ring Buffer 72) (see FIG. 22) within the kernel.
  • the data transfer unit 220 bypasses the kernel and can refer to a ring-structured buffer (Ring Buffer 72) (mbuf; a ring-structured buffer in which the PMD 151 copies data by DMA). It is possible to grasp (ie the polling model, not the interrupt model).
  • FIG. 16 is a diagram showing an example in which the intra-server data transfer system 1000B is applied to an interrupt model in a container-configured server virtualization environment.
  • the intra-server data transfer system 1000F has a container configuration with a Guest OS 180 and a Container 210A instead of the OS.
  • Container 210A has vNIC (virtual NIC) 211A.
  • Intra-server data transfer devices 200 and 200A are arranged in user space 160 .
  • the present invention can be applied to a non-virtualized system such as a pair metal configuration.
  • a system with a non-virtualized configuration it is possible to achieve both low delay and power saving by performing sleep control by timer control that considers data arrival timing.
  • packet transfer can be performed with reduced delay in the server without altering the APL.
  • a high-speed packet transfer processing function unit in a network system that must guarantee the data arrival timing such as a TAS (Time Aware Shaper) in a TSN (Time Sensitive Network). It is also possible to apply It is possible to achieve both low delay and power saving in a network system with a fixed data arrival schedule.
  • TAS Time Aware Shaper
  • TSN Time Sensitive Network
  • the intra-server data transfer devices 200 and 200A are arranged in the user space 160.
  • FIG. in the third embodiment instead of the in-server data transfer devices 200 and 200A arranged in the user space 160, the in-server data transfer device 200B that arranges polling threads in the kernel and performs sleep control is provided in the kernel.
  • FIG. 17 is a schematic configuration diagram of an intra-server data transfer system according to the third embodiment of the present invention.
  • the same components as those in FIGS. 1, 13 and 21 are denoted by the same reference numerals, and descriptions of overlapping portions are omitted.
  • This embodiment is an example applied to packet processing by New API (NAPI) implemented by Linux kernel 2.5/2.6.
  • NAPI New API
  • the intra-server data transfer system 1000G includes a HW 10, an OS 70, and an intra-server data transfer device 200B arranged within the Kernel 71 of the OS 70. More specifically, the data transfer unit 220 of the intra-server data transfer device 200B exists only inside the kernel 71, and the sleep control management unit 210 of the intra-server data transfer device 200B is located either in the user space 160 or inside the kernel 71. It is sufficient if it exists (the sleep control management unit 210 may be placed either inside the user space 160 or inside the kernel 71).
  • FIG. 17 shows an example in which the data transfer unit 220 and the sleep control management unit 210 (that is, the intra-server data transfer device 200B) are arranged inside the kernel 71 .
  • the in-server data transfer devices 200 and 200A arranged on the space 160 become unnecessary (in this case, general-purpose operation can be performed).
  • a mode is also included in which the in-server data transfer devices 200 and 200A are arranged in the in-server data transfer system and the in-server data transfer devices 200 and 200A are adaptively not used).
  • the reason why the intra-server data transfer devices 200 and 200A are unnecessary will be described. In other words, software interrupts that cause delay problems occur only inside the kernel 71 when DPDK is not used. do. For this reason, data can be transferred to the data processing APL1 at high speed even without the intra-server data transfer devices 200 and 200A on the user space 160.
  • the OS 70 includes the Kernel 71 and the memory space in the server that includes the OS 70.
  • the Ring Buffer 22 (see FIG. 19) managed by the Kernel 71 and the network that indicates which device the hardware interrupt (hardIRQ) from the NIC 11 belongs to.
  • a poll_list 86 (see FIG. 22) for registering device information, a vhost-net module 221A (see FIG. 19) which is a kernel thread, a tap device 222A (see FIG. 19) which is a virtual interface created by the kernel 91, a virtual and a switch (br) 223A (see FIG. 19).
  • the data transfer unit 220 is arranged in the Kernel 71 of the OS 70.
  • the data transfer unit 220 of the intra-server data transfer device 200B has a data arrival monitoring unit 222 (see FIG. 1) for monitoring data arrival from the interface unit (NIC 11).
  • the unit copies the arriving data to the memory space by DMA (Direct Memory Access) without using the CPU, and arranges this data by a ring-structured buffer.
  • the data arrival monitoring unit 222 activates a thread for monitoring packet arrival using a polling model, and detects the arrival of data by monitoring the ring-configured buffer.
  • the OS is a kernel (Kernel 71) and a ring buffer (Ring Buffer 72) managed by the kernel in a memory space in the server provided with the OS. and a poll list (poll_list 86) (see FIG. 22) for registering net device information indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC 11) belongs to, and the kernel Inside, it spawns a thread that monitors packet arrivals using a polling model.
  • kernel Kernel 71
  • Ring Buffer 72 ring buffer
  • poll list 86 for registering net device information indicating which device the hardware interrupt (hardIRQ) from the interface unit (NIC 11) belongs to, and the kernel Inside, it spawns a thread that monitors packet arrivals using a polling model.
  • the data transfer unit 220 of the intra-server data transfer device 200B refers to the data arrival monitoring unit 222 that monitors the poll list and, if a packet has arrived, refers to the packet held in the ring buffer.
  • the Rx data transfer unit (packet harvesting unit) 223 that performs harvesting to delete the corresponding queue entry from the ring buffer based on the next processing, and the polling thread that sleeps if the packet does not arrive for a predetermined period of time.
  • a sleep control unit 221 that causes the thread (polling thread) to sleep and cancels the sleep by a hardware interrupt (hardIRQ) of this thread (polling thread) when a packet arrives.
  • hardIRQ hardware interrupt
  • the server data transfer device 200B stops the packet processing software interrupt (softIRQ), which is the main cause of NW delay, and the data arrival monitoring unit 222 of the server data transfer device 200B A thread for monitoring arrival is executed, and the Rx data transfer unit (packet harvesting unit) 223 performs packet processing according to the polling model (without softIRQ) when a packet arrives. Then, the sleep control unit 221 puts the polling thread to sleep when the packet does not arrive for a predetermined period of time, so that the polling thread sleeps when the packet does not arrive. The sleep control unit 221 cancels sleep by a hardware interrupt (hardIRQ) when a packet arrives.
  • softIRQ packet processing software interrupt
  • the intra-server data transfer system 1000G includes an intra-server data transfer device 200B having a polling thread in the kernel. Wake up the polling thread with the trigger.
  • the data transfer unit 220 is characterized by being woken up by a timer when a polling thread is provided in the kernel.
  • the intra-server delay control device 200B can achieve both low delay and power saving by performing sleep management of the polling thread that performs packet transfer processing.
  • FIG. 18 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the intra-server data transfer devices 200 and 200A.
  • Computer 900 has CPU 901 , ROM 902 , RAM 903 , HDD 904 , communication interface (I/F) 906 , input/output interface (I/F) 905 , and media interface (I/F) 907 .
  • the CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls each part of the intra-server data transfer devices 200, 200A, and 200B shown in FIGS.
  • the ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, a program depending on the hardware of the computer 900, and the like.
  • the CPU 901 controls an input device 910 such as a mouse and keyboard, and an output device 911 such as a display via an input/output I/F 905 .
  • the CPU 901 acquires data from the input device 910 and outputs the generated data to the output device 911 via the input/output I/F 905 .
  • a GPU Graphics Processing Unit
  • a GPU may be used together with the CPU 901 as a processor.
  • the HDD 904 stores programs executed by the CPU 901 and data used by the programs.
  • Communication I/F 906 receives data from other devices via a communication network (for example, NW (Network) 920) and outputs it to CPU 901, and transmits data generated by CPU 901 to other devices via the communication network. Send to device.
  • NW Network
  • the media I/F 907 reads programs or data stored in the recording medium 912 and outputs them to the CPU 901 via the RAM 903 .
  • the CPU 901 loads a program related to target processing from the recording medium 912 onto the RAM 903 via the media I/F 907, and executes the loaded program.
  • the recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductor memory tape medium, a semiconductor memory, or the like. is.
  • the CPU 901 of the computer 900 executes a program loaded on the RAM 903 to The functions of the internal data transfer device 100 are realized. Data in the RAM 903 is stored in the HDD 904 .
  • the CPU 901 reads a program related to target processing from the recording medium 912 and executes it. In addition, the CPU 901 may read a program related to target processing from another device via the communication network (NW 920).
  • the in-server data transfer device 200 performs data transfer control of the interface unit (accelerator 120, NIC 130) in the user space, and the OS (OS 70) is the kernel (Kernel 171) and the server having the OS A ring buffer (mbuf; a ring structure buffer in which the PMD 151 copies data by DMA) in the memory space inside, and a driver (which can select polling mode or interrupt mode for data arrival from the interface unit (accelerator 120, NIC 130) PMD 151), a data transfer unit 220 that launches a polling thread that monitors packet arrival using a polling model, a data arrival schedule information that manages data arrival schedule information, and a data arrival a sleep control management unit (sleep control management unit 210) that distributes schedule information and performs sleep control of the data transfer unit 220; Based on this, the thread is put to sleep, and just before the arrival of data, a timer is activated to wake up the thread.
  • the OS is the kernel (Kernel 171) and the server having
  • the sleep control management unit 210 collectively performs sleep/activation timing control of each data transfer unit 220 in order to perform sleep control of a plurality of data transfer units in accordance with data arrival timing. .
  • the sleep control management unit 210 When data arrives, it bypasses the kernel in polling mode and transfers packets with low delay to reduce delay.
  • power saving is achieved by stopping data arrival monitoring and sleeping when no data arrives. As a result, both low delay and power saving can be achieved by performing sleep control by timer control in consideration of data arrival timing.
  • the intra-server data transfer device 200 can achieve low latency by implementing the intra-server data transfer delay using a polling model rather than an interrupt model. That is, in the in-server data transfer device 200, the data transfer unit 220 arranged in the user space 160 can bypass the kernel and refer to the ring-structured buffer like the DPDK. By constantly monitoring the buffer of this ring structure with the polling thread, it is possible to instantly grasp the arrival of packets (this is a polling model, not an interrupt model).
  • the CPU usage rate can be reduced while maintaining low latency, and power saving can be achieved. That is, the problem of wasteful use of CPU resources in the polling model can be resolved by implementing sleep control by timer control in consideration of data arrival timing, thereby achieving both low delay and power saving.
  • the Guest OS (Guest OS 70) running in the virtual machine is a kernel (Kernel 171) and a ring buffer (mbuf; ring-structured buffer in which the PMD 151 copies data by DMA) in the memory space in the server equipped with the Guest OS.
  • a driver (PMD 151) that can select data arrival from the interface unit (accelerator 120, NIC 130) in polling mode or interrupt mode, and a protocol processing unit 74 that performs protocol processing of packets that have been pruned.
  • the data transfer unit 220 launches a thread (polling thread) that monitors packet arrival using a polling model, manages the data arrival schedule information, and distributes the data arrival schedule information to the data transfer unit 220.
  • a sleep control management unit (sleep control management unit 210) that performs sleep control of the data transfer unit 220; is put to sleep, and a timer is started immediately before data arrives to wake up the thread and perform sleep cancellation.
  • the host OS (Host OS 20) on which the virtual machine and the external process formed outside the virtual machine can operate is a kernel (Kernel 91) and a ring buffer (mbuf; PMD 151 is a DMA ), a driver (PMD 151) that can select data arrival from the interface unit (accelerator 120, NIC 130) in polling mode or interrupt mode, and a virtual a tap device 222A, which is an interface; a data transfer unit 220 that launches a polling thread that monitors packet arrival using a polling model; a sleep control management unit (sleep control management unit 210) that distributes data arrival schedule information and performs sleep control of the data transfer unit 220; It is characterized by putting a thread to sleep based on data arrival schedule information, and activating a timer immediately before data arrival to wake up the thread and perform sleep cancellation.
  • the CPU usage rate can be reduced while maintaining low latency for a server equipped with a kernel (Kernel 191) and a host OS (Host OS 20), It is possible to achieve power saving.
  • Kernel 191 a kernel
  • Host OS 20 a host OS
  • the OS (OS70) consists of a kernel (Kernel171), a ring buffer (Ring Buffer72) managed by the kernel in a memory space in the server provided with the OS, and an interface unit (NIC11 ) for registering net device information indicating which device the hardware interrupt (hardIRQ) from thread), manages the data arrival schedule, manages the data arrival schedule information, distributes the data arrival schedule information to the data transfer unit 220, and performs sleep control of the data transfer unit 220.
  • the data transfer unit 220 includes a data arrival monitoring unit 222 that monitors the poll list and a ring buffer if a packet has arrived.
  • the sleep control management unit 210 that refers to the packets held in the a sleep control unit (sleep control unit 221) that puts the polling thread to sleep based on the data arrival schedule information and releases the sleep by a hardware interrupt (hardIRQ) when the sleep is released; , provided.
  • the intra-server data transfer device 200B realizes the data transfer delay in the server by the polling model instead of the interrupt model, thereby achieving low delay.
  • the CPU usage rate can be reduced while maintaining low latency, and power saving can be achieved. That is, the problem of wasteful use of CPU resources in the polling model can be resolved by implementing sleep control by timer control in consideration of data arrival timing, thereby achieving both low delay and power saving.
  • the data transfer unit 220 Based on the data arrival schedule information received from the sleep control management unit 210, the data transfer unit 220 puts the polling thread to sleep, and when the sleep is canceled, a hardware interrupt (hardIRQ) is generated. Wake up. As a result, in addition to the effects described above, effects (1) and (2) are obtained.
  • the polling thread in the intra-server data transfer device 200 operates as a kernel thread and monitors packet arrival in polling mode.
  • a kernel thread (polling thread) that monitors packet arrivals sleeps while no packets arrive. When no packet arrives, the CPU is not used by sleep, so power saving can be achieved.
  • sleep release is characterized in that it is not triggered by a timer that has a timer, but by a hardIRQ handler. If the traffic load is known in advance, for example, if 30 mssleep is known like the workload transfer rate shown in FIG. 23, the hardIRQ handler may wake up at this timing.
  • the in-server data transfer device 200B can achieve both low delay and power saving by performing sleep management of the polling thread that performs packet transfer processing.
  • the in-server data transfer device 200A is characterized by having a CPU frequency setting unit (CPU frequency/CPU idle control unit 225) that sets the CPU operating frequency of the CPU core used by the thread to be low during sleep.
  • CPU frequency setting unit CPU frequency/CPU idle control unit 225
  • the intra-server data transfer device 200A dynamically varies the CPU operating frequency according to the traffic. , the power saving effect can be enhanced.
  • the intra-server data transfer device 200A is characterized by comprising a CPU idle setting unit (CPU frequency/CPU idle control unit 225) for setting the CPU idle state of the CPU core used by the thread to the power saving mode during sleep. .
  • a CPU idle setting unit CPU frequency/CPU idle control unit 225
  • the intra-server data transfer device 200A dynamically changes the CPU idle state (power saving function according to the CPU model, such as changing the operating voltage) according to the traffic, thereby further saving power. Power efficiency can be enhanced.
  • each of the above configurations, functions, processing units, processing means, etc. may be realized in hardware, for example, by designing a part or all of them with an integrated circuit.
  • each configuration, function, etc. described above may be realized by software for a processor to interpret and execute a program for realizing each function.
  • Information such as programs, tables, files, etc. that realize each function is stored in memory, hard disk, SSD (Solid State Drive) and other recording devices, IC (Integrated Circuit) cards, SD (Secure Digital) cards, optical discs, etc. It can be held on a recording medium.

Landscapes

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

Abstract

インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置（２００）であって、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部（２２０）と、データ到着スケジュール情報を管理し、データ転送部（２２０）に対して、データ到着スケジュール情報を配信してデータ転送部（２２０）のスリープ制御を行うsleep制御管理部（２１０）と、を備え、データ転送部（２２０）は、sleep制御管理部（２１０）から配信されたデータ到着スケジュール情報をもとに、スレッドをスリープさせるとともに、データ到着の直前にタイマを発動させて、スレッドを起こすスリープ解除を行う。

Description

サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
　本発明は、サーバ内データ転送装置、サーバ内データ転送方法およびプログラムに関する。
　ＮＦＶ（Network Functions Virtualization：ネットワーク機能仮想化）による仮想化技術の進展などを背景に、サービス毎にシステムを構築して運用することが行われている。また、上記サービス毎にシステムを構築する形態から、サービス機能を再利用可能なモジュール単位に分割し、独立した仮想マシン（ＶＭ：Virtual Machineやコンテナなど）環境の上で動作させることで、部品のようにして必要に応じて利用し運用性を高めるといったＳＦＣ（Service Function Chaining）と呼ばれる形態が主流となりつつある。
　仮想マシンを構成する技術としてLinux（登録商標）とＫＶＭ（kernel-based virtual machine）で構成されたハイパーバイザー環境が知られている。この環境では、ＫＶＭモジュールが組み込まれたHost OS（物理サーバ上にインストールされたＯＳをHost OSと呼ぶ）がハイパーバイザーとしてカーネル空間と呼ばれるユーザ空間とは異なるメモリ領域で動作する。この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にGuest OS（仮想マシン上にインストールされたＯＳをGuest OSと呼ぶ）が動作する。
　Guest OSが動作する仮想マシンは、Host OSが動作する物理サーバとは異なり、（イーサネット（登録商標）カードデバイスなどに代表される）ネットワークデバイスを含むすべてのＨＷ（hardware）が、ＨＷからGuest OSへの割込処理やGuest OSからハードウェアへの書き込みに必要なレジスタ制御となる。このようなレジスタ制御では、本来物理ハードウェアが実行すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がHost OS環境に比べ、低いことが一般的である。
　この性能劣化において、特にGuest OSから自仮想マシン外に存在するHost OSや外部プロセスに対して、ＨＷの模倣を削減し、高速かつ統一的なインターフェイスにより通信の性能と汎用性を向上させる技術がある。この技術として、virtioというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにLinux（登録商標）を始め、FreeBSD（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている（特許文献１，２参照）。
　virtioでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換をキューのオペレーションにより定義している。そして、virtioのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをGuest OS起動時に用意することにより、Guest OSと自仮想マシン外部との通信を、ハードウェアエミュレーションを実行せずにキューによるオペレーションだけで実現することができる。
［割込モデルによるパケット転送（汎用VM構成の例）］
　図１９は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。
　ＨＷ１０は、NIC（Network Interface Card）１１（物理NIC）(インターフェイス部)を有し、Host OS２０、仮想マシンを構築するハイパーバイザーであるＫＶＭ３０、仮想マシン（ＶＭ１，ＶＭ２）４０、およびGuest OS５０により構築された仮想通信路を経由してuser space（ユーザスペース）６０上のデータ処理ＡＰＬ（Application）１との間でデータ送受信の通信を行う。以下の説明において、図１９の太矢印に示すように、データ処理ＡＰＬ１が、ＨＷ１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、データ処理ＡＰＬ１が、ＨＷ１０にパケットを送信するデータの流れをＴｘ側送信と称する。
　Host OS２０は、kernel２１、Ring Buffer２２、およびDriver２３を有し、kernel２１は、kernel threadであるvhost-netモジュール２２１Ａと、tapデバイス２２２Ａと、仮想スイッチ(br)２２３Ａと、を有する。
　tapデバイス２２２Ａは、仮想ネットワークのカーネルデバイスであり、ソフトウェアでサポートされている。仮想マシン（ＶＭ１）４０は、仮想ブリッジ(bridge)に作成される仮想スイッチ(br)２２３Ａを介してGuest OS５０とHost OS２０が通信できる。tapデバイス２２２Ａは、この仮想ブリッジに作成されるGuest OS５０の仮想NIC（vNIC）と繋がるデバイスである。
　Host OS２０は、Guest OS５０の仮想マシン内で構築された構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をvhost-netモジュール２２１Ａにコピーし、仮想マシン側の端点の情報をHost OS２０内部に構築する。このvhost-netモジュール２２１Ａは、virtioネットワーキング用のカーネルレベルのバックエンドであり、virtioパケット処理タスクをユーザ領域（ユーザ空間）からkernel２１のvhost-netモジュール２２１Ａに移すことで仮想化のオーバーヘッドを低減できる。
　Guest OS５０は、仮想マシン（ＶＭ１）上にインストールされたGuest OS（Guest１）と、仮想マシン（ＶＭ２）上にインストールされたGuest OS（Guest２）と、を有し、仮想マシン（ＶＭ１，ＶＭ２）４０内でGuest OS５０（Guest１，Guest２）が動作する。Guest OS５０として、Guest１を例に取ると、Guest OS５０（Guest１）は、kernel５１、Ring Buffer５２、およびDriver５３を有し、Driver５３は、virtio-driver５３１を備える。
　具体的には、ＰＣＩ（Peripheral Component Interconnect）デバイスとして仮想マシン内にコンソール、ファイル入出力、ネットワーク通信それぞれに対しvirtioデバイスが存在し（コンソールはvirtio-console、ファイル入出力はvirtio-blk、ネットワークはvirtio-netと呼ばれるデバイスとそれに対応するＯＳが持つドライバがvirtioキューで定義されている）、Guest OS起動時に、Guest OSと相手側とのデータの受け渡し端点（送受信端点）を２つ作り、データ送受信の親子関係を構築する。多くの場合、親子関係は仮想マシン側（子側）とGuest OS（親側）で構成する。
　子側は仮想マシン内のデバイスの構成情報として存在し、それぞれのデータ領域のサイズと必要とする端点の組み合わせの個数、デバイスの種別を親側に要求する。親側は子側の要求に従い、必要な分のデータを貯蓄し受け渡すための共有バッファキューのためのメモリを割り当て確保し、子側がアクセスできるようにそのアドレス番地を子側に返す。データの受け渡しに必要とされる共有バッファキューのオペレーションについては、virtioではすべて共通であり、親側、子側両方合意済みとして実行される。さらに共有バッファキューの大きさも両方合意済みとする（つまりデバイスごとに決まっている）。これにより、子側にアドレスを伝えるだけで、親側、子側の双方が共有するキューを操作することが可能となる。
　virtioにおいて用意する共有バッファキューは単一方向用として用意されるため、例えば、virtio-netデバイスと呼ばれる仮想ネットワークデバイスでは送信用、受信用、コントロール用の３つのRing Buffer５２で構成される。親と子の通信は、共有バッファキューへの書き込みとバッファ更新通知により実現し、Ring Buffer５２に書き込んだ後、相手側に通知する。相手側は通知を受けると、どの共有バッファキューにどの程度新規のデータが入っているのかをvirtioの共通オペレーションを利用して確認し、新規のバッファ領域を取り出す。これにより、親から子または子から親へのデータの受け渡しが成立する。
　以上のように、親子でお互いデータ交換用のRing Buffer５２とそれぞれのリングバッファ用のオペレーション方法（virtioで共通）を共有することにより、ハードウェアエミュレーションを必要としない、Guest OS５０と外部との通信を実現する。これにより、従来のハードウェアエミュレーションに比べ、Guest OS５０と外部とのデータの送受信を高速に実現することが可能である。
　仮想マシン内のGuest OS５０が外部と通信する場合は、子側が外部と接続し、子側が外部と親側の中継役としてデータを送受信する必要がある。例えば、Guest OS５０とHost OS２０間の通信がその例の１つである。ここで、外部をHost OS２０とした場合、既存の通信方法として２パターン存在する。
　第１の方法（以下、外部通信方式１と呼ぶ）は、仮想マシン内に子側の端点を構築し、Guest OS５０と仮想マシン間の通信と、Host OS２０が提供する通信端点（通常、tap／tunデバイスと呼ばれる）を、仮想マシン内で接続する。この接続により以下のとおりの接続を構築し、Guest OS５０からHost OS２０への通信を実現する。
　このとき、Guest OS５０はtapドライバやHost OS２０が動作するカーネル空間というメモリ領域とは異なる権限を持つユーザ空間であるメモリ領域で動作している。このため、Guest OS５０からHost OS２０への通信には最低１回メモリコピーが発生してしまう。
　第２の方法（以下、外部通信方式２と呼ぶ）は、これを解決する手段として、vhost-netという技術が存在する。vhost-netでは一度仮想マシン内で構築された親側の構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をHost OS２０内部のvhost-netモジュール２２１Ａにコピーし、子側の端点の情報をホスト内部に構築する。この構築により、共有バッファキューの操作をGuest OS５０とHost OS２０間で直接実施することを可能とする技術である。これにより、コピーは実質０回で済むようになり、virtio-netに比べ、コピー回数が１回少ない分、外部通信方式１と比較し、より高速にデータ転送が実現できる。
　このように、virtioで接続されたHost OS２０とGuest OS５０において、virtio-net関連のメモリコピー回数を減らすことにより、パケット転送処理を高速化することができる。
　なお、kernel v4.10(2017.2～)以降、tapインターフェイスの仕様変更があり、tapデバイスから挿入されたパケットは、tapデバイスへパケットコピーを行った処理と同一コンテキスト内で完結されるようになった。これにより、ソフトウェア割込（softIRQ）の発生がなくなった。
［ポーリングモデルによるパケット転送（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）がある。ＳＰＰは、ＶＭ間に共有メモリを用意し、各ＶＭが同じメモリ空間を直接参照できる構成にすることで、仮想化層でのパケットコピーを省略する。また、物理ＮＩＣと共有メモリ間のパケットのやり取りには、ＤＰＤＫを用いて高速化を実現する。ＳＰＰは、各ＶＭのメモリ交換の参照先を制御することで、パケットの入力先、出力先をソフトウェア的に変更することができる。この処理によって、ＳＰＰは、ＶＭ間やＶＭと物理ＮＩＣ間の動的な接続切替を実現する（非特許文献２参照）。
　図２０は、OvS-DPDK（Open vSwitch with DPDK）の構成における、ポーリングモデルによるパケット転送を説明する図である。図１９と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
　図２０に示すように、Host OS２０は、パケット処理のためのソフトウェアであるOvS-DPDK７０を備え、OvS-DPDK７０は、仮想マシン（ここではＶＭ１）に接続するための機能部であるvhost-user７１と、ＮＩＣ（ＤＰＤＫ）１１（物理ＮＩＣ）に接続するための機能部であるdpdk(PMD)７２と、を有する。
　また、データ処理ＡＰＬ１Ａは、Guest OS５０区間においてポーリングを行う機能部であるdpdk(PMD)２を具備する。すなわち、データ処理ＡＰＬ１Ａは、図１９のデータ処理ＡＰＬ１にdpdk(PMD)２を具備させて、データ処理ＡＰＬ１を改変したＡＰＬである。
　ポーリングモデルによるパケット転送は、DPDKの拡張として、共有メモリを介してゼロコピーでHost OS２０とGuest OS５０間、および、Guest OS５０間のパケットコピーを高速に行うＳＰＰにおいて、ＧＵＩにより経路操作を可能とする。
［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７１は、ＮＩＣ１１からのパケット到着の知らせを、ハードウェア割込（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８２は、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を抑止し、低遅延なパケット処理を実現する。
　図２３は、映像（３０ＦＰＳ）のデータ転送例である。図２３に示すワークロードは、転送レート３５０Ｍｂｐｓで、３０ｍｓごとに間欠的にデータ転送を行っている。
　図２４は、非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。
　図２４に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図２３に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
　次に、ＤＰＤＫシステムについて説明する。
［ＤＰＤＫシステム構成］
　図２５は、アクセラレータ１２０を備えるＨＷ１１０の制御を行うＤＰＤＫシステムの構成を示す図である。
　ＤＰＤＫシステムは、ＨＷ１１０、ＯＳ１４０、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるＤＰＤＫ１５０、データ処理ＡＰＬ１を有する。
　データ処理ＡＰＬ１は、ＡＰＬの実行に先立って行われるパケット処理である。
　ＨＷ１１０は、データ処理ＡＰＬ１との間でデータ送受信の通信を行う。以下の説明において、図２５に示すように、データ処理ＡＰＬ１が、ＨＷ１１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、データ処理ＡＰＬ１が、ＨＷ１１０にパケットを送信するデータの流れをＴｘ側送信と称する。
　ＨＷ１１０は、アクセラレータ１２０と、通信ネットワークに接続するためのＮＩＣ１３０（物理NIC）と、を備える。
　アクセラレータ１２０は、ＣＰＵからの入力をもとに、特定の演算を高速に行う計算ユニットハードウェアである。アクセラレータ１２０は、具体的には、ＧＰＵ（Graphics Processing Unit）やＦＰＧＡ（Field Programmable Gate Array）等のＰＬＤ（Programmable Logic Device）である。図２５では、アクセラレータ１２０は、複数のＣｏｒｅ（Ｃｏｒｅプロセッサ）１２１、データを先入れ先出しのリスト構造で保持するＲｘキュー（queue：待ち行列）１２２およびＴｘキュー１３３を備える。
　アクセラレータ１２０にデータ処理ＡＰＬ１の処理の一部をオフロードし、ソフトウェア（ＣＰＵ処理）のみでは到達できない性能や電力効率を実現する。
　ＮＦＶ（Network Functions Virtualization）やＳＤＮ（Software Defined Network）を構成するデータセンタなど、大規模なサーバクラスタにおいて、上記のようなアクセラレータ１２０を適用するケースが想定される。
　ＮＩＣ１３０は、ＮＷインターフェイスを実現するＮＩＣハードウェアであり、データを先入れ先出しのリスト構造で保持するＲｘキュー１３１およびＴｘキュー１３２を備える。ＮＩＣ１３０は、例えば通信ネットワークを介して対向装置１７０に接続され、パケット送受信を行う。
　なお、ＮＩＣ１３０は、例えばアクセラレータ付きのＮＩＣであるＳｍａｒｔＮＩＣであってもよい。ＳｍａｒｔＮＩＣは、処理能力が落ちる原因となるＩＰパケット処理など、負荷のかかる処理をオフロードしてＣＰＵの負荷を軽減することができるＮＩＣである。
　ＤＰＤＫ１５０は、ＮＩＣの制御をuser space１６０で行うためのフレームワークであり、具体的にはデータ高速転送ミドルウェアからなる。ＤＰＤＫ１５０は、ポーリングベースの受信機構であるＰＭＤ（Poll Mode Driver）１５１（データ到着をポーリングモードまたは割込モードで選択可能なドライバ）を有する。ＰＭＤ１５１は、データ到達の確認や受信処理を専用のスレッドが継続的に行う。
　ＤＰＤＫ１５０は、ＡＰＬが動作するuser space１６０でパケット処理機能を実現し、user space１６０からpollingモデルでパケット到着時に即時刈取りを行うことで、パケット転送遅延を小さくすることを可能にする。すなわち、ＤＰＤＫ１５０は、polling（ＣＰＵでキューをbusy poll）によりパケットの刈取りを行うため、待ち合わせがなく遅延小である。
特開２０１５－１９７８７４号公報 特開２０１８－３２１５６号公報
New API Intel, ［online］,［令和３年７月５日検索］,インターネット 〈http://lwn.net/2002/0321/a/napi-howto.php3〉 "リソース設定(NIC) ～DPDK入門 第6回～," NTTテクノクロス, ［online］,［令和３年７月５日検索］,インターネット 〈https://www.ntt-tx.co.jp/column/dpdk_blog/190610/〉 Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, "KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server", IEEE CCNC 2021.
　しかしながら、割込モデルとポーリングモデルによるパケット転送のいずれについても下記課題がある。
　割込モデルは、ＨＷからイベント（ハードウェア割込）を受けたkernelがパケット加工を行うためのソフトウェア割込処理によってパケット転送を行う。このため、割込モデルは、割込（ソフトウェア割込）処理によりパケット転送を行うので、他の割込との競合や、割込先ＣＰＵがより優先度の高いプロセスに使用されていると待ち合わせが発生し、パケット転送の遅延が大きくなるといった課題がある。この場合、割込処理が混雑すると、更に待ち合わせ遅延は大きくなる。
　例えば、図１９に示すように、割込モデルによるパケット転送は、割込処理（図１９の符号ａ，ｂ参照）によりパケットの転送を行うため、割込処理の待ち合わせが発生し、パケット転送の遅延が大きくなる。
　割込モデルにおいて、遅延が発生するメカニズムについて補足する。
　一般的なkernelは、パケット転送処理はハードウェア割込処理の後、ソフトウェア割込処理にて伝達される。
　パケット転送処理のソフトウェア割込が発生した際に、下記条件（１）～（３）においては、前記ソフトウェア割込処理を即時に実行することができない。このため、ksoftirqd（ＣＰＵ毎のカーネルスレッドであり、ソフトウェア割込の負荷が高くなったときに実行される）等のスケジューラにより調停され、割込処理がスケジューリングされることにより、ｍｓオーダの待ち合わせが発生する。
（１）他のハードウェア割込処理と競合した場合
（２）他のソフトウェア割込処理と競合した場合
（３）優先度の高い他プロセスやkernel thread（migration thread等）、割込先ＣＰＵが使用されている場合
　上記条件では、前記ソフトウェア割込処理を即時に実行することができない。
　また、New API(NAPI)によるパケット処理についても同様に、図２２の破線囲みｐに示すように、割込処理（softIRQ）の競合に起因し、ｍｓオーダのＮＷ遅延が発生する。
 <ＫＢＰの課題>
　上述したように、ＫＢＰは、kernel内でpollingモデルによりパケット到着を常時監視することで、softIRQを抑止し、低遅延なパケット処理を実現することができる。
　しかし、パケット到着を常時監視するkernel threadがＣＰＵコアを専有し、常にＣＰＵタイムを使用するため、消費電力が高くなる課題がある。図２３および図２４を参照して、ワークロードとＣＰＵ使用率の関係について説明する。
　図２４に示すように、ＫＢＰでは、kernel threadはbusy pollを行うために、ＣＰＵコアを専有する。図２３に示す間欠的なパケット受信であっても、ＫＢＰでは、パケット到着有無に関わらず常にＣＰＵを使用するため、消費電力が大きくなる課題がある。
　ＤＰＤＫについても、上記ＫＢＰと同様の課題がある。
 <ＤＰＤＫの課題>
　ＤＰＤＫでは、kernel threadはpolling（ＣＰＵでキューをbusy poll）を行うために、ＣＰＵコアを専有するので、図２３に示す間欠的なパケット受信であっても、ＤＰＤＫでは、パケット到着有無に関わらず、ＣＰＵを常に１００％使用するため、消費電力が大きくなる課題がある。
　このように、ＤＰＤＫは、user spaceでpollingモデルを実現するためsoftIRQ競合は発生しない、また、ＫＢＰは、kernel内でpollingモデルを実現するためsoftIRQ競合は発生しないので、低遅延なパケット転送が可能である。しかしながら、ＤＰＤＫおよびＫＢＰは、いずれもパケット到着有無に関わらず、常にパケット到着監視のためにＣＰＵリソースを無駄使いし、消費電力が大きくなる課題がある。
　このような背景を鑑みて本発明がなされたのであり、本発明は、低遅延性を維持しつつ、ＣＰＵ使用率を削減して省電力化を可能とすることを課題とする。
　前記した課題を解決するため、インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置であって、OSが、カーネルと、前記OSを備えるサーバ中のメモリ空間のリング構造のバッファと、インターフェイス部からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバと、を有し、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備え、前記データ転送部は、前記スリープ制御管理部から配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるとともに、データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行うことを特徴とするサーバ内データ転送装置とした。
　本発明によれば、低遅延性を維持しつつ、ＣＰＵ使用率を削減して省電力化を図ることができる。
本発明の第１実施形態に係るサーバ内データ転送システムの概略構成図である。 本発明の第１実施形態に係るサーバ内データ転送システムのpolling thread動作例を示す図である。 本発明の第１実施形態に係るサーバ内データ転送システムの取得例１のサーバ内データ転送システムの概略構成図である。 本発明の第１実施形態に係るサーバ内データ転送システムの取得例２のサーバ内データ転送システムの概略構成図である。 本発明の第１実施形態に係るサーバ内データ転送システムの取得例３のサーバ内データ転送システムの概略構成図である。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ到着スケジュール情報に変更があった場合のsleep制御管理部の動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ転送部の増設／減設が発生した場合のsleep制御管理部動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ転送部のsleep制御部動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ転送部のデータ到着監視部動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ転送部のＴｘデータ転送部動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ到着スケジュールに差分がある場合のデータ転送部の動作を示すフローチャートである。 本発明の第１実施形態に係るサーバ内データ転送システムのデータ到着スケジュールに差分がある場合のデータ転送部の動作を示すフローチャートである。 本発明の第２実施形態に係るサーバ内データ転送システムの概略構成図である。 本発明の第２実施形態に係るサーバ内データ転送システムのデータ転送部のデータ到着監視部動作を示すフローチャートである。 汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内データ転送システムを適用した例を示す図である。 コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内データ転送システムを適用した例を示す図である。 本発明の第３実施形態に係るサーバ内データ転送システムの概略構成図である。 本発明の実施形態に係るサーバ内データ転送システムのサーバ内データ転送装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。 汎用Linux kernelおよびＶＭ構成のサーバ仮想化環境における、割込モデルによるパケット転送を説明する図である。 OvS-DPDKの構成における、ポーリングモデルによるパケット転送を説明する図である。 Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるＲｘ側パケット処理の概略図である。 図２１の破線で囲んだ箇所におけるNew API(NAPI)によるＲｘ側パケット処理の概要を説明する図である。 映像（３０ＦＰＳ）のデータ転送例を示す図である。 非特許文献３に記載のＫＢＰにおける、busy poll threadが使用するＣＰＵ使用率を示す図である。 アクセラレータを備えるＨＷの制御を行うＤＰＤＫシステムの構成を示す図である。
　以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるサーバ内データ転送システム等について説明する。
（第１実施形態）
［全体構成］
　図１は、本発明の第１実施形態に係るサーバ内データ転送システムの概略構成図である。図２５と同一構成部分には、同一符号を付している。
　図１に示すように、サーバ内データ転送システム１０００は、ＨＷ１１０と、ＯＳ１４０と、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるサーバ内データ転送装置２００と、を有する。
　user space１６０には、さらに、データ処理ＡＰＬ１と、データフロータイムスロット管理スケジューラ２と、が配置される。データ処理ＡＰＬ１は、user space１６０で実行されるプログラムである。データフロータイムスロット管理スケジューラ２は、データ処理ＡＰＬ１にスケジュール情報を送信する（図１の符号ｑ参照）。また、データフロータイムスロット管理スケジューラ２は、sleep制御管理部２１０（後記）にデータ到着スケジュール情報を送信する（図１の符号ｒ参照）。
　ＨＷ１１０は、データ処理ＡＰＬ１との間でデータ送受信の通信を行う。データ処理ＡＰＬ１が、ＨＷ１１０からのパケットを受け取るデータの流れをＲｘ側受信と称し、データ処理ＡＰＬ１が、ＨＷ１１０にパケットを送信するデータの流れをＴｘ側送信と称する。
　ＨＷ１１０は、アクセラレータ１２０と、通信ネットワークに接続するためのＮＩＣ１３０（物理NIC）と、を備える。
　アクセラレータ１２０は、ＧＰＵやＦＰＧＡ等の計算ユニットハードウェアである。アクセラレータ１２０は、複数のＣｏｒｅ（Ｃｏｒｅプロセッサ）１２１、データを先入れ先出しのリスト構造で保持するＲｘキュー１２２およびＴｘキュー１２３を備える。
　アクセラレータ１２０にデータ処理ＡＰＬ１の処理の一部をオフロードし、ソフトウェア（ＣＰＵ処理）のみでは到達できない性能や電力効率を実現する。
　ＮＩＣ１３０は、ＮＷインターフェイスを実現するＮＩＣハードウェアであり、データを先入れ先出しのリスト構造で保持するＲｘキュー１３１およびＴｘキュー１３２を備える。ＮＩＣ１３０は、例えば通信ネットワークを介して対向装置１７０に接続され、パケット送受信を行う。
　ＯＳ１４０は、例えばLinux（登録商標）である。ＯＳ１４０は、カーネルタイマよりもより詳細にタイマ管理を行う高解像タイマ１４１を備える。高解像タイマ１４１は、例えばLinux（登録商標）のhrtimerを用いる。hrtimerでは、ktime_tという単位を使ってコールバックが発生する時間を指定できる。高解像タイマ１４１は、後記するデータ転送部２２０のsleep制御部２２１に、指定した時間におけるデータ到着タイミングを通知する（図１の符号ｕ参照）。
［サーバ内データ転送装置２００］
　サーバ内データ転送装置２００は、ＮＩＣの制御をuser space１６０で行うためのＤＰＤＫであり、具体的にはデータ高速転送ミドルウェアからなる。
　サーバ内データ転送装置２００は、sleep制御管理部２１０と、データ転送部２２０と、を備える。
　サーバ内データ転送装置２００は、user space１６０上に配置されているＤＰＤＫと同様にＰＭＤ１５１（データ到着をポーリングモードまたは割込モードで選択可能なドライバ）（図２５参照）を有する。ＰＭＤ１５１は、データ到着をポーリングモードまたは割込モードで選択可能なドライバであり、データ到達の確認や受信処理を専用のスレッドが継続的に行う。
 <sleep制御管理部２１０>
　sleep制御管理部２１０は、データ到着スケジュールを管理し、データ到着タイミングに合わせてデータ転送部２２０のsleep制御を行う。
　sleep制御管理部２１０は、各データ転送部２２０のSleep／起動のタイミング制御を一括して行う（図１の符号ｔ参照）。
　sleep制御管理部２１０は、データ到着スケジュール情報を管理し、データ転送部２２０に対して、データ到着スケジュール情報を配信してデータ転送部２２０のスリープ制御を行う。
　sleep制御管理部２１０は、データ転送部管理部２１１と、データ到着スケジュール管理部２１２と、データ到着スケジュール配信部２１３と、を備える。
　データ転送部管理部２１１は、データ転送部２２０の数やプロセスＩＤ（PID：Process IDentification）等の情報を一覧として保有する。
　データ転送部管理部２１１は、データ到着スケジュール配信部２１３からの要請に応じて、データ転送部２２０の数やプロセスＩＤ等の情報をデータ転送部２２０に伝達する。
　データ到着スケジュール管理部２１２は、データ到着スケジュールを管理する。データ到着スケジュール管理部２１２は、データフロータイムスロット管理スケジューラ２から、データ到着スケジュール情報を取得する（図１の符号ｒ参照）。
　データ到着スケジュール管理部２１２は、データ到着スケジュール情報に変更があった場合に、データフロータイムスロット管理スケジューラ２から、データ到着スケジュール情報の変更通知を受け取り、データ到着スケジュール情報の変更を検知する。または、データ到着スケジュール管理部２１２は、データ到着スケジュール情報が含まれるデータをsnoopすることで検知する（図４および図５参照）。
　データ到着スケジュール管理部２１２は、データ到着スケジュール配信部２１３に対して、データ到着スケジュール情報を伝達する（図１の符号ｓ参照）。
　データ到着スケジュール配信部２１３は、データ転送部管理部２１１から、データ転送部２２０の数やプロセスＩＤ等の情報を取得する。
　データ到着スケジュール配信部２１３は、各データ転送部２２０に対して、データ到着スケジュール情報を配信する（図１の符号ｔ参照）。
 <データ転送部２２０>
　データ転送部２２０は、ポーリングモデルを用いてパケット到着を監視するスレッド（polling thread）を立ち上げる。
　データ転送部２２０は、sleep制御管理部２１０から配信されたデータ到着スケジュール情報をもとに、スレッドをスリープ（sleep）させるとともに、データ到着の直前にタイマを発動させて、スレッドを起こすスリープ解除を行う。ここで、データ転送部２２０は、タイマで意図していないタイミングでパケットを受信してしまった際に備えて、スリープの解除時はハードウェア割込により該当スレッドのスリープ解除を行う。スリープ／解除については、[スリープ／解除]により後記する。
　データ転送部２２０は、sleep制御部２２１と、データ到着監視部２２２と、Ｒｘデータ転送部２２３（パケット刈取部）と、Ｔｘデータ転送部２２４と、を備える。
　データ到着監視部２２２およびＲｘデータ転送部２２３は、Ｒｘ側の機能部であり、Ｔｘデータ転送部２２４は、Ｔｘ側の機能部である。
 <sleep制御部２２１>
　sleep制御部２２１は、sleep制御管理部２１０からのデータ到着スケジュール情報をもとに、データの到着がない時はデータ到着監視を止めてsleepするsleep制御を行う。
　sleep制御部２２１は、データ到着スケジュール配信部２１３から受信したデータ到着スケジュール情報を保有する。
　sleep制御部２２１は、データ到着監視部２２２に対して、データ到着タイミングのタイマを設定する（図１の符号ｖ参照）。すなわち、sleep制御部２２１は、データ到着直前に、データ到着監視部２２２がpollingを開始できるようにタイマを設定する。ここで、sleep制御部２２１は、Linux kernelが保有する高解像タイマ１４１であるhrtimers等を利用し、ハードウェアクロックによるタイマ発動時のハードウェア割込契機にデータ到着監視部２２２を起動してもよい。
　図２は、サーバ内データ転送装置２００のpolling thread動作例を示す図である。縦軸は、polling threadが使用するＣＰＵコアのＣＰＵ使用率[％]を示し、横軸は、時間を示す。なお、図３は、図１３に示す間欠的にパケットが受信される映像（３０ＦＰＳ）のデータ転送例に対応するパケット到着によるpolling thread動作例を示している。
　図２に示すように、データ転送部２２０は、sleep制御管理部２１０から受信したデータ到着スケジュール情報をもとに、スレッド（polling thread）をスリープ（sleep）させるとともに（図３の符号ｗ参照）、当該スリープの解除時はハードウェア割込（hardIRQ）によりスリープ解除を行う（図３の符号ｗ参照）。なお、図３の符号ｙはコアＣＰＵ（Ｃｏｒｅプロセッサ）の輻輳使用等による配線電圧の変動である。
 <Ｒｘ側>
　データ到着監視部２２２は、sleep制御部２２１の管理するデータ到着スケジュール情報に従い、データが到着する直前に起動する。
　データ到着監視部２２２は、アクセラレータ１２０またはＮＩＣ１３０のＲｘキュー１２２，１３１を監視し、データ到着有無を確認する。
　データ到着監視部２２２は、デー到着有無に関わらずＣＰＵコアを専有してデータ到着有無をpollingにより監視する。因みに、ここを割込モデルにすると、図２２の従来技術に記載した遅延（すなわち、softIRQが他のsoftIRQと競合する場合、softIRQの実行に関して待合せが発生し、この待合せに起因したｍｓオーダのＮＷ遅延）が発生する。本実施形態では、Ｒｘ側においてpollingモデルのsleep制御にしている点が特徴である。
　データ到着監視部２２２は、Ｒｘキュー１２２，１３１にデータ到着がある場合、Ｒｘキュー１２２，１３１に格納されたキューの刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）、Ｒｘデータ転送部２２３へ転送する。
　Ｒｘデータ転送部２２３は、受信したデータをデータ処理ＡＰＬ１に転送する。Ｔｘデータ転送部２２４と同様に、データ到着時にのみ動作するため、ＣＰＵを無駄に使用することはない。
 <Ｔｘ側>
　Ｔｘデータ転送部２２４は、受信したデータを、アクセラレータ１２０またはＮＩＣ１３０のＴｘキュー１２３，１３２に格納する。
　Ｔｘデータ転送部２２４は、データ処理ＡＰＬ１がデータを送出する際にプロセス間通信により起動され、データ転送が終了するとCPU idleに戻るため、データ到着監視部２２２と異なり、ＣＰＵを無駄に使用することはない。
［スリープ／解除］
　データ転送部２２０は、sleep制御部２２１から受信したデータ到着スケジュール情報をもとに、スレッドをスリープさせるとともに、タイマ契機でスリープ解除する。
 <通常時>
　データ転送部２２０は、データ到着タイミングのスケジューリング情報（データ到着スケジュール情報）をもとに、データ到着の直前にタイマを発動させて、データ転送部２２０のデータ到着監視部スレッドを起こす。例えば、Linux kernel標準搭載機能のhr_timerを使用して、タイマ期限が来た際に、タイマのハードウェア割込を発動し、データ到着監視部２２２がスレッドを起こす。
 <想定外（スケジューリング外にデータ到着があった場合）>
　スケジューリングしているタイミング外にデータ到着があった場合、データ到着監視部２２２のスレッドはsleepしている状態である。また、通常時用のタイマ発動もない。このため、パケット到着時にパケット到着を通知するハードウェア割込を発動させるようにする。
　上述したように、通常時は、polling modeでパケットを常時監視しているので、ハードウェア割込は必要なく、ハードウェア割込の機能は、driver(PMD)で機能停止している。
　ただし、polling threadをsleepさせる際に、万が一スケジューリング外にデータ到着したことを想定し、パケット到着時にハードウェア割込を上げるように、モードを変更しておく。そうすることで、パケット到着時に、ハードウェア割込が上がり、このハードウェア割込ハンドラで、データ到着監視部２２２がスレッドを起こすようにすることができる。
［データ到着スケジュール情報取得例］
　本実施形態に係るサーバ内データ転送システムのデータ到着スケジュール情報取得例について説明する。
　データ到着スケジュールが決まっているデータフロー例として、ＲＡＮ（Radio Access Network）における信号処理が挙げられる。ＲＡＮにおける信号処理は、時分割多重によるデータ到着タイミングをＭＡＣ４（後記）のMAC schedulerが管理する。
　ｖＲＡＮ（virtual RAN），ｖＤＵ（virtual Distributed Unit）の信号処理は、高速データ転送のためにＤＰＤＫを利用することが多い。発明方式を適用することで、MAC schedulerが管理するデータ到着タイミングに合わせて、データ転送部（DPDK PMD等）のsleep制御を行う。
　MAC schedulerが管理するデータ到着タイミングの取得方式として、<MAC schedulerからデータ到着スケジュール情報取得>（MAC Schedulerから直接取得）（図３参照）、<FAPI P7をsnoopしてデータ到着スケジュール情報取得>（FAPI P7 IFのsnoopにより取得）（図４参照）、<CTIをsnoopしてデータ到着スケジュール情報取得>（O-RAN CTIのsnoopにより取得）（図５参照）がある。以下、順に説明する。
 <MAC schedulerからデータ到着スケジュール情報取得>
　図３は、取得例１のサーバ内データ転送システムの概略構成図である。取得例１は、ｖＤＵシステムに適用した例である。図１と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
　図３に示すように、取得例１のサーバ内データ転送システム１０００Ａは、user space１６０には、さらに、ＰＨＹ(High)（PHYsical）３と、ＭＡＣ（Medium Access Control）４と、ＲＬＣ（Radio Link Control）５と、が配置される。
　ＮＩＣ１３０に接続される対抗装置として、ＮＩＣ１３０への受信側にＲＵ（Radio Unit）１７１、ＮＩＣ１３０ｔｏの送信側にｖＣＵ１７２が接続される。
　サーバ内データ転送システム１０００Ａのsleep制御管理部２１０は、ＭＡＣ４のMAC schedulerを改変して、ＭＡＣ４からデータ到着スケジュール情報を取得する（図３の符号ｚ参照）。
　なお、ｖＤＵシステムに適用した例について説明したが、ｖＤＵだけではなく、ｖＣＵ等のｖＲＡＮシステムに適用してもよい。
 <CTIをsnoopしてデータ到着スケジュール情報取得>
　図４は、取得例２のサーバ内データ転送システムの概略構成図である。取得例２は、ｖＣＵシステムに適用した例である。図３と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
　図４に示すように、取得例２のサーバ内データ転送システム１０００Ｂは、user space１６０には、さらに、ＰＨＹ(High)３とＭＡＣ４との間にＦＡＰＩ(FAPI P7)６が配置される。なお、ＦＡＰＩ６は、表記の関係でサーバ内データ転送装置２００の中に描かれているがＦＡＰＩ６は、サーバ内データ転送装置２００の外に配置される。
　ＦＡＰＩ６は、ＳＣＦ（Small Cell Forum）において規定されたＰＨＹ(High)３とＭＡＣ４を接続するデータスケジュール情報等をやり取りするＩＦ（interface）である（図４の符号ａａ参照）。
　サーバ内データ転送システム１０００Ｂのsleep制御管理部２１０は、ＦＡＰＩ６をsnoopしてからデータ到着スケジュール情報を取得する（図４の符号ｂｂ参照）。
 <ＣＴＩ７をsnoopしてデータ到着スケジュール情報取得>
　図５は、取得例３のサーバ内データ転送システムの概略構成図である。取得例３は、ｖＣＵシステムに適用した例である。図３と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
　図５に示すように、取得例３のサーバ内データ転送システム１０００Ｃは、user space１６０の外に伝送装置１７３が配置される。
　伝送装置１７３は、O-RANコミュニティで定義された伝送装置である。
　user space１６０のＭＡＣ４と伝送装置１７３とは、ＣＴＩ（Collaborative Transport Interface）７を介して接続される。ＣＴＩ７は、O-RANコミュニティで定義された伝送装置とデータスケジュール情報等をやり取りするＩＦである（図５の符号ｃｃ参照）。
　サーバ内データ転送システム１０００Ｃのsleep制御管理部２１０は、ＣＴＩ７をsnoopしてからデータ到着スケジュール情報を取得する（図５の符号ｄｄ参照）。
　以下、サーバ内データ転送システムの動作を説明する。
　サーバ内データ転送システム１０００（図１参照），１０００Ａ（図３参照），１０００Ｂ（図４参照），１０００Ｃ（図５参照）の基本動作は同一であるため、サーバ内データ転送システム１０００（図１参照）について説明する。
［sleep制御管理部２１０の動作］
 <データ到着スケジュール情報に変更があった場合>
　図６は、データ到着スケジュール情報に変更があった場合のsleep制御管理部２１０の動作を示すフローチャートである。
　図６の破線囲みで示すステップＳ１０は、sleep制御管理部２１０の動作開始の外的要因を表わしている（以下、本明細書においてフローチャートの破線囲みは動作開始の外的要因を表わす）。
　ステップＳ１０[外的要因]において、データ到着スケジュール情報に変更があった場合に、データフロータイムスロット管理スケジューラ２（図１参照）は、sleep制御管理部２１０のデータ到着スケジュール管理部２１２へ、変更があった旨を通知する（図１の符号ｒ参照）。または、図４および図５に示すように、sleep制御管理部２１０のデータ到着スケジュール管理部２１２（図１参照）が、データ到着スケジュール情報が含まれるデータをsnoopすることで検知する。
　ステップＳ１１で、sleep制御管理部２１０のデータ到着スケジュール管理部２１２（図１参照）は、データフロータイムスロット管理スケジューラ２（図１参照）から、データ到着スケジュール情報を取得する。
　ステップＳ１２で、データ到着スケジュール管理部２１２は、データ到着スケジュール配信部２１３（図１参照）に対して、データ到着スケジュール情報を伝達する。
　ステップＳ１３で、sleep制御管理部２１０のデータ到着スケジュール配信部２１３は、データ転送部管理部２１１（図１参照）から、データ転送部２２０（図１参照）の数やプロセスＩＤ等の情報を取得する。
　ステップＳ１４で、データ到着スケジュール配信部２１３は、各データ転送部２２０（図１参照）に対して、データ到着スケジュール情報を配信して本フローの処理を終える。
 <データ転送部２２０の増設／減設が発生した場合>
　図７は、データ転送部２２０の増設／減設が発生した場合のsleep制御管理部２１０動作を示すフローチャートである。
　ステップＳ２０[外的要因]において、データ転送部２２０（図１参照）の増設／減設が発生した際に、本システムのオペレーションシステムや保守運用者等が、sleep制御管理部２１０のデータ転送部管理部２１１（図１参照）に対して、データ転送部２２０の数やプロセスＩＤ等の情報を設定する。
　ステップＳ２１で、sleep制御管理部２１０のデータ転送部管理部２１１は、データ転送部２２０の数やプロセスＩＤ等の情報を一覧として保有する。
　ステップＳ２２で、データ転送部管理部２１１は、データ到着スケジュール配信部２１３からの要請に応じて、データ転送部２２０の数やプロセスＩＤ等の情報を伝達して本フローの処理を終える。
　以上、sleep制御管理部２１０の動作について説明した。次に、データ転送部２２０動作について説明する。
［データ転送部２２０の動作］
 <sleep制御>
　図８は、データ転送部２２０のsleep制御部２２１の動作を示すフローチャートである。
　ステップＳ３１で、データ転送部２２０のsleep制御部２２１（図１参照）は、sleep制御管理部２１０のデータ到着スケジュール配信部２１３（図１参照）から受信したデータ到着スケジュール情報を保有する。
　ここで、対向装置１７０（図１参照）と時刻同期がされていない等の原因で、sleep制御管理部２１０（図１参照）が管理するデータ到着タイミングと、実際のデータ到着タイミングに定常的に差分がある場合がある。この場合は、データ転送部２２０においてデータ到着タイミングとの差分を記憶しておき、この差分データが一定であれば、一定差分時間をsleep制御管理部２１０で補正することにより、対応してもよい（詳細については、図１１および図１２で後記する）。
　ステップＳ３２で、データ転送部２２０のsleep制御部２２１（図１参照）は、データ到着監視部２２２（図１参照）に対して、データ到着タイミングのタイマを設定する。すなわち、sleep制御部２２１は、データ到着直前に、データ到着監視部２２２がpollingを開始できるようにタイマを設定する。
　なお、この時、Linux kernel（登録商標）が保有するhrtimers（登録商標）等の高解像タイマ１４１（図１参照）を利用し、ハードウェアクロックによるタイマ発動時のハードウェア割込契機にデータ到着監視部２２２を起動してもよい。
　以上、sleep制御部２２１の動作について説明した。次に、データ転送部２２０の<Ｒｘ側>と<Ｔｘ側>動作について説明する。本発明は、<Ｒｘ側>と<Ｔｘ側>とで動作が異なる特徴がある。
 <Ｒｘ側>
　図９は、データ転送部２２０のデータ到着監視部２２２の動作を示すフローチャートである。
　ステップＳ４１で、データ転送部２２０のデータ到着監視部２２２（図１参照）は、sleep制御部２２１（図１参照）の管理するデータ到着スケジュール情報に従い、データが到着する直前に起動する。
　ここで、データ到着監視部２２２がsleepしている間に、アクセラレータ１２０またはＮＩＣ１３０（図１参照）からデータを受信した際は、データ受信時にハードウェア割込を起動し、このハードウェア割込ハンドラ内で、データ到着監視部２２２を起動してもよい。この方法は、sleep制御管理部２１０が管理するデータ到着スケジュールから逸脱したタイミングでデータが到着した場合の対応に有効である。
　ステップＳ４２で、データ到着監視部２２２は、アクセラレータ１２０またはＮＩＣ１３０のＲｘキュー１２２，１３１（図１参照）を監視し、データ到着有無を確認する。この時、デー到着有無に関わらずＣＰＵコアを専有してデータ到着有無をpollingにより監視する。ここを割込モデルにすると、図２２の従来技術に記載した遅延（すなわち、softIRQが他のsoftIRQと競合する場合、softIRQの実行に関して待合せが発生し、この待合せに起因したｍｓオーダのＮＷ遅延）が発生する。本実施形態では、Ｒｘ側においてpollingモデルのsleep制御にしている点が特徴である。
　ステップＳ４３で、データ到着監視部２２２は、Ｒｘキュー１２２，１３１にデータ到着があるか否かを判別する。
　Ｒｘキュー１２２，１３１にデータ到着がある場合（Ｓ４３：Ｙｅｓ）、ステップＳ４４でデータ到着監視部２２２は、Ｒｘキュー１２２，１３１に格納されたデータ（キュー）を刈取り（バッファに溜まっているパケットの中身を参照して、そのパケットの処理を、次に行う処理を考慮してバッファから該当するキューのエントリを削除する）、Ｒｘデータ転送部２２３（図１参照）へ転送する。
　Ｒｘキュー１２２，１３１にデータ到着がない場合（Ｓ４３：Ｎｏ）、ステップＳ４２に戻る。
　ステップＳ４５で、Ｒｘデータ転送部２２３は、受信したデータをデータ処理ＡＰＬ１（図１参照）に転送する。
　Ｒｘデータ転送部２２３は、後記するＴｘデータ転送部２２４（図１参照）と同様に、データ到着時にのみ動作するため、ＣＰＵを無駄に使用することはない。
　ステップＳ４６で、sleep制御管理部２１０（図１参照）は、運用者が指定した一定期間を経過してもデータの到着がない場合に、データ到着監視部２２２（図１参照）をsleepさせて本フローの処理を終える。
 <Ｔｘ側>
　図１０は、データ転送部２２０のＴｘデータ転送部２２４の動作を示すフローチャートである。
　ステップＳ５０[外的要因]において、データ処理ＡＰＬ１（図１参照）は、サーバ内データ転送装置２００（図１参照）のデータ転送部２２０に対して、データを転送する。
　ステップＳ５１で、データ転送部２２０のＴｘデータ転送部２２４は、受信したデータを、アクセラレータ１２０またはＮＩＣ１３０（図１参照）のＴｘキュー１２３，１３２（図１参照）に格納して本フローの処理を終える。
　Ｔｘデータ転送部２２４は、データ処理ＡＰＬ１がデータを送出する際にプロセス間通信により起動され、データ転送が終了すると CPU idleに戻るため、<Ｒｘ側>のデータ到着監視部２２２と異なり、ＣＰＵを無駄に使用することはない。
　以上、データ転送部２２０動作について説明した。
［データ到着スケジュールに差分がある場合の対応例］
　次に、sleep制御管理部２１０が把握するデータ到着スケジュールと、実際に到着するデータ到着スケジュールが、一定時間差分がある場合の対応ついて説明する。図８のステップＳ３１の補足説明である。
　本実施形態では、ＲＡＮ等のデータ到着スケジュールが予め決まったユースケースを想定している。時間差分が一定ではないようなデータ到着は、ＲＡＮシステム（ＡＰＬ側）が許容しないため、対象外とする。
 <データ転送部２２０のスケジュールが実際のデータ到着よりも進んでいる場合：Ｃａｓｅ１>
　図１１は、データ到着スケジュールに差分がある場合のデータ転送部２２０の動作を示すフローチャートである。
　ステップＳ６１で、データ転送部２２０のデータ到着監視部２２２（図１参照）は、アクセラレータ１２０またはＮＩＣ１３０のＲｘキュー１２２，１３１（図１参照）を監視するとともに、データ到着スケジュールから実際のデータ到着までの時間差分△（差分を表わす記号を△で記載する）Ｔを図示しないメモリに記録する。
　ステップＳ６２で、データ到着監視部２２２（図１参照）は、複数回連続して△Ｔのデータ到着差分があった場合に、sleep制御部２２１（図１参照）へ△Ｔだけデータ到着スケジュールが進んでいる旨を伝達する。ここでいう複数回連続は、本システム運用者が任意で設定する。
　ステップＳ６３で、データ転送部２２０のsleep制御部２２１（図１参照）は、△Ｔだけデータ到着スケジュールが進んでいる旨の伝達を受けて、データ到着スケジュールを、△Ｔ分遅らせて本フローの処理を終える。これにより、一定時間データ到着スケジュールが早い場合のスケジュール補正が可能となる。
 <データ転送部２２０のスケジュールが実際のデータ到着よりも遅れている場合：Ｃａｓｅ２>
　図１２は、データ到着スケジュールに差分がある場合のデータ転送部２２０動作を示すフローチャートである。
　ステップＳ７１で、データ転送部２２０のデータ到着監視部２２２（図１参照）は、アクセラレータ１２０またはＮＩＣ１３０のＲｘキュー１２２，１３１（図１参照）を監視するとともに、データ到着監視を開始した最初のpollingで既にデータが到着している場合は、これを図示しないメモリに記録する。補足して説明する。データ到着監視部２２２は、データが到着する直前に起動する（図８のステップＳ３２の処理参照）。しかし、直前とはいえ、直前＝△ｔの時間間隔は存在し、何サイクルかは空振りのpollingを行うことが想定される。したがって、pollingを開始して既にデータ到着がある場合は、データ転送部２２０のスケジュールが遅れている可能性が高いと判断できる。
　ステップＳ７２で、データ到着監視部２２２は、複数回連続してpolling開始時に既にデータ到着がある場合に、sleep制御部２２１（図１参照）へ微小時間△Ｓだけデータ到着スケジュールを遅らせるように伝達する。ここで、実際にどれだけデータ到着スケジュールがズレているかは把握できないため、運用者が任意で設定した△Ｓの微小時間を繰り返し遅らせることで、少しずつスケジュールを合わせていく。
　ステップＳ７３で、sleep制御部２２１は、△Ｓだけデータ到着スケジュールを早めるべき旨の伝達を受けて、データ到着スケジュールを、△Ｓ分早めて本フローの処理を終える。この△Ｓの時刻補正を繰り返し行うことで、一定時間データ到着スケジュールに遅れがある場合のスケジュール補正が可能となる。
　以上説明したように、サーバ内データ転送システム１０００は、サーバ内データ転送装置２００がuser space１６０上に配置されている。このため、ＤＰＤＫのように、サーバ内データ転送装置２００のデータ転送部２２０は、kernelをバイパスして、リング構造のバッファ（アクセラレータ１２０またはＮＩＣ１３０にパケットが到着すると、ＤＭＡ（Direct Memory Access）により、ＤＰＤＫが管理するメモリ空間に作成されるリング構成のバッファ）を参照することが可能である。すなわち、サーバ内データ転送装置２００は、kernel内のリングバッファ（Ring Buffer７２）（図２２参照）やポールリスト（Ring Buffer７２）（図２２参照）は使用しない。
　データ転送部２２０は、このＤＰＤＫが管理するメモリ空間に作成されるリング構造のバッファ（mbuf；ＰＭＤ１５１がＤＭＡでデータをコピーするリング構造のバッファ）を、polling threadが常に監視することにより、パケット到着を瞬時に把握することが可能である（すなわち割込モデルではなく、pollingモデルである）。
　サーバ内データ転送装置２００は、上記、user space１６０上に配置される特徴のほか、polling threadの起床方法について下記の特徴がある。
　すなわち、サーバ内データ転送装置２００は、データ到着タイミングが決まっているワークロードに対して、データ到着タイミングのスケジューリング情報（データ到着スケジュール情報）をもとに、タイマによりpolling threadを起床する。なお、後記する第３実施形態のサーバ内データ転送装置２００Ｂ（図１７参照）は、kernel内にpolling threadを設けるとともに、NIC１１からのハードウェア割込契機でpolling threadを起床する。
　サーバ内データ転送装置２００の動作について補足して説明する。
 <通常動作：ポーリングモード>
　サーバ内データ転送装置２００は、user space１６０のpolling threadが、メモリ空間にアクセラレータ１２０またはＮＩＣ１３０（図１参照）から展開されたリングバッファを監視する。具体的には、サーバ内データ転送装置２００のＰＭＤ１５１（図２５参照）は、データ到着をポーリングモードまたは割込モードで選択可能なドライバであり、ＰＭＤ１５１は、アクセラレータ１２０またはＮＩＣ１３０にデータが到着した場合、mbufというリング構造のバッファがメモリ空間にあるので、このリング構造のバッファmbufにＤＭＡでデータをコピーする。このリング構造のバッファmbufを、user space１６０のpolling threadが監視する。このため、サーバ内データ転送装置２００は、kernelが準備したpoll_listは使用しないことになる。
　以上、通常の動作（ポーリングモード）について説明した。次に、想定外の割込モードの動作について述べる。
 <想定外動作：割込モード>
　サーバ内データ転送装置２００は、polling threadがsleepしている時にデータが到着した場合に、アクセラレータ１２０またはＮＩＣ１３０（図１参照）からハードウェア割込（hardIRQ）をあげることができるように、ドライバ（ＰＭＤ１５１）のモードを変更し、アクセラレータ１２０またはＮＩＣ１３０にデータが到着した際に、ハードウェア割込を発動し、polling threadを起床できるようにする。
　このように、サーバ内データ転送装置２００のドライバ（ＰＭＤ１５１）は、ポーリングモードと割込モードの２モードを持つ。
（第２実施形態）
　図１３は、本発明の第２実施形態に係るサーバ内データ転送システムの概略構成図である。図１と同一構成部分には、同一符号を付して重複箇所の説明を省略する。
　図１３に示すように、サーバ内データ転送システム１０００Ｄは、ＨＷ１１０と、ＯＳ１４０と、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるサーバ内データ転送装置２００Ａと、を有する。
　サーバ内データ転送装置２００Ａは、図１のサーバ内データ転送装置２００と同様に、データ高速転送ミドルウェアからなる。
　サーバ内データ転送装置２００Ａは、sleep制御管理部２１０と、データ転送部２２０Ａと、を備える。
　データ転送部２２０Ａは、図１３のデータ転送部２２０の構成にさらに、CPU周波数/CPU idle制御部２２５（ＣＰＵ周波数制御部，ＣＰＵアイドル制御部）を備える。
　CPU周波数/CPU idle制御部２２５は、ＣＰＵ動作周波数やCPU idle設定を変動させる制御を行う。具体的には、ハードウェア割込ハンドラにより起動されたpolling thread（サーバ内データ転送装置２００Ａ）のCPU周波数/CPU idle制御部２２５は、polling threadが使用するＣＰＵコアのＣＰＵ動作周波数を通常使用時と比較して低く設定する。
　ここで、kernelは、ＣＰＵコアの動作周波数をgovernor設定により変更が可能であり、CPU周波数/CPU idle制御部２２５は、governor設定等を利用して、ＣＰＵ動作周波数を通常使用時と比較して低く設定することができる。ただし、CPU idle設定は、ＣＰＵ機種依存するものである。なお、ＣＰＵコアがCPU idle設定を有効化している場合は、解除することも可能である。
　以下、サーバ内データ転送システム１０００Ｄの動作を説明する。
 <Ｒｘ側>
　図１４は、データ転送部２２０Ａのデータ到着監視部２２２動作を示すフローチャートである。図９に示すフローチャートと同一処理を行う部分には、同一ステップ番号を付して重複箇所の説明を省略する。
　ステップＳ４１でデータ到着監視部２２２（図１３参照）が、データが到着する直前に起動すると、ステップＳ８１でCPU周波数/CPU idle制御部２２５（図１３参照）は、この時、データ転送部２２０Ａが使用するＣＰＵコアの動作周波数をもとに戻す（ＣＰＵコアのＣＰＵ動作周波数を高くする）。また、CPU周波数/CPU idle制御部２２５は、CPU idle状態（C-State等ＣＰＵアーキテクチャに依存）設定をもとに戻してステップＳ４２に進む。
　ステップＳ４６でsleep制御管理部２１０（図１３参照）が、データ到着監視部２２２（図１３参照）をsleepさせた場合、ステップＳ８２でCPU周波数/CPU idle制御部２２５は、データ転送部２２０Ａが使用するＣＰＵコアの動作周波数を低く設定する。また、CPU周波数/CPU idle制御部２２５は、CPU idle状態（C-State等ＣＰＵアーキテクチャに依存）設定を投入し、該当ＣＰＵコアを CPU idle設定として本フローの処理を終える。
　このように、サーバ内データ転送装置２００Ａは、データ転送部２２０Ａが、ＣＰＵ周波数/CPU idle制御部２２５を備え、データ到着監視部２２２のsleep制御と合わせて、ＣＰＵ周波数/CPU idle状態の設定を行うことで、更なる省電力化を実現することも可能である。
　なお、ＣＰＵ周波数設定を低くする処理と、このsleep状態に落とす処理は、同時に実行してもよい。また、パケット転送処理が完了していることを確認してからsleepしてもよい。
［適用例］
　サーバ内データ転送装置２００，２００Ａは、Kernel内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるサーバ内データ転送装置であればよく、ＯＳは限定されない。また、サーバ仮想化環境下であることも限定されない。したがって、サーバ内データ転送システム１０００～１０００Ｄは、図１５および図１６に示す各構成に適用が可能である。
 <ＶＭ構成への適用例>
　図１５は、汎用Linux kernel（登録商標）およびＶＭ構成のサーバ仮想化環境における、割込モデルに、サーバ内データ転送システム１０００Ｅを適用した例を示す図である。図１、図１３および図１９と同一構成部分には、同一符号を付している。
　図１５に示すように、サーバ内データ転送システム１０００Ｅは、ＨＷ１０と、HostOS２０と、user space（ユーザ空間）１６０上に配置されたデータ高速転送ミドルウェアであるサーバ内データ転送装置２００，２００Ａと、仮想スイッチ１８４と、Guest OS７０と、を有する。
　詳細には、サーバは、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS２０と、仮想マシン内で動作するGuest OS７０と、を備える。
　Host OS２０は、Kernel９１と、Host OS２０を備えるサーバ中のメモリ空間で、Kernel９１が管理するRing Buffer２２（図１９参照）と、NIC１１からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list８６（図２２参照）と、kernel threadであるvhost-netモジュール２２１Ａ（図１９参照）と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２Ａ（図１９参照）と、仮想スイッチ(br)２２３Ａ（図１９参照）と、を有する。
　一方、Guest OS７０は、Kernel１８１と、Driver７３と、Guest OS７０を備えるサーバ中のメモリ空間で、Kernel１８１が管理するRing Buffer５２（図１９参照）と、NIC１１からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list８６（図２２参照）と、を備える。
　サーバ内データ転送システム１０００Ｅは、サーバ内データ転送装置２００，２００Ａがuser space１６０上に配置されている。このため、ＤＰＤＫのように、サーバ内データ転送装置２００，２００Ａのデータ転送部２２０は、kernelをバイパスして、リング構造のバッファを参照することが可能である。すなわち、サーバ内データ転送装置２００，２００Ａは、kernel内のリングバッファ（Ring Buffer７２）（図２２参照）やポールリスト（Ring Buffer７２）（図２２参照）は使用しない。
　データ転送部２２０は、kernelをバイパスして、リング構造のバッファ（Ring Buffer７２）（mbuf；ＰＭＤ１５１がＤＭＡでデータをコピーするリング構造のバッファ）を参照することが可能であり、パケット到着を瞬時に把握することが可能である（すなわち割込モデルではなく、pollingモデルである）。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Host OS２０とGuest OS７０とのいずれのOSにおいても、データ到着がある時はpollingモードによりkernelをバイパスし低遅延にパケット転送を行うことで、低遅延化を図る。また、データの到着がない時はデータ到着監視を止めてsleepすることで、省電力化を図る。その結果、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。また、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <コンテナ構成への適用例>
　図１６は、コンテナ構成のサーバ仮想化環境における、割込モデルに、サーバ内データ転送システム１０００Ｂを適用した例を示す図である。図１５と同一構成部分には、同一符号を付している。
　図１６に示すように、サーバ内データ転送システム１０００Ｆは、Guest OS１８０と、OSをContainer２１０Ａに代えた、コンテナ構成を備える。Container２１０Ａは、vNIC（仮想NIC）２１１Ａを有する。サーバ内データ転送装置２００，２００Ａは、user space（ユーザ空間）１６０上に配置される。
　コンテナなどの仮想サーバ構成のシステムにおいて、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。また、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <ペアメタル構成（非仮想化構成）への適用例>
　本発明は、ペアメタル構成のように非仮想化構成のシステムに適用できる。非仮想化構成のシステムにおいて、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。また、ＡＰＬを改変することなく、サーバ内の遅延を小さくしてパケット転送を行うことができる。
 <拡張技術>
　本発明は、トラヒックフロー数が増えた場合に、インバウンドのネットワークトラフィックを複数ＣＰＵで処理可能なＲＳＳ（Receive-Side Scaling）と連携して、パケット到着監視threadに割り当てるＣＰＵ数を増やすことで、ネットワーク負荷に対するスケールアウトが可能になる。
 <データ到着スケジュールが決まっているネットワークシステムへの適用例>
　データ到着スケジュールが決まっているネットワークシステムの例として、ＴＳＮ（Time Sensitive Network）におけるＴＡＳ（Time Aware Shaper）のように、データ到着タイミングを保証しなければならないネットワークシステムにおける、高速パケット転送処理機能部に適用することも可能である。データ到着スケジュールが決まっているネットワークシステムにおいて、低遅延と省電力の両立を達成することができる。
（第３実施形態）
　第１および第２実施形態は、サーバ内データ転送装置２００，２００Ａをuser space（ユーザ空間）１６０上に配置している。第３実施形態は、user space１６０上に配置したサーバ内データ転送装置２００，２００Ａに代えて、poling threadをkernel内に配備してsleep制御を行うサーバ内データ転送装置２００Ｂをkernel内に備える。
　図１７は、本発明の第３実施形態に係るサーバ内データ転送システムの概略構成図である。図１、図１３および図２１と同一構成部分には、同一符号を付して重複箇所の説明を省略する。本実施形態は、Linux kernel 2.5/2.6より実装されているNew API(NAPI)によるパケット処理に適用した例である。なお、kernel内部にpolling thread を搭載する場合は、NAPIベースにすると、kernelバージョンを考慮する必要がある。
　図１７に示すように、サーバ内データ転送システム１０００Ｇは、ＨＷ１０と、ＯＳ７０と、OS７０のKernel７１内に配置されたサーバ内データ転送装置２００Ｂと、を備える。より詳細には、サーバ内データ転送装置２００Ｂのデータ転送部２２０は、kernel７１内部にのみ存在し、サーバ内データ転送装置２００Ｂのsleep 制御管理部２１０は、user space１６０かkernel７１内部のいずれかに１つ存在すればよい（sleep制御管理部２１０は、user space１６０かkernel７１内部のどちらに配置してもよい）。図１７では、データ転送部２２０およびsleep 制御管理部２１０（すなわちサーバ内データ転送装置２００Ｂ）を、kernel７１内部に配置した例を示している。
　ここで、kernel７１内部に、sleep制御を行うサーバ内データ転送装置２００Ｂを配置する構成を採れば space１６０上に配置するサーバ内データ転送装置２００，２００Ａは、不要になる（この場合、汎用的運用を考慮して、サーバ内データ転送システムにサーバ内データ転送装置２００，２００Ａを配置しておき、適応的にサーバ内データ転送装置２００，２００Ａを不使用とする態様も含まれる）。サーバ内データ転送装置２００，２００Ａが不要になる理由について説明する。すなわち、遅延の問題となるソフトウェア割込は、ＤＰＤＫを使用しない場合は、kernel７１内部でしか発生せず、ＤＰＤＫを使用しない場合は、データ処理ＡＰＬ１とはsocket７５を使用して割込レスでデータ転送する。このため、user space１６０上にサーバ内データ転送装置２００，２００Ａは無くても高速にデータ処理ＡＰＬ１にまでデータ転送が可能であるからである。
　OS７０は、Kernel７１と、OS７０を備えるサーバ中のメモリ空間で、Kernel７１が管理するRing Buffer２２（図１９参照）と、NIC１１からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するpoll_list８６（図２２参照）と、kernel threadであるvhost-netモジュール２２１Ａ（図１９参照）と、Kernel９１により作成される仮想インターフェイスであるtapデバイス２２２Ａ（図１９参照）と、仮想スイッチ(br)２２３Ａ（図１９参照）と、を有する。
　上述したように、サーバ内データ転送装置２００Ｂは、少なくともデータ転送部２２０（図１参照）が、OS７０のKernel７１内に配置される。
　サーバ内データ転送装置２００Ｂのデータ転送部２２０は、インターフェイス部（NIC１１）からのデータ到着を監視するためのデータ到着監視部２２２（図１参照）を有し、インターフェイス部からデータ到着した際にインターフェイス部は、ＤＭＡ（Direct Memory Access）によりＣＰＵを使用せずにメモリ空間に到着データをコピーし、リング構成のバッファにより、このデータを配列する。データ到着監視部２２２は、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げ、リング構成のバッファを監視することにより、データの到着を検知する。
　具体的には、サーバ内データ転送装置２００Ｂのデータ転送部２２０は、OS（OS７０）が、カーネル（Kernel７１）と、OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２）と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list８６）（図２２参照）と、を有し、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げる。
　このように、サーバ内データ転送装置２００Ｂのデータ転送部２２０は、ポールリストを監視（polling）するデータ到着監視部２２２と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するＲｘデータ転送部（パケット刈取部）２２３と、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させ、かつ、パケット到着時はこのスレッド（polling thread）のハードウェア割込（hardIRQ）によりスリープ解除を行うsleep制御部２２１と、を備える。
　このようにすることで、サーバ内データ転送装置２００Ｂは、ＮＷ遅延発生の主要因であるパケット処理のソフトウェア割込（softIRQ）を停止し、サーバ内データ転送装置２００Ｂのデータ到着監視部２２２がパケット到着を監視するthreadを実行し、Ｒｘデータ転送部（パケット刈取部）２２３が、パケット到着時に、pollingモデル（softIRQなし）によりパケット処理を行う。そして、sleep制御部２２１が、パケットが所定期間到着しない場合はスレッド（polling thread）をスリープ（sleep）させることで、スレッド（polling thread）はパケット未到着時にsleepする。sleep制御部２２１は、パケット到着時はハードウェア割込（hardIRQ）によりスリープ解除を行う。
　以上説明したように、サーバ内データ転送システム１０００Ｇは、kernel内にpolling threadを設けるサーバ内データ転送装置２００Ｂを備え、サーバ内データ転送装置２００Ｂのデータ転送部２２０は、NIC１１からのハードウェア割込契機でpolling threadを起床する。特に、データ転送部２２０は、kernel内にpolling threadを設ける場合において、タイマで起床させることを特徴とする。これにより、サーバ内遅延制御装置２００Ｂは、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。
［ハードウェア構成］
　上記各実施形態に係るサーバ内データ転送装置２００，２００Ａ，２００Ｂは、例えば図１８に示すような構成のコンピュータ９００によって実現される。
　図１８は、サーバ内データ転送装置２００，２００Ａの機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
　コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３、ＨＤＤ９０４、通信インターフェイス（Ｉ／Ｆ：Interface）９０６、入出力インターフェイス（Ｉ／Ｆ）９０５、およびメディアインターフェイス（Ｉ／Ｆ）９０７を有する。
　ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に格納されたプログラムに基づいて動作し、図１および図１３に示すサーバ内データ転送装置２００，２００Ａ，２００Ｂの各部の制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いてもよい。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラムまたはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、導体メモリテープ媒体又は半導体メモリ等である。
　例えば、コンピュータ９００が本実施形態に係る一装置として構成されるサーバ内データ転送装置２００，２００Ａ，２００Ｂとして機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することによりサーバ内データ転送装置１００の機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
［効果］
　以上説明したように、インターフェイス部（アクセラレータ１２０，ＮＩＣ１３０）のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置２００であって、OS（OS７０）が、カーネル（Kernel１７１）と、OSを備えるサーバ中のメモリ空間のリングバッファ（mbuf；ＰＭＤ１５１がＤＭＡでデータをコピーするリング構造のバッファ）と、インターフェイス部（アクセラレータ１２０，ＮＩＣ１３０）からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバ（ＰＭＤ１５１）と、を有し、ポーリングモデルを用いてパケット到着を監視するスレッド（polling thread）を立ち上げるデータ転送部２２０と、データ到着スケジュール情報を管理し、データ転送部２２０に対して、データ到着スケジュール情報を配信してデータ転送部２２０のスリープ制御を行うスリープ制御管理部（sleep制御管理部２１０）と、を備え、データ転送部２２０は、sleep制御管理部２１０から配信されたデータ到着スケジュール情報をもとに、スレッドをスリープ（sleep）させるとともに、データ到着の直前にタイマを発動させて、スレッドを起こすスリープ解除を行う。
　このようにすることで、sleep制御管理部２１０は、データ到着タイミングに合わせて複数のデータ転送部のsleep制御を行うために、一括して各データ転送部２２０のSleep／起動のタイミング制御を行う。データ到着がある時はpollingモードによりkernelをバイパスし低遅延にパケット転送を行うことで、低遅延化を図る。また、データの到着がない時はデータ到着監視を止めてsleepすることで、省電力化を図る。その結果、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。
　サーバ内データ転送装置２００は、サーバ内のデータ転送遅延を、割込モデルではなくpollingモデルで実現することで、低遅延化の達成が可能である。すなわち、サーバ内データ転送装置２００は、ＤＰＤＫのように、user space１６０に配置されたデータ転送部２２０が、kernelをバイパスして、リング構造のバッファを参照することが可能である。そして、このリング構造のバッファを、polling threadが常に監視することにより、パケット到着を瞬時に把握することが可能である（割込モデルではなく、pollingモデルである）。
　また、ｖＲＡＮにおける信号処理のように、時分割多重データフロー等のデータ到着タイミングが固定的に決まったデータフローに対して、データ到着スケジュールを考慮してデータ転送部２２０のsleep制御を行うことで、低遅延性を維持しつつＣＰＵ使用率を削減することができ、省電力の達成が可能である。すなわち、pollingモデルにおけるＣＰＵリソースの無駄使いの問題を、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。
　また、仮想マシン内で動作するGuest OS（Guest OS７０）が、カーネル（Kernel１７１）と、Guest OSを備えるサーバ中のメモリ空間のリングバッファ（mbuf；ＰＭＤ１５１がＤＭＡでデータをコピーするリング構造のバッファ）と、インターフェイス部（アクセラレータ１２０，ＮＩＣ１３０）からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバ（ＰＭＤ１５１）と、刈取りが実行されたパケットのプロトコル処理を行うプロトコル処理部７４と、を有し、ポーリングモデルを用いてパケット到着を監視するスレッド（polling thread）を立ち上げるデータ転送部２２０と、データ到着スケジュール情報を管理し、データ転送部２２０に対して、データ到着スケジュール情報を配信してデータ転送部２２０のスリープ制御を行うスリープ制御管理部（sleep制御管理部２１０）と、を備え、データ転送部２２０は、sleep制御管理部２１０から配信されたデータ到着スケジュール情報をもとに、スレッドをスリープ（sleep）させるとともに、データ到着の直前にタイマを発動させて、スレッドを起こすスリープ解除を行うことを特徴とする。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、Guest OS（Guest OS７０）を備えるサーバについて、低遅延性を維持しつつＣＰＵ使用率を削減することができ、省電力の達成が可能である。
　また、仮想マシンおよび仮想マシン外に形成された外部プロセスが動作可能なHost OS（Host OS２０）が、カーネル（Kernel９１）と、Host OSを備えるサーバ中のメモリ空間のリングバッファ（mbuf；ＰＭＤ１５１がＤＭＡでデータをコピーするリング構造のバッファ）と、インターフェイス部（アクセラレータ１２０，ＮＩＣ１３０）からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバ（ＰＭＤ１５１）と、カーネル（Kernel９１）により作成される仮想インターフェイスであるtapデバイス２２２Ａと、を有し、ポーリングモデルを用いてパケット到着を監視するスレッド（polling thread）を立ち上げるデータ転送部２２０と、データ到着スケジュール情報を管理し、データ転送部２２０に対して、データ到着スケジュール情報を配信してデータ転送部２２０のスリープ制御を行うスリープ制御管理部（sleep制御管理部２１０）と、を備え、データ転送部２２０は、sleep制御管理部２１０から配信されたデータ到着スケジュール情報をもとに、スレッドをスリープ（sleep）させるとともに、データ到着の直前にタイマを発動させて、スレッドを起こすスリープ解除を行うことを特徴とする。
　このようにすることにより、ＶＭの仮想サーバ構成のシステムにおいて、カーネル（Kernel１９１）とHost OS（Host OS２０）とを備えるサーバについて、低遅延性を維持しつつＣＰＵ使用率を削減することができ、省電力の達成が可能である。
　また、サーバ内データ転送装置２００Ｂであって、OS（OS７０）が、カーネル（Kernel１７１）と、OSを備えるサーバ中のメモリ空間で、カーネルが管理するリングバッファ（Ring Buffer７２)と、インターフェイス部（NIC１１）からのハードウェア割込（hardIRQ）がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリスト（poll_list８６）と、カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッド（thread）を立ち上げるデータ転送部２２０と、データ到着スケジュールを管理し、データ到着スケジュール情報を管理し、データ転送部２２０に対して、データ到着スケジュール情報を配信して当該データ転送部２２０のスリープ制御を行うスリープ制御管理部（sleep制御管理部２１０）と、を備え、データ転送部２２０は、ポールリストを監視（polling）するデータ到着監視部２２２と、パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリをリングバッファから削除する刈取りを実行するパケット刈取部（Ｒｘデータ転送部２２３）と、sleep制御管理部２１０から受信したデータ到着スケジュール情報をもとに、スレッド（polling thread）をスリープ（sleep）させるとともに、当該スリープの解除時はハードウェア割込（hardIRQ）によりスリープ解除を行うスリープ制御部（sleep制御部２２１）と、を備える。
　このようにすることで、サーバ内データ転送装置２００Ｂは、サーバ内のデータ転送遅延を、割込モデルではなくpollingモデルで実現することで、低遅延化の達成が可能である。特に、ｖＲＡＮにおける信号処理のように、時分割多重データフロー等のデータ到着タイミングが固定的に決まったデータフローに対して、データ到着スケジュールを考慮してデータ転送部２２０のsleep制御を行うことで、低遅延性を維持しつつＣＰＵ使用率を削減することができ、省電力の達成が可能である。すなわち、pollingモデルにおけるＣＰＵリソースの無駄使いの問題を、データ到着タイミングを考慮したタイマ制御によりsleep制御することで、低遅延と省電力の両立を達成することができる。
　データ転送部２２０は、sleep制御管理部２１０から受信したデータ到着スケジュール情報をもとに、スレッド（polling thread）をスリープ（sleep）させるとともに、当該スリープの解除時はハードウェア割込（hardIRQ）によりスリープ解除を行う。
　これにより、上記効果に加えて、さらに（１）～（２）の効果を奏する。
　（１）遅延発生の原因となるパケット到着時のソフトウェア割込（softIRQ）を停止し、カーネル（Kernel１７１）内でpollingモデルを実現する。すなわち、サーバ内データ転送システム１０００Ｇは、既存技術のNAPIと異なり、ＮＷ遅延の主要因となる割込モデルではなく、pollingモデルを実現する。パケット到着時は、待合せなく即時に刈り取られるため、低遅延なパケット処理を実現することができる。
　（２）サーバ内データ転送装置２００におけるpolling threadは、kernel threadとして動作し、pollingモードでパケット到着を監視している。パケット到着を監視するkernel thread（polling thread）は、パケット到着がない間はsleepする。パケット到着がない場合は、sleepによってＣＰＵを使用しないので、省電力の効果を得ることができる。
　そして、パケット到着時には、sleep中のpolling threadは、パケット到着時のhardIRQハンドラで起こされる（sleep解除される）。hardIRQハンドラでsleep解除されることで、softIRQ競合を回避しながら、polling threadを即時起動させることができる。ここで、sleep解除は、タイマを持っていてこのタイマにより起こすものではなく、hardIRQハンドラで起こす点に特徴がある。なお、あらかじめトラヒックロードが分かっている場合、例えば図２３に示すワークロード転送レートのように３０ｍｓsleepが分かっている場合は、このタイミング合わせてhardIRQハンドラで起こすようにしてもよい。
　このように、サーバ内データ転送装置２００Ｂは、パケット転送処理を行うpolling threadのsleep管理を行うことで、低遅延と省電力を両立させることができる。
　サーバ内データ転送装置２００Ａにおいて、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数設定部（CPU周波数/CPU idle制御部２２５）を備えることを特徴とする。
　このように、サーバ内データ転送装置２００Ａは、ＣＰＵ動作周波数をトラヒックに合わせて動的に変動させる、すなわち、スリープによりＣＰＵを使わないのであれば、スリープ中におけるＣＰＵ動作周波数を低く設定することで、より省電力の効果を高めることができる。
　サーバ内データ転送装置２００Ａにおいて、スリープ中に、スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル設定部（CPU周波数/CPU idle制御部２２５）を備えることを特徴とする。
　このようにすることにより、サーバ内データ転送装置２００Ａは、CPU idle状態（動作電圧を変更するなど、ＣＰＵ機種に応じた省電力機能）をトラヒックに合わせて動的に変動させることで、より省電力の効果を高めることができる。
　なお、上各記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
　１　データ処理ＡＰＬ（アプリケーション）
　２　データフロータイムスロット管理スケジューラ
　３　ＰＨＹ(High)
　４　ＭＡＣ
　５　ＲＬＣ
　６　ＦＡＰＩ(FAPI P7)
　２０，７０　Host OS（OS）
　５０　Guest OS（OS）
　８６　poll_list（ポールリスト）
　７２　Ring Buffer（リングバッファ）
　９１，１７１，１８１　Kernel（カーネル）
　１１０　ＨＷ
　１２０　アクセラレータ（インターフェイス部）
　１２１　コア（Ｃｏｒｅプロセッサ）
　１２２，１３１　Ｒｘキュー
　１２３，１３２　Ｔｘキュー
　１３０　ＮＩＣ（物理NIC）（インターフェイス部）
　１４０　ＯＳ
　１５１　ＰＭＤ（データ到着をポーリングモードまたは割込モードで選択可能なドライバ）
　１６０　user space（ユーザ空間）
　２００，２００Ａ，２００Ｂ　サーバ内データ転送装置
　２１０　sleep制御管理部
　２１０Ａ　Container
　２１１　データ転送部管理部
　２１２　データ到着スケジュール管理部
　２１３　データ到着スケジュール配信部
　２２０　データ転送部
　２２１　sleep制御部
　２２２　データ到着監視部
　２２３　Ｒｘデータ転送部（パケット刈取部）
　２２４　Ｔｘデータ転送部
　２２５　CPU周波数/CPU idle制御部（ＣＰＵ周波数制御部，ＣＰＵアイドル制御部）
　１０００，１０００Ａ，１０００Ｂ，１０００Ｃ，１０００Ｄ，１０００Ｅ，１０００Ｆ，１０００Ｇ　サーバ内データ転送システム
　Mbuf　ＰＭＤがＤＭＡでデータをコピーするリング構造のバッファ

Claims (8)

  1. 　インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置であって、
    　OSが、
    　カーネルと、
    　前記OSを備えるサーバ中のメモリ空間のリング構造のバッファと、
    　インターフェイス部からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバと、を有し、
    　ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備え、
    　前記データ転送部は、
    　前記スリープ制御管理部から配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるとともに、データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行う
    　ことを特徴とするサーバ内データ転送装置。
  2. 　インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置であって、
    　仮想マシン内で動作するGuest OSが、
    　カーネルと、
    　前記Guest OSを備えるサーバ中のメモリ空間のリング構造のバッファと、
    　インターフェイス部からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバと、を有し、
    　ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備え、
    　前記データ転送部は、
    　前記スリープ制御管理部から配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるとともに、データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行う
    　ことを特徴とするサーバ内データ転送装置。
  3. 　インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置であって、
    　仮想マシンおよび前記仮想マシン外に形成された外部プロセスが動作可能なHost OSが、
    　カーネルと、
    　前記Host OSを備えるサーバ中のメモリ空間のリングバッファと、
    　インターフェイス部からのデータ到着をポーリングモードまたは割込モードで選択可能なドライバと、
    　前記カーネルにより作成される仮想インターフェイスであるtapデバイスと、を有し、
    　ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備え、
    　前記データ転送部は、
    　前記スリープ制御管理部から配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるとともに、データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行う
    　ことを特徴とするサーバ内データ転送装置。
  4. 　サーバ内データ転送装置であって、
    　OSが、
    　カーネルと、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、
    　インターフェイス部からのハードウェア割込がどのデバイスのものであるかを示すネットデバイスの情報を登録するポールリストと、を有し、
    　前記カーネル内に、ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備え、
    　前記データ転送部は、
    　前記ポールリストを監視するデータ到着監視部と、
    　パケットが到着している場合は、リングバッファに保持したパケットを参照し、次に行う処理に基づいて該当するキューのエントリを前記リングバッファから削除する刈取りを実行するパケット刈取部と、
    　前記スリープ制御管理部から受信した前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるとともに、当該スリープの解除時はハードウェア割込により当該スレッドのスリープ解除を行うスリープ制御部と、を備える
    　ことを特徴とするサーバ内データ転送装置。
  5. 　前記データ転送部は、
    　前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵ動作周波数を低く設定するＣＰＵ周波数制御部を備える
    　ことを特徴とする請求項１乃至４のいずれか一項に記載のサーバ内データ転送装置。
  6. 　前記データ転送部は、
    　前記スリープ中に、前記スレッドが使用するＣＰＵコアのＣＰＵアイドル状態を省電力モードに設定するＣＰＵアイドル制御部を備える
    　ことを特徴とする請求項１乃至４のいずれか一項に記載のサーバ内データ転送装置。
  7. 　インターフェイス部のデータ転送制御をユーザ空間上で行うサーバ内データ転送装置のサーバ内データ転送方法であって、
    　OSが、
    　カーネルと、
    　前記OSを備えるサーバ中のメモリ空間のリング構造のバッファと、
    　データ到着をポーリングモードまたは割込モードで選択可能なドライバと、を有し、
    　ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備えており、
    　前記データ転送部は、
    　前記スリープ制御管理部から配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせるステップと、
    　データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行うステップと、を実行する
    　ことを特徴とするサーバ内データ転送方法。
  8. 　OSが、
    　カーネルと、
    　前記OSを備えるサーバ中のメモリ空間のリングバッファと、
    　データ到着をポーリングモードまたは割込モードで選択可能なドライバと、を有し、
    　ポーリングモデルを用いてパケット到着を監視するスレッドを立ち上げるデータ転送部と、
    　データ到着スケジュール情報を管理し、前記データ転送部に対して、前記データ到着スケジュール情報を配信して当該データ転送部のスリープ制御を行うスリープ制御管理部と、を備えており、
    　前記データ転送部としてのコンピュータに、
    　配信された前記データ到着スケジュール情報をもとに、前記スレッドをスリープさせる手順、
    　データ到着の直前にタイマを発動させて、前記スレッドを起こすスリープ解除を行う手順、
    　を実行させるためのプログラム。
PCT/JP2021/027049 2021-07-19 2021-07-19 サーバ内データ転送装置、サーバ内データ転送方法およびプログラム WO2023002547A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2021/027049 WO2023002547A1 (ja) 2021-07-19 2021-07-19 サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
JP2023536248A JPWO2023002547A1 (ja) 2021-07-19 2021-07-19

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/027049 WO2023002547A1 (ja) 2021-07-19 2021-07-19 サーバ内データ転送装置、サーバ内データ転送方法およびプログラム

Publications (1)

Publication Number Publication Date
WO2023002547A1 true WO2023002547A1 (ja) 2023-01-26

Family

ID=84979012

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/027049 WO2023002547A1 (ja) 2021-07-19 2021-07-19 サーバ内データ転送装置、サーバ内データ転送方法およびプログラム

Country Status (2)

Country Link
JP (1) JPWO2023002547A1 (ja)
WO (1) WO2023002547A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004199683A (ja) * 2002-12-18 2004-07-15 Internatl Business Mach Corp <Ibm> 低消費電力適応的ポーリング
US20090089784A1 (en) * 2007-09-28 2009-04-02 Walters Glen R Variable polling interval based on historical timing results
JP2018507457A (ja) * 2014-12-22 2018-03-15 インテル コーポレイション ネットワークデバイスにおける受信パケットの処理と関連する電力管理のための技術
WO2021130828A1 (ja) * 2019-12-23 2021-07-01 日本電信電話株式会社 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004199683A (ja) * 2002-12-18 2004-07-15 Internatl Business Mach Corp <Ibm> 低消費電力適応的ポーリング
US20090089784A1 (en) * 2007-09-28 2009-04-02 Walters Glen R Variable polling interval based on historical timing results
JP2018507457A (ja) * 2014-12-22 2018-03-15 インテル コーポレイション ネットワークデバイスにおける受信パケットの処理と関連する電力管理のための技術
WO2021130828A1 (ja) * 2019-12-23 2021-07-01 日本電信電話株式会社 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Also Published As

Publication number Publication date
JPWO2023002547A1 (ja) 2023-01-26

Similar Documents

Publication Publication Date Title
JP7310924B2 (ja) サーバ内遅延制御装置、サーバ、サーバ内遅延制御方法およびプログラム
US9842075B1 (en) Presenting multiple endpoints from an enhanced PCI express endpoint device
US9231892B2 (en) Distributed virtual switch configuration and state management
US20220121607A1 (en) Io processing method and apparatus
JP7251648B2 (ja) サーバ内遅延制御システム、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP4171910B2 (ja) 並列処理システム及び並列処理プログラム
WO2002031672A2 (en) Method and apparatus for interprocessor communication and peripheral sharing
US20190042151A1 (en) Hybrid framework of nvme-based storage system in cloud computing environment
WO2022143714A1 (zh) 服务器系统、虚拟机创建方法及装置
US11625199B2 (en) Communication apparatus, communication method, and computer program product
Chang et al. Virtualization technology for TCP/IP offload engine
WO2023002547A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
JP7451438B2 (ja) 通信装置、通信システム、通知方法及びプログラム
WO2022195826A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023144878A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2022172366A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023144958A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023218596A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2024013830A1 (ja) サーバ内データ転送装置、データ転送システム、サーバ内データ転送方法およびプログラム
WO2023199519A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023105578A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
WO2023105692A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
CN118355641A (zh) 服务器内数据传输装置、服务器内数据传输方法以及程序
EP0796466A1 (en) An improved method and apparatus for embedding a real-time multi-tasking kernel in a non-real-time operating system
KR101483603B1 (ko) 통신 시스템에서 효율이 개선된 자원 제어 방법 및 장치

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: 21950901

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023536248

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18579035

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE