Server internal data transfer apparatus, server internal data transfer method, and program

Abstract

To reduce power consumption of a CPU used in data polling, while suppressing data transfer delay from an accelerator to an application, when using accelerator resources on a physical server for a plurality of applications.SOLUTION: A server internal data transfer apparatus 100 transfers data from a device including an accelerator to an application when the device is used for the application. The server internal data transfer apparatus comprises: a device simulation unit 130 that uses a virtual queue that replaces a physical queue of the device, to separate connection between the device and a thread corresponding to the application, and responds with data corresponding to a data request from the thread on behalf of the device; and a proxy unit 140 that dynamically changes connection between the virtual queue and the physical queue.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an intra-server data transfer device, an intra-server data transfer method, and a program. [Background technology]

[0002] With the advancement of virtualization technology such as NFV (Network Functions Virtualization), systems are being built and operated for each service. Furthermore, instead of building systems for each service, service functions are being divided into reusable modules that run on independent virtual machine (VM, container, etc.) environments.

[0003] A known technology for configuring virtual machines is a hypervisor environment consisting of Linux (registered trademark) and KVM (kernel-based virtual machine). In this environment, a Host OS (an OS installed on a physical server is called a Host OS) with a built-in KVM module acts as a hypervisor and runs in a memory area called kernel space, which is different from user space. In this environment, a virtual machine runs in user space, and a Guest OS (an OS installed on a virtual machine is called a Guest OS) runs within that virtual machine.

[0004] Unlike a physical server running a Host OS, a virtual machine running a Guest OS controls all hardware (HW), including network devices (typically Ethernet (registered trademark) card devices), as registers required for interrupt processing from the HW to the Guest OS and for writing from the Guest OS to the hardware. In this type of register control, notifications and processing that should be performed by physical hardware are simulated by software, so performance is generally lower than in a Host OS environment.

[0005] To address this performance degradation, there is a technology that reduces HW emulation, particularly from the guest OS to the host OS or external processes that exist outside the virtual machine, and improves communication performance and versatility through a high-speed, unified interface. One such technology is a device abstraction technology called Virtio, or paravirtualization technology, which has been developed and is already incorporated into many general-purpose operating systems, including Linux (registered trademark) and FreeBSD (registered trademark), and is currently in use (see Patent Document 1).

[0006] Virtio defines data exchange using queues designed with ring buffers as a unidirectional transport for data input / output such as console, file input / output, and network communication, through queue operations. By using the Virtio queue specifications to prepare the number and size of queues appropriate for each device when the Guest OS starts, communication between the Guest OS and outside the virtual machine can be achieved using only queue operations without performing hardware emulation.

[0007] Data transfer technologies within a server include New API (NAPI), DPDK (Data Plane Development Kit), and KBP (Kernel Busy Poll).

[0008] When a packet arrives, the New API (NAPI) processes the packet using a software interrupt request after issuing a hardware interrupt request.

[0009] DPDK implements packet processing functions in the user space where applications run, and immediately harvests packets as they arrive from the user space using a polling model (see Non-Patent Document 1). Specifically, DPDK is a framework for controlling NICs (Network Interface Cards), a function traditionally performed by the Linux kernel (registered trademark), in user space. The biggest difference from the Linux kernel's processing is the inclusion of a polling-based reception mechanism called PMD (Pull Mode Driver). Typically, in the Linux kernel, an interrupt is generated when data arrives at the NIC, triggering the execution of reception processing. In contrast, in PMD, a dedicated thread continuously checks for data arrival and performs reception processing. High-speed packet processing is possible by eliminating overhead such as context switches and interrupts. DPDK significantly improves packet processing performance and throughput, allowing more time to be devoted to data plane application processing. However, DPDK exclusively uses computer resources such as the CPU (Central Processing Unit) and NIC.

[0010] Non-Patent Document 2 describes a server network delay control device (KBP: Kernel Busy Poll). KBP constantly monitors packet arrivals within the kernel using a polling model. This suppresses softIRQs and achieves low-latency packet processing.

[0011] Next, we will explain the DPDK system. [DPDK system configuration] FIG. 23 is a diagram illustrating a configuration of a DPDK system that controls HW 10 including an accelerator 11. The DPDK system includes HW 10, a packet processing API (Application Programming Interface) 14, and an application (APL) 20.

[0012] APL20 is a packet processing performed prior to the execution of APL. APL20 is APL1 and APL2 in this example.

[0013] The packet processing API 14 is an API for offloading packet processing to a NIC or an accelerator. The packet processing API 14 is a high-speed data transfer middleware located in user space, which is DPDK. DPDK realizes packet processing functions in the user space where APL20 runs, and reduces packet transfer delays by immediately reaping packets when they arrive from the user space using a polling model. In other words, DPDK uses polling (a CPU busy polls the queue) to retrieve packets (references the contents of the packets stored in the buffer, and deletes the corresponding queue entry from the buffer to process the packet and take into account the next processing to be performed), so there is no waiting and delays are small.

[0014] HW10 communicates with APL1 and APL2 to send and receive data. In the following description, the data flow in which APL1 and APL2 receive packets from HW10 is referred to as Rx-side reception, and the data flow in which APL1 and APL2 send packets to HW10 is referred to as Tx-side transmission.

[0015] The HW 10 includes an accelerator 11. The HW 10 may also include a NIC (physical NIC) for connecting to a communication network. The accelerator 11 is a computational unit hardware that performs specific calculations at high speed based on input from a CPU. Specifically, the accelerator 11 is a PLD (Programmable Logic Device) such as a GPU (Graphics Processing Unit) or an FPGA (Field Programmable Gate Array). In FIG. 23, the accelerator 11 includes multiple IP cores (Intellectual Property Cores) 12 and a physical queue 13 consisting of an Rx queue (waiting queue) and a Tx queue that hold data in a first-in-first-out list structure. The IP cores 12 are design information for reusable circuit components that constitute semiconductors such as FPGAs, ICs, and LSIs, and are sometimes called device cores (core processors).

[0016] Part of the processing of APL1 and APL2 is offloaded to the accelerator 11, achieving performance and power efficiency that cannot be achieved by software (CPU processing) alone. It is expected that the accelerator 11 described above will be applied to a large-scale server cluster such as a data center that implements NFV (Network Functions Virtualization) or SDN (Software Defined Network).

[0017] Existing applications (APL20, APL1, APL2) that transfer data to accelerators in poll mode, such as DPDK, operate by being fixedly linked to the physical queue 13 used by the application at the time of initialization (see the dashed-line box in Figure 23). The application thread (hereinafter referred to as the application thread) performs transmission and reception processing via the Ring Buffer 16 (see Figure 24) corresponding to the accelerator 11. The application thread 15 here is a Polling Thread.

[0018] FIG. 24 is a diagram illustrating reception processing by polling in the DPDK system of FIG. The application thread (PollingThread) 15 and the packet processing API 14 are arranged in a user space 30 . In the receiving process by polling, when there is data to be transferred, the pointer of the data is stored in the Ring Buffer 16 (see symbol a in FIG. 24). To reduce delays from the accelerator 11, the application thread 15 polls the Ring Buffer 16, and when there is data to be transferred, it acquires a pointer to the data and performs a receive process (see symbol b in FIG. 24). At this time, the CPU usage rate of the application thread 15 becomes 100% due to the polling, and power consumption increases. In DPDK, the application thread 15 polls for packet arrival, resulting in little delay but increased power consumption. As shown in Fig. 23, when there are multiple applications APL1 and APL2, the impact of increased power consumption is significant. [Prior art documents] [Patent documents]

[0019] [Patent Document 1] Japanese Patent Application Publication No. 2018-32156 [Non-patent literature]

[0020] [Non-Patent Document 1] THE LINUX FOUNDATION PROJECTS DPDK, [online], [Retrieved November 5, 2021], Internet <http: / / www.dpdk.org / > [Non-patent document 2] Kei Fujimoto, Kenichi Matsui, Masayuki Akutsu, “KBP: Kernel Enhancements for Low-Latency Networking without Application Customization in Virtual Server”, IEEE CCNC 2021. Summary of the Invention [Problem to be solved by the invention]

[0021] However, packet transfer using the polling model has the following problems. In DPDK, the kernel thread occupies a CPU core to perform polling (busy polling the queue on the CPU). For this reason, even in the case of intermittent packet reception, DPDK always uses 100% of the CPU regardless of whether packets have arrived, which poses the issue of increased power consumption. KBP also has the same issues as DPDK. That is, KBP constantly monitors packet arrivals using a polling model within the kernel, suppressing softIRQs and achieving low-latency packet processing. However, the kernel thread that constantly monitors packet arrivals occupies a CPU core and constantly uses CPU time, which results in high power consumption.

[0022] The present invention was made in light of this background, and its objective is to reduce the power consumption of the CPU used for data polling while suppressing delays in data transfer from the accelerator to applications when accelerator resources installed in a physical server are used by multiple applications. [Means for solving the problem]

[0023] In order to solve the above-mentioned problems, there is provided an intra-server data transfer device that transfers data from a device including an accelerator to an application when the device is used in the application, and is characterized by comprising: a device simulation unit that uses a virtual queue that serves as a substitute for the physical queue of the device to separate the connection between the device and a thread corresponding to the application, and that responds with data corresponding to a data request from the thread on behalf of the device, and a proxy unit that dynamically changes the connection between the virtual queue and the physical queue. [Effects of the Invention]

[0024] According to the present invention, when accelerator resources installed in a physical server are used by multiple applications, it is possible to reduce the power consumption of the CPU used for data polling while suppressing delays in data transfer from the accelerator to the applications. [Brief explanation of the drawings]

[0025] [Figure 1] 1 is a schematic configuration diagram of an intra-server data transfer system according to an embodiment of the present invention; [Figure 2] 1 is a block diagram of an intra-server data transfer system according to an embodiment of the present invention; [Figure 3] 10A and 10B are diagrams illustrating a sleep control operation of an application thread in the server data transfer system according to the embodiment of the present invention. [Figure 4] FIG. 4 is a control sequence diagram of the sleep control operation of the application thread in FIG. 3. [Figure 5] FIG. 2 is a diagram illustrating a communication proxy with an accelerator in the server data transfer system according to an embodiment of the present invention. [Figure 6] FIG. 10 is a diagram showing a correspondence table between thread IDs and physical queues of a proxy unit in the intra-server data transfer system according to the embodiment of the present invention. [Figure 7] FIG. 10 is a diagram showing a virtual queue table of a proxy unit of the intra-server data transfer system according to the embodiment of the present invention. [Figure 8] FIG. 10 is a diagram showing a logical-physical mapping table of a proxy unit of the intra-server data transfer system according to the embodiment of the present invention. [Figure 9] FIG. 10 is a diagram showing a physical queue table of a proxy unit of the intra-server data transfer system according to the embodiment of the present invention. [Figure 10] 10 is a flowchart showing a wake-up determination process using packet arrival information in the polling control of the intra-server data transfer system according to the embodiment of the present invention. [Figure 11]10 is a flowchart showing a wake-up determination process using timing information (statistics) in the polling control of the intra-server data transfer system according to the embodiment of the present invention. [Figure 12] 10 is a diagram showing, in the form of a table, packet timers of virtual queues of the intra-server data transfer system according to the embodiment of the present invention. FIG. [Figure 13] FIG. 10 is a diagram illustrating a virtual queue threshold table of the intra-server data transfer system according to the embodiment of the present invention. [Figure 14] FIG. 3 is a control sequence diagram of packet transmission in the server data transfer system according to the embodiment of the present invention. [Figure 15] FIG. 3 is a control sequence diagram of packet reception and polling in the server data transfer system according to the embodiment of the present invention. [Figure 16] FIG. 10 is a control sequence diagram of an IP core scale-in in the server data transfer system according to the embodiment of the present invention. [Figure 17] FIG. 17 is a diagram illustrating the IP core scale-in of FIG. [Figure 18] 10 is a flowchart illustrating a logical-to-physical mapping table update process of the intra-server data transfer system according to the embodiment of the present invention. [Figure 19] FIG. 10 is a control sequence diagram of a thread scale-in in the intra-server data transfer system according to the embodiment of the present invention. [Figure 20] FIG. 1 is a diagram illustrating a thread scale-in of an intra-server data transfer system according to an embodiment of the present invention. [Figure 21] 10 is a flowchart illustrating a logical-to-physical mapping table update process of the intra-server data transfer system according to the embodiment of the present invention. [Figure 22] 1 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of an intra-server data transfer device of an intra-server data transfer system according to an embodiment of the present invention. [Figure 23] FIG. 1 is a diagram illustrating the configuration of a DPDK system that controls HW equipped with an accelerator. [Figure 24]FIG. 24 is a diagram illustrating reception processing by polling in the DPDK system of FIG. 23. DETAILED DESCRIPTION OF THE INVENTION

[0026] Hereinafter, an intra-server data transfer system and the like in an embodiment for carrying out the present invention (hereinafter referred to as "the present embodiment") will be described with reference to the drawings. (Embodiment) [Overall configuration] 1 is a schematic diagram of an intra-server data transfer system according to an embodiment of the present invention, in which the same components as those in FIG. 23 are assigned the same reference numerals. As shown in FIG. 1, the intra-server data transfer system 1000 includes HW 10, a packet processing API 14, a controller (CTRL) (internal server data transfer device) 100, and an application (APL) 20.

[0027] The controller 100 is disposed between the application 20 and the HW 10. For this reason, the packet processing API 14 is disposed between the application 20 and the controller 100, but the presence of the controller 100 is invisible to the application 20, and the packet processing API 14 is an API for offloading packet processing to a NIC or accelerator.

[0028] The controller 100 is an intra-server data transfer device that transfers data from a device including the accelerator 11 to the application 20 when the device is used by the application 20 . The controller 100 manages the association between the application thread 15 and the IP cores 12 of the accelerators 11 and communicates with the accelerators 11 on behalf of the application 20.

[0029] The controller 100 includes a packet arrival monitor 110 , a polling control unit 120 , a device simulation unit 130 , and a proxy unit 140 .

[0030] The packet arrival monitor 110 monitors communication between the accelerator 11 (device) and the application thread 15 and measures the timing of packet arrival. That is, after processing between the accelerator 11 and the application thread 15 is completed, a packet arrives to be received by the application, and the packet arrival monitor 110 monitors the arrival of this packet and measures the timing of packet arrival from the accelerator 11.

[0031] The polling control unit 120 wakes up the application thread 15 when the packet arrival monitor unit 110 detects that a packet has arrived, and prompts the application thread 15 to process the packet, and puts the application thread to sleep while there are no packets. Until now, polling processing was performed 100% of the time, but now packet processing is stopped when it is not necessary (polling is stopped; the polling control unit 120 wakes up the application thread 15 only when a packet arrives).

[0032] The device simulation unit 130 connects to the application 20 using an interface equivalent to an existing one, and provides a virtual queue 200 (see FIG. 5) instead of the physical queue 13 of the device. The device simulation unit 130 connects the device to the application 20 by having the application thread 15 perform packet processing using a virtual queue 200 corresponding to the physical queue of the device instead of the physical queue. The virtual queue 200 is a queue that is presented to the application thread 15 in place of the physical queue 13 .

[0033] It is desired that the application 20 believes that it is always using the accelerator 11 (that it is always communicating with the accelerator 11) (in other words, it is desired to hide the controller 100 from the accelerator 11). The device simulation unit 130 connects to the application 20 using an interface equivalent to an existing one, and provides a virtual queue 200 instead of the physical queue 13 of the device. This makes it appear as if the application 20 is always communicating with the accelerator 11.

[0034] The proxy unit 140 dynamically changes the connection between the virtual queue 200 and the physical queue 13 . When a packet arrives from the application thread 15 , the packet needs to be delivered to the accelerator 11 by the virtual queue 200 , and the proxy unit 140 connects the virtual queue 200 and the physical queue 13 .

[0035] The proxy unit 140 changes the association of the physical queue 13 with the virtual queue 200 and simultaneously instructs the increase or decrease of the IP cores 12 and application threads 15. The proxy unit 140 further associates multiple physical queues (1:N) with one application thread 15, or associates one physical queue (M:1) with multiple application threads 15 (N and M are any natural numbers).

[0036] [Intra-server data transfer system] 2 is a block diagram of an intra-server data transfer system 1000 equipped with a controller 100. Components that are the same as those in FIG. 1 are given the same reference numerals. The intra-server data transfer system 1000 includes an application thread 15 arranged in a user space 30, an accelerator 11 having a plurality of physical queues 13 and IP cores 12, and a controller 100.

[0037] In addition, an external controller 50 such as a RIC (RAN Intelligent Controller) is connected to the intra-server data transfer system 1000. The RIC is a component defined by software called the RAN (Radio Access Network) architecture, and realizes control, optimization, and intelligence of RAN functions.

[0038] The white arrows in FIG. 2 indicate the flow of data, and from the perspective of the flow of data transmission and reception processing, the controller 100 is configured to be interposed between the application thread 15 and the accelerator 11.

[0039] The controller 100 includes a packet arrival monitor 110, a polling controller 120, a device simulation unit 130, a proxy unit 140, an integrated controller 150, an application controller 160, a device controller 170, and an external controller IF 180. The integrated control unit 150 performs integrated control of each unit. The integrated control unit 150 makes a scale-in decision in response to a request from the external controller IF 180 (see FIG. 19, described later). The integrated control unit 150 also makes a "logical-physical mapping table update request" to the proxy unit 140 (see FIG. 19, described later). The integrated control unit 150 makes a scale-in request to the device control unit 170 (see FIG. 19, described later).

[0040] The application control unit 160 controls the application thread 15 in accordance with instructions from the integrated control unit 150 . The device control unit 170 controls the accelerator 11 in accordance with instructions from the integrated control unit 150 . The external controller IF 180 receives instructions from the external controller 50 .

[0041] The operation of the intra-server data transfer system configured as above will now be described. [Sleep control behavior of application threads] 3 is a diagram illustrating the sleep control operation of an application thread. The same components as those in FIGS. 1 and 24 are denoted by the same reference numerals. The application thread 15 , the packet processing API 14 , and the controller 100 are located in the user space 30 .

[0042] As described above, when there are multiple applications APL1 and APL2 (see Figure 1), the impact of increased power consumption is significant. Therefore, the sleep control operation of the application thread when there are multiple applications APL1 and APL2 will be described. A plurality of application threads 15 exist for each of the plurality of applications APL1 and APL2. The polling control unit 120 (see FIG. 1) of the controller 100 wakes up the application thread 15 when a packet arrives to prompt packet processing, and puts the application thread 15 to sleep while there are no packets.

[0043] The packet arrival monitor 110 (see FIG. 1) of the controller 100 monitors communication with the accelerator 11 and measures the packet arrival timing. In the reception process by polling, the packet arrival monitor 110 (see FIG. 1) uses the physical queue 41 to store a pointer to the data to be transferred in the Ring Buffer 17 (Ring Buffer <1> ) (see symbol a in Figure 3).

[0044] Incidentally, in the past, the application thread 15 would poll the Ring Buffer 16 and harvest packets, as shown in FIG.

[0045] In contrast to this, in this embodiment, the packet arrival monitoring unit 110 (see FIG. 1) uses the virtual queue 200 (see FIG. 5) instead of the application thread 15 to poll the Ring Buffer 17, and when there is data to be transferred, obtains a pointer to the data and performs the receiving process (see symbol b in FIG. 3).

[0046] The proxy unit 140, on behalf of the application thread 15, stores a pointer to the data to be transferred in the Ring Buffer 18 (Ring Buffer <2> ) (=virtual queue 200) (see symbol c in FIG. 3).

[0047] The polling control unit 120 notifies the application thread 15 of the event (see symbol d in FIG. 3).

[0048] When there is data to be transferred, the application thread 15 acquires a pointer to the data using the virtual queue 200 (see symbol e in FIG. 3).

[0049] Here, the packet arrival monitor 110 polls the physical queues 13 on behalf of all application threads 15. As a result, even if there are multiple application threads 15, only one packet arrival monitor 110 can monitor the physical queues 13. For example, in the case of FIG. 23, multiple (six) application threads 15 are running in parallel for multiple applications APL1 and APL2, and in the conventional example of FIG. 23, polling of all six application threads 15 was required. In contrast, in this embodiment, all physical queues 13 can be monitored for multiple application threads 15 running in parallel by polling all physical queues 13 with only one packet arrival monitor 110. Therefore, by simple calculation, power consumption can be reduced to 1 / 6. Even if polling cannot be completely eliminated, the problem can be solved.

[0050] As described above, the controller 100 monitors the arrival of packets at the accelerator 11 and polls the Ring Buffer 17 on behalf of the application thread 15 . The controller 100 notifies the application thread 15 of the arrival of a packet by a method such as event notification.

[0051] FIG. 4 is a control sequence diagram of the sleep control operation of the application thread in FIG. The application thread 15 notifies the Ring Buffer 17 of an accelerator execution request (S1), and the Ring Buffer 17 notifies the Ring Buffer 18 of this execution request (S2). The Ring Buffer 18 notifies the accelerator 11 of this execution request (S3).

[0052] Here, when the application thread 15 notifies the Ring Buffer 17 of an accelerator execution request, the controller 100 puts the application thread 15 to sleep (see symbol f in FIG. 4).

[0053] The accelerator 11 executes the request from the accelerator 11 (S4) and transmits the processing result to the Ring Buffer 18 (S5). The packet arrival monitor 110 of the controller 100 monitors communication with the accelerator 11, and the controller 100 polls the Ring Buffer 18 on behalf of the application thread 15 (see symbol g in FIG. 4).

[0054] The controller 100 notifies the application thread 15 of the arrival of a packet by a method such as an event notification (see symbol h in FIG. 4).

[0055] The Ring Buffer 18 transmits the processing result to the Ring Buffer 17 (S6), and the Ring Buffer 17 transmits the processing result of the accelerator 11 to the application thread 15 when a data transmission request is received from the application thread 15 that has been woken up in response to the event notification (S7).

[0056] In this way, the controller 100 can monitor, by polling, the arrival of packets from the accelerator 11 on behalf of the accelerator 11. This eliminates the need for each application thread 15 to monitor the arrival of packets by polling, thereby reducing power consumption.

[0057] The controller 100 can monitor the communications of all application threads 15, thereby making the polling of all application threads 15 more efficient and enabling a reduction in the power consumption of the entire server.

[0058] The intra-server data transfer system 1000 can reduce delays by sending an event notification from the controller 100 to the application thread 15 when a packet arrives, or by sending an event notification based on timing information obtained from statistical data on packet sending and receiving intervals.

[0059] [Proxies for communication with accelerators] 5 is a diagram for explaining a communication proxy with an accelerator. The same components as those in FIG. 1 are given the same reference numerals. The controller 100 communicates with the application 20 as a pseudo device having an interface equivalent to an existing one so that the application 20 can treat it in the same way as the accelerator 11. In this case, a virtual queue 200 is provided to the application 20 instead of the physical queue 13. The device emulation unit 130 (FIGS. 1 and 2) connects to the application using an interface equivalent to an existing interface, and provides a virtual queue 200 instead of the physical queue 13 of the device.

[0060] FIG. 6 is a diagram showing a correspondence table 210 between the thread IDs of the proxy unit 140 and the physical queues 13. As shown in FIG. A corresponding physical queue 13 is assigned to each thread ID "1001...". For example, if the IP core 12 of the accelerator 11 shown in FIG. 5 has physical queues (0 to 5) arranged from left to right, the thread ID "1001" is assigned to the leftmost physical queue (0) of the IP core 12 of the accelerator 11 shown in FIG. 5. It is also possible to assign multiple physical queues to a thread ID. For example, the thread ID "1003" is assigned to the physical queue (2,3) of the IP core 12 of the accelerator 11 shown in FIG. 5. This example is indicated by the connections branching to the physical queue (2,3) when viewed from the virtual queue. Conversely, the thread IDs "2001" and "2002" are both assigned to the physical queue (4). This example is indicated by the connections being aggregated in the physical queue (4). Conventionally, there is a one-to-one correspondence between thread IDs and physical queues, and the branching and aggregation described above does not occur.

[0061] FIG. 7 is a diagram showing the virtual queue table 220 of the proxy unit 140. As shown in FIG. The virtual queue table 220 describes which thread ID corresponds to which virtual queue. There is a one-to-one correspondence between thread IDs and virtual queues. For example, thread ID "1001" corresponds to virtual queue (0), and thread ID "1002" corresponds to virtual queue (1). Proc_type (process type) specifies the type of processing you want the accelerator to perform. For example, Proc_type "1" can be connected to an IP core 12 that supports type 1 processing, and Proc_type "2" can be connected to an IP core 12 that supports type 2 processing. When a thread corresponds to multiple applications, the APL describes the application type. The "state" describes whether the thread is active (Used) or inactive (blank).

[0062] FIG. 8 is a diagram showing the logical-physical mapping table 230 of the proxy unit 140. As shown in FIG. The logical-physical mapping table 230 assigns physical queues (0-3) to virtual queues (0-4). For example, physical queue 0 is assigned to virtual queue (0), and physical queue 1 is assigned to virtual queue (1). It is also possible to assign multiple physical queues (physical queues 2 and 3) to virtual queue (3).

[0063] FIG. 9 is a diagram showing the physical queue table 240 of the proxy unit 140. As shown in FIG. The IP core ID is the ID of the core that actually performs the processing, and each IP core ID is associated with a physical queue, Proc_type, device ID, and "state." Proc_type indicates that only processes of the same type can be connected. The device ID indicates the type of accelerator that is processed by the accelerator; for example, a device ID of "1" indicates that accelerator 1 is the corresponding accelerator.

[0064] [Polling control] <Wake-up decision using packet arrival information> FIG. 10 is a flowchart showing wake-up determination processing using packet arrival information in polling control. In step S11, polling control unit 120 determines whether or not packet arrival has been confirmed by packet arrival monitor unit 110. If packet arrival cannot be confirmed (S11: No), polling control unit 120 returns to step S11 and waits for packet arrival.

[0065] If the arrival of a packet is confirmed (S11: Yes), in step S12, the polling control unit 120 sends a wake-up instruction to the application thread 15 corresponding to the virtual queue 200 (in the following description, the application thread 15 is referred to as the polling thread 15 because it is a thread in polling control).

[0066] In step S13, the polling control unit 120 determines whether the polling thread 15 has woken up and harvested a packet. If the packet has not been harvested (S13: No), the process returns to step S13 and waits for the packet to be harvested.

[0067] If the packet has been harvested (S13: Yes), in step S14, the polling control unit 120 instructs the polling thread 15 corresponding to the virtual queue 200 to sleep until the next harvest, and ends the processing of this flow.

[0068] <Wake-up decision using timing information (statistics)> FIG. 11 is a flowchart showing wake-up determination processing using timing information (statistics) in polling control. In step S21, the polling control unit 120 selects the virtual queue 200. In step S22, the polling control unit 120 checks the packet timer 250 (see FIG. 12) of the virtual queue 200 which has the largest value.

[0069] FIG. 12 is a diagram showing the packet timer 250 of the virtual queue 200 in the form of a table. A virtual queue and a timer are set for each packet ID. By setting a timer for each virtual queue 200, it is possible to set in advance the timing for waking up when a packet arrives, thereby making it possible to achieve effective sleep control.

[0070] Returning to FIG. 11, in step S23, the polling control unit 120 determines whether the packet timer 250 has exceeded the threshold value of the virtual queue 200 or not.

[0071] FIG. 13 is a diagram showing the threshold table 260 of the virtual queue 200. As shown in FIG. Set a threshold for each virtual queue to determine whether or not pruning will occur. For example, set it so that virtual queue (0) will not be pruned until it reaches the threshold "200".

[0072] 11, if the packet timer 250 has not exceeded the threshold of the virtual queue 200 (S23: No), the process returns to step S21 and repeats steps S21 and S22 until the packet timer 250 exceeds the threshold of the virtual queue 200. The threshold of the packet timer 250 is set separately from statistical information from packet transmission to reception.

[0073] If the packet timer 250 exceeds the threshold value of the virtual queue 200 (S23: Yes), the polling control unit 120 transmits a wake-up instruction to the polling thread corresponding to the virtual queue 200 in step S24.

[0074] In step S25, the polling control unit 120 determines whether the thread has woken up and harvested a packet. If the packet has not been harvested (S25: No), the process returns to step S25 and waits for the packet to be harvested.

[0075] If the thread wakes up and harvests the packet (S25: Yes), in step S26 the polling control unit 120 instructs the polling thread 15 corresponding to the virtual queue 200 to sleep until the next harvest, and ends the processing of this flow.

[0076] [Send Packet] 14 is a control sequence diagram of packet transmission. This packet transmission has a <polling pattern> and a <non-polling pattern>. Note that this polling is between the packet arrival monitor 110 and the virtual queue 200.

[0077] <Polling pattern> The application thread 15 transmits the pointer information of the packet to the virtual queue 200 (S101). On the other hand, the packet arrival monitor 110 checks for packet arrival by polling (S151). The virtual queue 200 notifies the packet arrival monitor 110 of "packet arrival" and "pointer information of the packet" (S152).

[0078] The packet arrival monitor 110 receives the "packet arrival" and "packet pointer information" from the virtual queue 200, and transmits the "packet pointer information" to the proxy unit 140 (S105).

[0079] The proxy unit 140 receives the "pointer information of the packet" and checks the physical queue 13 corresponding to the virtual queue 200 (S106). The proxy unit 140 transmits the "pointer information of the packet" to the physical queue 13 (S107).

[0080] Packet transmission according to this <polling pattern> (pattern with polling) does not notify the controller 100 as in the <pattern without polling> below.

[0081] <No Polling Pattern> The same steps as those in the above polling pattern are assigned the same step numbers. The application thread 15 transmits the packet pointer information to the virtual queue 200 (S101), and notifies the packet arrival monitor 110 that a packet has arrived (S102). Upon receiving the notification of "packet arrival" from the application thread 15, the packet arrival monitor 110 checks the virtual queue 200 for packet arrival (S103). The virtual queue 200 transmits "packet arrival" and "pointer information of the packet" to the packet arrival monitor 110 (S104).

[0082] The packet arrival monitor 110 receives the "packet arrival" and "packet pointer information" from the virtual queue 200, and transmits the "packet pointer information" to the proxy unit 140 (S105).

[0083] The proxy unit 140 receives the "pointer information of the packet" and checks the physical queue 13 corresponding to the virtual queue 200 (S106). The proxy unit 140 transmits the "pointer information of the packet" to the physical queue 13 (S107).

[0084] [Packet reception / polling control] FIG. 15 is a control sequence diagram of packet reception and polling. The packet arrival monitor 110 checks the arrival of a packet by polling the physical queue 13 (S111). The physical queue 13 transmits "packet arrival" and "packet pointer information" to the packet arrival monitor 110 (S112).

[0085] Upon receiving the "packet arrival" and "packet pointer information" from the physical queue 13, the packet arrival monitor 110 transmits the "packet pointer information" to the proxy unit 140 (S113).

[0086] The proxy unit 140 receives the "pointer information of the packet" and checks the virtual queue 200 corresponding to the physical queue 13 (S114). The proxy unit 140 transmits "pointer information of the packet" to the virtual queue 200 (S115), and also transmits "corresponding virtual queue information" to the packet arrival monitor unit 110 (S116).

[0087] Upon receiving the "corresponding virtual queue information" from the proxy unit 140, the packet arrival monitor unit 110 transmits "packet arrival" to the polling control unit 120 (S117). Upon receiving the "packet arrival" from the packet arrival monitor 110, the polling control unit 120 issues an "event notification" to the application thread 15 (S118).

[0088] The application thread 15 performs a "wake-up process" (S119). The application thread 15 requests "pointer information of the packet" from the virtual queue 200 (S120). In response to this request, the virtual queue 200 transmits the "pointer information of the packet" to the virtual queue 200 (S121).

[0089] [IP core scale-in] FIG. 16 is a control sequence diagram of the IP core scale-in. The external controller IF 180 sends a "scale-in determination request" to the integrated control unit 150 (S131). The integrated control unit 150 makes a scale-in decision (S132). The integrated control unit 150 makes a "logical-physical mapping table update request" to the proxy unit 140 (S133). The proxy unit 140 updates the logical-physical mapping table 230 (see FIG. 8) (see the logical-physical mapping table update in FIG. 18) and notifies the integrated control unit 150 of this (S135).

[0090] In the IP core scale-in process, a case where the IP core #2 of the IP cores 12 is scaled in will be taken as an example (see FIG. 17). The integrated control unit 150 sends an "IP core #2 scale-in request" to the device control unit 170 (S136). The device control unit 170 performs a power-off operation for the IP core #2 (S137) and notifies the integrated control unit 150 of "IP core #2 scale-in completion" (S138).

[0091] Fig. 17 is a diagram for explaining the IP core scale-in of Fig. 16. The same components as in Fig. 5 are denoted by the same reference numerals. By the IP core scale-in process of FIG. 16, the IP core #2 is scaled in (see the dashed arrow i in FIG. 17).

[0092] FIG. 18 is a flowchart showing the logical-physical mapping table update process. In step S31, the proxy unit 140 determines whether or not there is a virtual queue 200 corresponding to the physical queue to be scaled in. If there is no corresponding virtual queue 200 (S31: No), the logical-physical mapping table update process according to this flow is normally terminated.

[0093] If there is a corresponding virtual queue 200 (S31: Yes), the proxy unit 140 selects one virtual queue 200 in step S32.

[0094] In step S33, the proxy unit 140 determines whether there is a physical queue 13 with the same proc_type as the proc_type of the virtual queue 200. If there is no physical queue 13 with the same proc_type as the proc_type of the virtual queue 200 (S33: No), the logical-to-physical mapping table update process according to this flow is ended with NG.

[0095] If there is a physical queue 13 with the same proc_type as the virtual queue 200 in step S33 (S33: Yes), the proxy unit 140 determines to re-link the virtual queue 200 and the physical queue 13, and in step S34, if there are multiple devices, it selects a device (however, this depends on the policy). This policy may be, for example, concentrating loads on devices with the highest loads possible (aggregation) or distributing loads to devices with the lowest loads (load balancing).

[0096] In step S35, if there are multiple physical queues 13, the proxy unit 140 selects (according to a policy) a physical queue 13. This policy may, for example, concentrate traffic on a physical queue with the highest possible load (aggregation) or distribute traffic to physical queues with the lowest possible load (load distribution).

[0097] In step S36, the proxy unit 140 changes the value of the cell of the physical queue 13 associated with the virtual queue 200 in the logical-to-physical mapping table 230 (see FIG. 8) to 1.

[0098] In step S37, the proxy unit 140 changes the values ​​of the cells of the virtual queue 200 and the scale-in physical queue 13 in the logical-physical mapping table 230 to 0, and then returns to step S31.

[0099] [Thread Scale In] FIG. 19 is a control sequence diagram of the thread scale-in. The external controller IF 180 sends a "scale-in determination request" to the integrated control unit 150 (S141). The integrated control unit 150 makes a scale-in decision (S142). The integrated control unit 150 makes a "logical-physical mapping table update request" to the proxy unit 140 (S143). The proxy unit 140 updates the logical-physical mapping table 230 (see FIG. 8) (S144) (see the logical-physical mapping table update in FIG. 21), and notifies the integrated control unit 150 of this (S145).

[0100] In the thread scale-in process, a case where thread #2 of application threads 15 is scaled in will be taken as an example (see FIG. 20). The central control unit 150 makes a "thread #2 scale-in request" to the device control unit 170 (S146). The device control unit 170 performs an operation to stop polling of thread #2 (S147) and notifies the central control unit 150 of "thread #2 scale-in completion" (S148).

[0101] Fig. 20 is a diagram for explaining thread scale-in. The same components as those in Fig. 5 and Fig. 17 are denoted by the same reference numerals. Thread #2 shown in FIG. 20 is scaled in by the thread scale-in process of FIG. 19 (see dashed arrow j in FIG. 20).

[0102] FIG. 21 is a flowchart showing the logical-physical mapping table update process. In step S41, the proxy unit 140 determines whether or not there is a physical queue 13 corresponding to the virtual queue to be scaled in. If there is no corresponding physical queue 13 (S41: No), the logical-to-physical mapping table update process according to this flow is normally ended.

[0103] If there is a corresponding physical queue 13 (S41: Yes), the proxy unit 140 selects one physical queue 13 in step S42.

[0104] In step S43, the proxy unit 140 determines whether there is a virtual queue 200 with the same proc_type as the proc_type of the physical queue 13. If there is no virtual queue 200 with the same proc_type as the proc_type of the physical queue 13 (S43: No), the process proceeds to step S47.

[0105] If there is a virtual queue 200 with the same proc_type as the physical queue 13 in step S43 (S43: Yes), the proxy unit 140 determines to re-link the virtual queue 200 and the physical queue 13, and in step S44, if there are multiple applications, it selects an application (however, this depends on a policy). This policy may, for example, concentrate the load on an APL with the highest possible load (aggregation) or distribute the load to an APL with a lower load (load distribution).

[0106] In step S45, if there are multiple virtual queues 200, the proxy unit 140 selects a virtual queue 200 (however, depending on a policy). This policy may, for example, concentrate loads on a virtual queue with the highest possible load (aggregation) or distribute loads to virtual queues with the lowest possible load (load distribution).

[0107] In step S46, the proxy unit 140 changes the value of the cell of the virtual queue 200 linked to the physical queue 13 in the logical-physical mapping table 230 (see FIG. 8) to 1.

[0108] In step S47, the proxy unit 140 changes the values ​​of the cells of the physical queue 13 and the scale-in virtual queue 200 in the logical-physical mapping table 230 to 0, and then returns to step S41.

[0109] [Hardware configuration] The controller (internal server data transfer device) 100 according to the above embodiment is realized by a computer 900 having a configuration as shown in FIG. 22, for example. FIG. 22 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the controller 100. The computer 900 includes a CPU 901, a RAM 902, a ROM 903, a HDD 904, an accelerator 905, an input / output interface (I / F) 906, a media interface (I / F) 907, and a communication interface (I / F) 908. The accelerator 905 corresponds to the accelerator 11 in FIGS. 1, 3, and 5.

[0110] The accelerator 905 is an accelerator (device) 11 (FIGS. 1 and 5) that processes at least one of data from the communication I / F 908 and data from the RAM 902 at high speed. Note that the accelerator 905 may be of a type (look-aside type) that executes processing from the CPU 901 or RAM 902 and then returns the execution results to the CPU 901 or RAM 902. On the other hand, the accelerator 905 may be of a type (in-line type) that performs processing between the communication I / F 908 and the CPU 901 or RAM 902.

[0111] The accelerator 905 is connected to an external device 915 via a communication I / F 908. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from and to a recording medium 917.

[0112] The CPU 901 operates based on a program stored in the ROM 903 or the HDD 904, and controls each part of the controller 100 shown in Figures 1, 3, and 5 by executing a program (also called an application or an app for short) loaded into the RAM 902. This program can also be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM. The ROM 903 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0113] The CPU 901 controls an input / output device 916, which is made up of input units such as a mouse and a keyboard, and output units such as a display and a printer, via an input / output I / F 906. The CPU 901 acquires data from the input / output device 916 via the input / output I / F 906, and outputs generated data to the input / output device 916. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0114] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 908 receives data from other devices via a communication network (e.g., a network) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0115] The media I / F 907 reads a program or data stored in the recording medium 917 and outputs it to the CPU 901 via the RAM 902. The CPU 901 loads a program related to a target process from the recording medium 917 onto the RAM 902 via the media I / F 907, and executes the loaded program. The recording medium 917 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0116] For example, when the computer 900 functions as the intra-server data transfer device 100 configured as one device according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 902 to realize the functions of the controller (internal-server data transfer device) 100. The HDD 904 stores data in the RAM 902. The CPU 901 reads and executes a program relating to a target process from the recording medium 917. Alternatively, the CPU 901 may read a program relating to a target process from another device via a communication network.

[0117] [effect] As described above, the intra-server data transfer device according to this embodiment is an intra-server data transfer device (controller 100) that transfers data from a device including accelerator 11 to application 20 when the device is used by application 20, and includes packet arrival monitoring unit 110 that monitors communication between the device and application thread 15 corresponding to application 20 and measures the timing of packet arrival, and polling control unit 120 that wakes up application thread 15 to process the packet when a packet arrives that has been detected by packet arrival monitoring unit 110, and puts application thread 15 to sleep while no packets arrive.

[0118] In this way, a controller (internal server data transfer device) 100 including a packet arrival monitor 110 and a polling control unit 120 acts as an intermediary between the application 20 and the accelerator 11 .

[0119] Since the controller 100 can monitor the arrival of packets from the accelerator 11 on behalf of the accelerator 11 by polling, it is no longer necessary for each application thread 15 to monitor the arrival of packets by polling, and power consumption can be reduced.

[0120] The controller 100 can monitor the communications of all application threads 15, thereby making it possible to improve the efficiency of polling of all application threads 15 and reduce the power consumption of the entire server.

[0121] In addition, the controller 100 can suppress delays by, for example, notifying the application thread 15 of an event when a packet arrives, or by notifying the application thread 15 of an event based on timing information from statistical data on packet transmission / reception intervals.

[0122] Furthermore, when multiple network applications that use accelerators to speed up data processing, such as vRAN (virtual Radio Access Network), are installed on the same server, applying this system can provide the following benefits:

[0123] Power saving: Polling in each application thread 15 is no longer necessary, significantly reducing the power consumption of the CPU core.

[0124] Efficiency (dynamic aspect): In cases where demand changes significantly, such as between day and night, power consumption can be reduced by shutting down unnecessary resources through IP core scale-in and thread scale-in.

[0125] Efficiency (static aspect): When the accelerator 11 has spare capacity, the number of users that can be accommodated by the accelerator can be increased by linking virtual queues of multiple applications to one physical queue.

[0126] The server data transfer device (controller) 100 of this embodiment corresponds to the physical queue of the device and includes a device simulation unit 130 that connects the device to the application 20 by having the application thread 15 perform packet processing using a virtual queue 200 instead of the physical queue, and a proxy unit 140 that dynamically changes the connection between the virtual queue 200 and the physical queue 13.

[0127] In this way, the device simulation unit 130 and the proxy unit 140 are provided, and the device simulation unit 130 provides the application with the virtual queue 200 instead of the physical queue 13. From the application 20's perspective, it appears as if it is communicating with the actual accelerator 11, so no modifications are required.

[0128] The controller 100 manages the association between the application threads 15 and the IP cores 12 of the multiple accelerators 11, and communicates with the accelerators 11 on behalf of the application 20. The controller 100 changes the association between the physical queues 13 and the virtual queues 200, and at the same time instructs the increase or decrease of the IP cores 12 and application threads 15, thereby enabling dynamic resource changes such as increasing (scaling out) or decreasing (scaling in) the IP cores 12 and application threads 15 according to demand.

[0129] Furthermore, by linking multiple physical queues (1:N) to one application thread 15 or one physical queue (M:1) to multiple application threads, more flexible resource management and resource aggregation through superposition become possible.

[0130] It should be noted that, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. Furthermore, the components of each device shown in the figure are conceptual functional components and do not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0131] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information on the programs, tables, files, etc. that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disc. [Explanation of symbols]

[0132] 10 HW 11,905 accelerators (devices) 12 IP cores (device cores) 14 Packet Processing API 17,18 Ring Buffer 15 application threads (polling threads) 20 Applications (APL) 100 Controller (data transfer device within the server) 110 Packet arrival monitor 120 Polling control section 130 Device Simulation Unit 140 Proxy Section 150 Integrated Control Unit 160 Application control unit 170 Device control unit 180 External controller IF 220 Virtual Queue Table 230 Logical-Physical Mapping Table 240 Physical Queue Table 250 Packet Timer 260 Threshold Table 1000 Server Data Transfer System APL1, APL2 applications

Claims

1. 1. A data transfer device in a server that transfers data from a device including an accelerator to an application when the device is used by the application, comprising: a device emulation unit that separates the connection between the device and the thread corresponding to the application by using a virtual queue that replaces a physical queue of the device, and responds with data corresponding to a data request from the thread on behalf of the device; a proxy unit that dynamically changes the connection between the virtual queue and the physical queue.

1. A server data transfer device comprising:

2. The proxy unit provides an M:N (N and M are any natural numbers) many-to-many connection between one or M virtual queues that serve as substitutes for physical queues of the device and one or N physical queues of the device.

2. The server data transfer device according to claim 1.

3. The proxy unit dynamically changes the connection destination between one or more virtual queues that serve as substitutes for the physical queues of the device and one or more physical queues of the device.

2. The server data transfer device according to claim 1.

4. 1. An intra-server data transfer method for an intra-server data transfer device that transfers data from a device including an accelerator to an application when the device is used by the application, comprising: The server data transfer device using a virtual queue that replaces a physical queue of the device to decouple the device from a thread corresponding to the application, and responding with data corresponding to a data request from the thread on behalf of the device; and dynamically changing the connection between the virtual queue and the physical queue.

2. A method for transferring data within a server, comprising:

5. When a device including an accelerator is used in an application, a computer as a server data transfer device that transfers data from the device to the application, a step of separating the connection between the device and the thread corresponding to the application by using a virtual queue that replaces a physical queue of the device, and responding with data corresponding to a data request from the thread on behalf of the device; a step of dynamically changing the connection between the virtual queue and the physical queue; A program to execute.

Images