WO2023105603A1 - 転送管理装置、転送管理方法、および、転送管理プログラム - Google Patents

転送管理装置、転送管理方法、および、転送管理プログラム Download PDF

Info

Publication number
WO2023105603A1
WO2023105603A1 PCT/JP2021/044832 JP2021044832W WO2023105603A1 WO 2023105603 A1 WO2023105603 A1 WO 2023105603A1 JP 2021044832 W JP2021044832 W JP 2021044832W WO 2023105603 A1 WO2023105603 A1 WO 2023105603A1
Authority
WO
WIPO (PCT)
Prior art keywords
transfer
priority
request
queue
size
Prior art date
Application number
PCT/JP2021/044832
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/044832 priority Critical patent/WO2023105603A1/ja
Publication of WO2023105603A1 publication Critical patent/WO2023105603A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • 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/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal

Definitions

  • the present invention relates to a transfer management device, a transfer management method, and a transfer management program.
  • Non-Patent Document 1 DMA hardware transfer enables high-speed and large-capacity data transfer (Non-Patent Document 2).
  • DMA often uses an application (APL) on a server as a transfer source and an accelerator or network device on the same server as a transfer destination.
  • APL application
  • Non-Patent Document 3 describes the XDMA specifications of Xilinx Corporation, which is an example of a transfer engine.
  • the Xilinx driver has multiple channels of queues that store requests to be transferred, and takes out requests from each channel in round robin (equally) and transfers them.
  • FIG. 26 is a configuration diagram of a conventional physical server 100z.
  • a plurality of threads 11z each issues a request (illustrated as a hatched rectangle) requesting DMA transfer of data to the host DRAM 12z.
  • the DMA transfer driver 1z reads each request and sequentially transfers them to the device DRAM 51z in the device 50z via the PCIe (Peripheral Component Interconnect Express) 59z.
  • An IP core 52z which is an FPGA (Field Programmable Gate Array) in the device 50z, reads and processes each request transferred to the device DRAM 51z.
  • FIG. 27 is a configuration diagram of the DMA transfer driver 1z in FIG.
  • the DMA transfer driver 1z has a reception queue 20z, a transfer queue 30z, and a transfer engine 40z.
  • the reception queue 20z stores a request issued from each thread 11z as a pointer pointing to a data storage destination in the host DRAM 12z.
  • the transfer queue 30z stores the pointer of the request read from the reception queue 20z to notify the transfer engine 40z.
  • the transfer engine 40z sequentially reads request data in the host DRAM 12z from the pointer in the transfer queue 30z and transfers the data to the device DRAM 51z.
  • a transfer wait for the next request occurs while a certain request is being transferred.
  • the following procedure has a transfer wait problem.
  • the file transfer application A1 (first thread 11z) requests the transfer engine 40z to make a request R1 for a file with a large data size.
  • the transfer engine 40z starts transferring the request R1 because there are no other requests to be transferred at this time.
  • the call application A2 (second thread 11z) issues a high-priority call data request R2 with a short delay (TAT: Turnaround Time) requirement to the transfer engine 40z.
  • the main object of the present invention is to satisfy the transfer efficiency and delay requirements of the transferred data in a well-balanced manner when transferring data from a plurality of transfer sources to the same transfer destination.
  • the present invention is a transfer management apparatus having a host section having a host memory in which transfer source data is stored, and a device section having a device memory as a data transfer destination,
  • the host unit has a transfer control unit that performs DMA transfer from the host memory to the device memory, and a plurality of transfer queues that store requests indicating transfer requests specifying data to be DMA transferred. cage,
  • the transfer control unit creates one or more subsets from the data in the host memory specified by the request in each of the transfer queues, and DMA transfers the selected subsets of each of the transfer queues in order to the device memory. characterized by
  • the present invention when transferring data from a plurality of transfer sources to the same transfer destination, it is possible to satisfy the transfer efficiency and delay requirements of the transferred data in a well-balanced manner.
  • FIG. 1 is a configuration diagram of a physical server related to this embodiment
  • FIG. 2 is a configuration diagram of a DMA transfer driver in FIG. 1 relating to the present embodiment
  • FIG. FIG. 27 is a time chart when high-priority requests are kept waiting when the conventional DMA transfer driver shown in FIG. 26 is used
  • FIG. FIG. 4 is a time chart when the waiting time of high-priority requests is shortened by data division of requests when the DMA transfer driver of the present embodiment shown in FIG. 1 is used
  • FIG. 5 is a time chart when the waiting time of high-priority requests is further reduced than in the case of FIG. 4 by changing the size of the subset of requests according to the present embodiment
  • It is a time chart when the subset size of an own request regarding this embodiment is large.
  • FIG. 4 is a time chart when the subset size of own requests is small according to the present embodiment; 3 is a detailed configuration diagram of a DMA transfer driver according to this embodiment; FIG. FIG. 9 is a table showing the state of transfer processing of the DMA transfer driver of FIG. 8 according to the present embodiment at each time;
  • FIG. 4 is a configuration diagram of a queue ID table according to this embodiment;
  • FIG. 4 is a configuration diagram of a transfer queue management table according to the embodiment;
  • FIG. 4 is a configuration diagram of a subset size table according to the embodiment;
  • FIG. 4 is a configuration diagram of a request counter table according to the embodiment;
  • FIG. 4 is a configuration diagram of a transfer engine table according to the embodiment;
  • FIG. 4 is a configuration diagram of a priority table according to the embodiment;
  • FIG. 3 is a hardware configuration diagram of a physical server according to the embodiment;
  • FIG. FIG. 5 is a sequence diagram showing request transfer processing of a physical server according to the embodiment;
  • FIG. 18 is a sequence diagram showing the request transfer processing of the physical server following FIG. 17;
  • FIG. 10 is a flow chart showing processing of notifying a request from a reception queue to a transfer queue according to the embodiment;
  • FIG. 11 is a flow chart showing processing for notifying a transfer engine of a subset of requests from a transfer queue according to the present embodiment;
  • FIG. FIG. 10 is a flowchart showing a process of DMA-transferring a subset from a transfer engine to a device according to this embodiment;
  • FIG. 7 is a flowchart illustrating a first example of processing for changing the subset size of requests according to the present embodiment
  • FIG. 23 is a time-series graph of subset sizes of high priority and low priority in the first example of FIG. 22
  • FIG. 11 is a flowchart illustrating a second example of processing for changing the subset size of requests according to the present embodiment
  • FIG. FIG. 25 is a time-series graph of subset sizes of high priority and low priority in the second example of FIG. 24
  • FIG. 1 is a configuration diagram of a conventional physical server
  • FIG. FIG. 27 is a configuration diagram of a DMA transfer driver in FIG. 26;
  • FIG. 1 is a configuration diagram of a physical server 100.
  • a physical server (transfer management device) 100 has a host (host unit) 10 having a host DRAM (host memory) 12 in which transfer source data is stored, and a device DRAM (device memory) 51 as a data transfer destination.
  • device 50 device section.
  • the thread 11 is, for example, a network application that speeds up data processing using the accelerator device 50, and operates according to the vRAN (virtual radio access network) standard.
  • vRAN virtual radio access network
  • a plurality of threads 11 each issues a request, which is a data transfer request, to the host DRAM 12 .
  • a DMA transfer driver (transfer control unit) 1 reads the data of each request and sequentially transfers the data to the device DRAM 51 in the device 50 via the PCIe 59 .
  • An IP core 52 which is an FPGA within the device 50, reads and processes the data of each request transferred to the device DRAM51.
  • FIG. 2 is a configuration diagram of the DMA transfer driver 1 of FIG.
  • the DMA transfer driver 1 has a reception queue 20 , a transfer queue 30 and a transfer engine 40 .
  • the DMA transfer driver 1 creates one or more subsets from the data in the host DRAM 12 specified by the request in each transfer queue 30 and DMA-transfers the sequentially selected subsets of each transfer queue 30 to the device DRAM 51 .
  • the reception queue 20 stores requests issued from each thread 11 as pointers in the host DRAM 12 .
  • the transfer queue 30 stores the pointer of the request read from the reception queue 20 to notify the transfer engine 40 .
  • one transfer queue 30z is provided in one DMA transfer driver 1z, but in FIG. 2, one DMA transfer driver 1 is provided with a plurality of transfer queues 30.
  • Each transfer queue 30 is prepared, for example, for each priority of a request, and one or more requests with the same priority are stored in the same transfer queue 30 . In this specification, a request with a higher priority value is prioritized over other requests in the DMA transfer process.
  • each queue in FIG. 2 is expanded from each queue in FIG. 27 as follows.
  • the reception queue 20 corresponds to a plurality of transfer queues 30, and a request can be distributed to any one of the transfer queues 30 according to an instruction from the transfer queue determination unit 21 of FIG.
  • Individual priorities are assigned to the plurality of transfer queues 30, and requests of the priorities are stored.
  • Each transfer queue 30 is extended to enqueue (insert into the queue) a single request and then dequeue (remove from the queue) the request divided into multiple subsets. Therefore, the transfer queue 30 may have separate areas for storing requests before division and areas for storing subsets after division.
  • the transfer engine 40 is extended so that subsets from a plurality of transfer queues 30 can be sequentially read and transferred according to instructions from the transfer queue selector 41 of FIG.
  • a "subset" of the request that is, one I will call it a split request.
  • the transfer engine 40 sequentially reads requests in the host DRAM 12 from pointers in the transfer queue 30 and transfers the requests to the device DRAM 51 . Each transfer engine 40 does not accept the next request until the transfer of the request accepted by itself is completed. When the transfer engine 40 enters a ready state in which no transfer is being performed, if there is only one transfer queue 30 with a subset, the transfer engine 40 takes out the subset from the transfer queue 30 and transfers it.
  • the transfer engine 40 takes out and transfers the subsets from the transfer queues 30 selected in order by a method such as round robin.
  • the selection method of the transfer queue 30 may be flexibly changed to round robin, weighted round robin, or the like, but logic with relatively light load is preferable.
  • a plurality of transfer engines 40 may be provided within one DMA transfer driver 1 . Each transfer engine 40 can perform transfer processing in parallel unless requests are transferred to the same transfer destination at the same time.
  • FIG. 3 is a time chart when high-priority requests R2 and R3 are kept waiting when the conventional DMA transfer driver 1z shown in FIG. 26 is used.
  • the horizontal axis of the time chart indicates time slots (time t0 to t9), and the vertical axis indicates requests stored in each component in physical server 100z at each time.
  • pointers are issued in the order of three types of requests R1, R2, and R3 in the reception queue 20z.
  • the request R1 has a large data size but has a low priority, and the requests R2 and R3 have a small data size but have a high priority (with strict TAT requirements).
  • the pointers of requests R1, R2, and R3 are enqueued from the reception queue 20z into the transfer queue 30z in this order.
  • the transfer engine 40z reads the request R1 from the transfer queue 30z and DMA transfers it from the host DRAM 12z to the device DRAM 51z.
  • the request R1 is first stored in the IP core 52z(#1) after time t6.
  • the transfer engine 40z reads the remaining requests R2 and R3 from the transfer queue 30z and DMA transfers them.
  • the request R2 arrives at the IP core 52z(#1) at time t6
  • the request R3 arrives at the IP core 52z(#2) at time t7.
  • the high-priority requests R2 and R3 failed to comply with the delay requirement due to the long waiting time caused by the request R1 from time t3 to t5.
  • FIG. 4 is a time chart when the waiting time of high-priority requests R2 and R3 is reduced by data division of requests when the DMA transfer driver 1 of this embodiment shown in FIG. 1 is used.
  • time t0 similarly to time t1 in FIG. 3, pointers are issued in the order of three types of requests R1, R2, and R3 in the reception queue 20 (the priority and size of each request, and the illustrated painting pattern are also (identical to FIG. 3).
  • a low-priority transfer queue 30 (#1) is assigned a low-priority request R1
  • a high-priority transfer queue 30 (#2) is assigned high-priority requests R2 and R3.
  • the pointer of each request is enqueued in the transfer queue 30, so the size of the requests is not directly shown in the time chart.
  • the requests in the transfer queue 30 are then divided into a plurality of subsets of the same determined size until they are dequeued.
  • Each of the high priority requests R2 and R3 is divided into two, and the low priority request R1 is divided into twelve.
  • the transfer engine 40 sequentially (round robin) reads subsets from the two transfer queues 30 and DMA transfers them from the host DRAM 12 to the device DRAM 51 .
  • the requests R2 and R3 that enter the DMA transfer driver 1 later at time t0 are transferred through the interval between the divisions of the request R1 that entered earlier at time t0, thereby suppressing the delay. rice field.
  • FIG. 5 is a time chart when the waiting time of high-priority requests is further reduced than in the case of FIG. 4 by changing the subset size of requests.
  • the DMA transfer driver 1 refers to the priority of each request to determine the size of the subset. Times t0 and t1 are the same in FIGS. One or more subsets are generated from the requests in the transfer queue 30 according to the size according to the priority of each request.
  • the DMA transfer driver 1 (transfer size determination unit 33 in FIG. 8) increases the subset size as the priority is higher.
  • the high-priority requests R2 and R3 are not divided and become subsets one by one.
  • a low-priority request R1 is divided into twelve.
  • the transfer engine 40 sequentially (round robin) reads subsets from the two transfer queues 30 and DMA transfers them from the host DRAM 12 to the device DRAM 51 .
  • FIG. 6 is a time chart when the subset size of own request R1 is large.
  • the subset size of its own request R1 it is divided into two subsets and DMA-transferred.
  • the other request R2 started DMA transfer at time t3 and arrived at the IP core 52 (#2) at time t4. Therefore, the amount of one-time transfer of the own request R1 increases, and the other request R2 cannot be transferred during that time, so transfer interruption (preemption) is less likely to occur. Therefore, the throughput of the own request R1 increases, and the TAT of the other request R2 deteriorates.
  • FIG. 7 is a time chart when the subset size of own request R1 is small.
  • the subset size of own request R1 it is divided into four subsets and DMA-transferred.
  • the other request R2 started DMA transfer at time t2 and arrived at the IP core 52 (#2) at time t3. Therefore, the amount of one-time transfer of the own request R1 is reduced, and the other request R2 can be transferred in between, making the transfer more likely to be interrupted. Therefore, the throughput of the own request R1 is reduced, and the TAT of the other request R2 is improved.
  • the subset size is a trade-off between throughput and TAT. Therefore, the DMA transfer driver 1 attempts optimization by flexibly changing the subset size. By changing the subset size, the frequency with which the request is interrupted by transfer requests from other requests is adjusted (details are shown in FIGS. 22 to 25).
  • FIG. 8 is a detailed block diagram of the DMA transfer driver 1.
  • the DMA transfer driver 1 includes, in addition to the reception queue 20, M transfer queues 30, and N transfer engines 40 described with reference to FIG. It has a counter 31 , a request division unit 32 , a transfer size determination unit 33 , a transfer queue selection unit 41 , an integrated control unit 42 and an external controller IF 61 .
  • each arrow of FIG. 8 is as follows. ⁇ Bold solid arrow: Request path ⁇ Bold dashed arrow: Management signal (m-plane) path ⁇ Thin solid arrow: Control signal (c-plane) path
  • the transfer queue determination unit 21 dequeues the request in the reception queue 20 and determines which transfer queue 30 to enqueue.
  • the request counter 31 counts the number of requests stored in each transfer queue 30 .
  • the priority determination unit 22 determines the priority of the request based on the content of the request or information from the external controller IF61.
  • the transfer size determination unit 33 determines the size of subsets when splitting a request based on the priority of the request and the communication requirements (TAT, throughput, etc.) required for the request. For example, the transfer size determining unit 33 desirably increases the size of the subset as the priority of the request is higher. As a result, the higher the priority of the request, the more data can be transferred at once, so the throughput and TAT of the high priority request can be improved.
  • the request division unit 32 divides the request based on the size determined by the transfer size determination unit 33 .
  • the transfer queue selector 41 determines from which transfer queue 30 an empty transfer engine 40 dequeues a subset.
  • the integrated control unit 42 sets setting information for the transfer size determining unit 33 (designation of the minimum and maximum size of the subset) and setting information for the transfer queue selection unit 41 (designation of the read count policy). control.
  • a control signal from the external controller 60 is notified inside the DMA transfer driver 1 such as the priority determining unit 22 via the external controller IF 61 .
  • external cooperation can be executed, such as the external controller 60 notifying the priority determining unit 22 of the priority of each request.
  • the DMA transfer driver 1 includes the request division unit 32 and the transfer queue selection unit 41, so that each request is divided into a plurality of subsets with a fixed size and then DMA-transferred as described with reference to FIG. .
  • the processing does not refer to the priority of each request, so the development cost for modifying the DMA transfer driver 1 can be eliminated.
  • the DMA transfer driver 1 includes the priority determination unit 22 and the transfer size determination unit 33 in addition to the request division unit 32 and the transfer queue selection unit 41, so that each Requests are divided into one or more subsets according to priority and then DMA transferred. As a result, the completion of the DMA transfer of the requests R2 and R3 could be made earlier than in FIG. On the other hand, some development costs are required for modifying the DMA transfer driver 1 to allow the DMA transfer driver 1 to recognize the priority of each request.
  • FIG. 9 is a table 70 showing the state of transfer processing of the DMA transfer driver 1 of FIG. 8 at each time.
  • Table 70 shows the data stored in reception queue 20, transfer queue 30 (#1 for low priority, #2 for high priority), transfer engine 40, and device DRAM 51, which are components for each of times T1 to T7. .
  • the components of the DMA transfer driver 1 shown in FIG. 8 will be clarified by explaining the contents of the table 70 along the time T1 to T7.
  • request B (low priority) is received in the reception queue 20 .
  • the two transfer queues 30 (#1, #2) are both empty (no stored entries), and the transfer engine 40 is also empty.
  • the transfer queue determination unit 21 enqueues the request B dequeued from the reception queue 20 to the transfer queue 30 (#1) determined by referring to the priority of the request determined by the priority determination unit 22 .
  • the transfer size determining unit 33 refers to the subset size table 73 of FIG. 12 and determines the division size and division number (here, 2) of the request B in the transfer queue 30 (#1).
  • the request dividing unit 32 divides the request B into two subsets of requests B1 and B2.
  • the transfer queue selection unit 41 dequeues the request B1 from the transfer queue 30 (#1) selected by referring to the transfer engine table 75 of FIG. 14, and requests the transfer engine 40 to perform DMA transfer.
  • the transfer engine 40 DMA-transfers the request B1 to the device DRAM 51 .
  • request A (high priority) is received in the reception queue 20 .
  • the transfer queue determination unit 21 enqueues the request A dequeued from the reception queue 20 to the transfer queue 30 (#2) determined by referring to the priority of the request determined by the priority determination unit 22 .
  • the request dividing unit 32 divides the request A in the transfer queue 30 (#2) into one subset because the original size is small.
  • the transfer queue selection unit 41 refers to the transfer engine table 75 and dequeues the request A of the transfer queue 30 (#2) instead of the request B2 of the transfer queue 30 (#1) as the next processing target.
  • the transfer engine 40 DMA-transfers the request A to the device DRAM 51 .
  • the request A which arrived at the reception queue 20 later than the request B, was transmitted with priority over the request B2, thereby keeping the TAT.
  • FIG. 10 is a configuration diagram of the queue ID table 71. As shown in FIG. A transfer queue ID is registered in the queue ID table 71 for each priority.
  • the transfer queue determination unit 21 refers to the queue ID table 71 and selects the transfer queue 30 of the transfer destination.
  • the integrated control unit 42 writes entries in the queue ID table 71 in advance.
  • FIG. 11 is a configuration diagram of the transfer queue management table 72. As shown in FIG. The transfer queue management table 72 registers the usage status for each transfer queue ID.
  • the transfer queue determination unit 21 refers to the transfer queue management table 72, which is held by the integrated control unit 42, and checks whether the transfer queue 30 can be used.
  • the integrated control unit 42 updates the latest status of the transfer queue 30 as an entry in the transfer queue management table 72 as needed.
  • FIG. 12 is a configuration diagram of the subset size table 73.
  • the subset size table 73 registers a subset size range (minimum size, maximum size) and a subset size for each time slot (slot 0, slot 1, . . . ) for each transfer queue ID.
  • the request dividing unit 32 refers to the subset size table 73 to determine the size to divide each request.
  • the integrated control unit 42 sets the subset size range of the subset size table 73 in advance. Based on the request counter table 74 (FIG. 13), the transfer size determining unit 33 writes the subset size for each time slot to the subset size table 73 within the range of the subset size.
  • FIG. 13 is a configuration diagram of the request counter table 74. As shown in FIG.
  • the request counter table 74 stores the total number of requests arriving at the transfer queue 30 and the number of requests in each time slot (slot 0, slot 1, . . . ) for each transfer queue ID (for each priority). ).
  • the transfer size determination unit 33 refers to the request counter table 74 to determine the size of the subset.
  • FIG. 14 is a configuration diagram of the transfer engine table 75.
  • a transfer engine table 75 is prepared for each transfer engine 40 .
  • the subset read count and the size of the subset are associated with each transfer queue ID. These contents are set from the integrated control unit 42 .
  • the transfer queue selector 41 refers to the transfer engine table 75 to determine from which transfer queue 30 a specific transfer engine 40 should dequeue the subset. For example, in the transfer engine table 75 of FIG. 14, the read count is 1 for each. Therefore, the transfer queue selection unit 41 reads one subset from the transfer queue (0) this time, and then reads one subset from the transfer queue (1) next time. Note that when the size of the subset read out reaches the value registered in the transfer engine table 75 instead of the number of times of reading, the transfer queue selection unit 41 switches to dequeue the subset from another transfer queue 30 next time. may
  • FIG. 15 is a configuration diagram of the priority table 76.
  • the priority determining unit 22 determines the priority of requests issued from each thread 11 as exemplified in (Method 1) to (Method 3) below.
  • the thread 11 individually passes the priority to the DMA transfer driver 1 as a parameter for each request without referring to the priority table 76 .
  • An API (Application Programming Interface) example of the thread 11 for parameter passing is implemented by a data write command "write(priority, *buf, size);”.
  • the API of this write command is an API to the effect that the data of the data size of size from the pointer position of *buf in the host DRAM 12 is written to the device DRAM 51 with the priority of priority.
  • Method 2 By referring to the base priority of the priority table 76, a fixed priority is set for each request of a specific thread ID, even over time. For example, in the priority table 76 of FIG. 15, it is determined that thread #1 has priority "0" and thread #2 has priority "2". (Method 3) Referring to the priority of each time slot (t1, t2, t3, . priority dynamically depending on the For example, in the priority table 76 of FIG. 15, when the time slot is t2, the thread #1 is assigned priority "1" and the thread #2 is assigned priority "2".
  • FIG. 16 is a hardware configuration diagram of the physical server 100.
  • Physical server 100 is configured as computer 900 having CPU 901 , RAM 902 , ROM 903 , HDD 904 , communication I/F 905 , input/output I/F 906 and media I/F 907 .
  • Accelerator 905 is device 50 ( FIG. 1 ) that processes at least one of data from communication I/F 908 and data from RAM 902 at high speed.
  • a type look-aside type that returns the execution result to the CPU 901 or the RAM 902 after executing the processing from the CPU 901 or the RAM 902 may be used.
  • accelerator 905 a type (in-line type) that performs processing by entering between the communication I/F 908 and the CPU 901 or the RAM 902 may be used.
  • Accelerator 905 is connected to external device 915 via communication I/F 908 .
  • Input/output I/F 906 is connected to input/output device 916 .
  • a media I/F 907 reads and writes data from a recording medium 917 .
  • the CPU 901 controls each processing unit by executing a program (also called an application or an app for short) read into the RAM 902 .
  • This program can be distributed via a communication line or recorded on a recording medium 917 such as a CD-ROM for distribution.
  • FIG. 17 is a sequence diagram showing request transfer processing of the physical server 100.
  • the priority determining unit 22 reads the metadata (description information) of the request from the reception queue 20 (S201), and notifies the transfer queue determining unit 21 of the extracted priority information of the request (S202). Based on the priority information of the request, the transfer queue determining unit 21 determines the storage destination of the request as the transfer queue information (#0) (S203). The transfer queue determination unit 21 enqueues the request dequeued from the reception queue 20 to the transfer queue 30 (#0) (S204).
  • FIG. 18 is a sequence diagram showing the request transfer processing of the physical server 100 following FIG.
  • the transfer queue selector 41 checks whether or not a request is stored in the transfer queue 30 (#0) (S211), and receives notification of the stored request (S212).
  • the transfer engine 40 (#0) is in an idle state, not in transfer, and notifies the transfer queue selector 41 that new requests can be accepted (S213).
  • the transfer queue selection unit 41 requests the transfer queue 30 (#0) to transfer the request notified in S212 to the transfer engine 40 (#0) notified in S213 (S214).
  • the request dividing unit 32 receives the request requested to be transferred in S214 (S215), divides it into subsets, and notifies the transfer engine 40 (#0) of the subsets (S216).
  • FIG. 19 is a flow chart showing the process of notifying the transfer queue 30 of a request from the reception queue 20 .
  • the transfer queue determination unit 21 determines whether or not a new request has been received from the thread 11 to the reception queue 20 (S101). If Yes in S101, the metadata (description information) of the request is transmitted from the reception queue 20 to the priority determination unit 22 (S102). If No in S101, proceed to S103.
  • the transfer queue determination unit 21 determines whether or not there is a request for which transfer queue information to be enqueued has been determined (S103). If No in S103, the process returns to S101.
  • the transfer queue determining unit 21 determines whether or not there is a vacancy in the transfer queue 30 indicated by the determined transfer queue information (S104). If No in S104, the process returns to S101. If Yes in S104, the transfer queue determining unit 21 transmits (enqueues) the request to the transfer queue 30 based on the transfer queue information (S105).
  • FIG. 20 is a flow chart showing the process of notifying the transfer engine 40 of a subset of requests from the transfer queue 30 .
  • the transfer queue selector 41 selects the transfer queue 30 to dequeue the request. Then, the transfer queue selection unit 41 determines whether or not it has received from the transfer engine 40 that is available (S111). If No in S111, the process returns to S111. If Yes in S111, the request dividing unit 32 divides the requests in the transfer queue 30 into subsets. The transfer size determination unit 33 determines the size of the subset. Then, the transfer queue selection unit 41 transmits the divided subsets to the transfer engine 40 that has received the reception availability notification in S111 (S112). Further, the transfer queue selection unit 41 notifies the number of sent subsets (the number of requests for each priority) to the request counter 31 to update the request counter table 74 (S113).
  • FIG. 21 is a flow chart showing the process of DMA transferring a subset from transfer engine 40 to device 50 .
  • the transfer engine 40 determines whether or not the previous subset is being transferred (S121). If Yes in S121, the process returns to S121. If No in S121, the transfer queue selection unit 41 determines whether or not data of a subset to be transferred exists in any of the transfer queues 30 serving as read destinations (S122). If No in S122, the process returns to S121. If Yes in S122, the transfer queue selection unit 41 refers to the transfer engine table 75 and the previous transfer history to determine the transfer queue 30 of the read destination this time (S123).
  • the transfer queue selection unit 41 transmits a subset transfer request to the transfer queue 30 (S124), and receives the subset from the transfer queue 30 (S125).
  • the transfer queue selector 41 transfers the subset of S125 to the transfer engine 40 (S126). As a result, the subset is DMA-transferred from the transfer engine 40 to the device 50 .
  • FIG. FIG. 22 is a flowchart illustrating a first example of processing for changing the subset size of requests.
  • the transfer size determining unit 33 sets the size of the subset created from the request data to the size of the subset with the low priority "1" during the period when the request with the high priority "2" does not enter the transfer queue 30.
  • the size of the low priority subset is controlled to be reduced. The details of subset size control will be described below with reference to the flowchart.
  • the transfer size determining unit 33 extracts a count value obtained by counting the number of requests currently stored in each transfer queue 30 (S301). When the count value of priority "2" has increased compared to the previous count value (Yes in S302), that is, when a burst request occurs, the transfer size determination unit 33 determines the transfer size corresponding to priority "1". The subset size of the queue 30 is returned to the initial value (S303). If No in S302 and the count value of priority "1" has increased by a certain amount or more compared to the previous count value (Yes in S304), the transfer size determining unit 33 determines the transfer queue corresponding to priority "1". Increase the subset size of 30 (S305). This subset size increasing process increases by a predetermined value (by +n) within a range not exceeding the maximum value.
  • FIG. 23 is a time-series graph of subset sizes of high priority and low priority in the first example of FIG.
  • the upper graph shows the count value c2(k) in time slot k with priority "2".
  • the lower graph shows the subset size s1(k) at time slot k with priority "1". This s1(k) increases to the maximum subset size s1max of priority "1" when throughput is prioritized.
  • the TAT with the other priority "2" has priority, it is reduced to the minimum subset size s1min with the priority "1".
  • period T11 priority "2" does not occur, so the subset size of priority "1” is increased to s1max to give priority to throughput.
  • period T12 priority "2” occurs, so the subset size of priority “1” is reduced to s1min, giving priority to TAT of priority "2".
  • period T13 priority "2” does not occur, so throughput is prioritized by gradually increasing the subset size of priority "1” to s1max.
  • priority "2” occurs, so the subset size of priority "1” is reduced to s1min, giving priority to TAT of priority "2".
  • period T15 priority "2” does not occur, so throughput is prioritized by gradually increasing the subset size of priority "1” to s1max.
  • FIG. 24 is a flowchart illustrating a second example of processing for changing the subset size of requests.
  • the priority "2" high priority
  • the transfer size determining unit 33 sets the size of the subset created from the request data to that of the low priority "1" while the number of high priority "2" requests entering the transfer queue 30 increases.
  • the size of the subset is reduced while the size of the low priority subset is increased during periods when the number of high priority requests entering the transfer queue 30 is reduced.
  • the transfer size determining unit 33 extracts the count value of the transfer queue 30 corresponding to the priority "2" of the time slot k (S402), and calculates s1(k) by (Equation 1) (S403).
  • the transfer size determination unit 33 updates the subset size in time slot k with priority "1" to s1(k) calculated in S403 (S404).
  • FIG. 25 is a time-series graph of subset sizes of high priority and low priority in the second example of FIG. Similar to FIG. 23, the upper graph shows c2(k) and the lower graph shows s1(k). Also, the threshold value c2P in the upper graph is a count threshold value with which priority "2" should be processed with the highest priority. In the period T21, since there is no request with the priority "2", the priority "1" is set to the maximum size s1max. In period T22, the number of requests with priority "2" increases, so the size of priority "1” is reduced. This improves the TAT for priority "2".
  • the present invention is a physical server 100 having a host 10 having a host DRAM 12 in which transfer source data is stored and a device 50 having a device DRAM 51 as a data transfer destination,
  • a host 10 has a DMA transfer driver 1 that performs DMA transfer from a host DRAM 12 to a device DRAM 51, and a plurality of transfer queues 30 that store requests indicating transfer requests for data to be DMA transferred,
  • the DMA transfer driver 1 creates one or more subsets from the data in the host DRAM 12 specified by the request in each transfer queue 30, and DMA-transfers the sequentially selected subsets of each transfer queue 30 to the device DRAM 51. characterized by
  • the transfer delay of each request is suppressed by dividing the request data before the DMA transfer.
  • the threads 11 request DMA transfer to the same device 50, while one thread 11 is transferring a large request, it is possible to transfer a request from another thread 11 that comes later. becomes. Therefore, since fairness among the threads 11 is maintained, the threads 11 with strict delay requirements can operate on the same physical server 100 as other threads 11 (noisy neighbors). In this way, regardless of the size of the data size of the request from each thread 11, by providing fair data transfer opportunities among the threads 11, when data is transferred from a plurality of transfer sources to the same transfer destination. , the transfer efficiency of the transferred data and the delay requirement can be met in a well-balanced manner.
  • each transfer queue 30 is assigned an individual priority and stores requests of that priority
  • the DMA transfer driver 1 is characterized in that the size of the subset created from the data of the request is increased as the priority of the request is higher.
  • the DMA transfer driver 1 has versatility so that it can handle the priority of each request, so it is implemented so that priority control (designation of transfer order and required bandwidth) is performed by directly linking between threads 11 Reduce development costs. Moreover, since the threads 11 with different priorities can be accommodated in the same physical server 100, the housing cost and power consumption can be reduced compared to a method in which a plurality of physical servers 100 are operated for each priority.
  • each transfer queue 30 is assigned an individual priority and stores requests of that priority
  • the DMA transfer driver 1 expands the size of the subset created from the data of the request while increasing the size of the subset with low priority while the high priority request does not enter the transfer queue 30. requests enter the transfer queue 30, the size of the low-priority subset is reduced.
  • each transfer queue 30 is assigned an individual priority and stores requests of that priority, As the size of the subset created from the request data, the DMA transfer driver 1 reduces the size of the low-priority subset while the number of high-priority requests entering the transfer queue 30 increases. It is characterized by controlling the size of the low-priority subset to be expanded during a period in which the number of high-priority requests entering the queue 30 decreases.
  • the subset size can be dynamically controlled to meet the transfer requirements of both high-priority and low-priority requests in a well-balanced manner.
  • DMA transfer driver (transfer control unit) 10 host (host part) 11 threads 12 host DRAM (host memory) 20 reception queue 21 transfer queue determination unit 22 priority determination unit 30 transfer queue 31 request counter 32 request division unit 33 transfer size determination unit 40 transfer engine 41 transfer queue selection unit 42 integrated control unit 50 device (device unit) 51 Device DRAM (device memory) 52 IP cores 59 PCIe 60 External controller 61 External controller IF 71 queue ID table 72 transfer queue management table 73 subset size table 74 request counter table 75 transfer engine table 76 priority table 100 physical server (transfer management device)

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

物理サーバ（１００）のホスト（１０）は、ホストDRAM（１２）からデバイスDRAM（５１）へのDMA転送を行うDMA転送ドライバ（１）と、DMA転送の対象となるデータの転送要求を示すリクエストを格納する複数の転送キュー（３０）とを有しており、DMA転送ドライバ（１）は、各転送キュー（３０）内のリクエストにより指定されたホストDRAM（１２）のデータから１つ以上のサブセットを作成し、順番に選択した各転送キュー（３０）のサブセットを、デバイスDRAM（５１）にDMA転送する。

Description

転送管理装置、転送管理方法、および、転送管理プログラム
　本発明は、転送管理装置、転送管理方法、および、転送管理プログラムに関する。
　装置内のバスを介してデータ転送する方式は、データアクセス命令をCPUが中継するPIO（Programmed Input/Output）と、CPUを介さずにデバイスとメモリとの間でデータを直接転送するDMA（Direct Memory Access）とに分類される（非特許文献１）。
　DMAのハードウェア転送により、高速かつ大容量のデータ転送ができる（非特許文献２）。DMAは、サーバ上のアプリケーション（APL：application）を転送元とし、同一サーバ上のアクセラレータやネットワークデバイスを転送先とすることが多い。
　転送エンジンは、リクエストとして受け付けた転送対象のデータを１つずつ選択してDMA転送を行う。転送エンジンは、あるデータの転送中には、次の転送を受け付けないように調整（アービトレーション）を行う。これにより、同一の転送先を同時に使用するアプリケーションが複数ある場合でも、データの衝突を回避する。
　非特許文献３には、転送エンジンの一例であるXilinx社のXDMA仕様が記載されている。Xilinxのドライバでは、転送対象のリクエストを格納するキューが複数チャンネルあり、各チャンネルからラウンドロビン（均等）にリクエストを取り出して転送する。
東光高岳、"DMA対応と言われたら（1）"、［online］、［2021年11月26日検索］、インターネット＜URL：https://uquest.tktk.co.jp/embedded/learning/lecture15-1.html＞ EDN Japan、"DMAのメリットって何？"、［online］、［2021年11月26日検索］、インターネット＜URL：https://ednjapan.com/edn/articles/1608/18/news015.html＞ XILINX、"DMA/Bridge Subsystem for PCI Express v4.1 Product Guide"、［online］、［2021年11月26日検索］、インターネット＜URL：https://www.xilinx.com/support/documentation/ip_documentation/xdma/v4_1/pg195-pcie-dma.pdf＞
　図２６は、従来の物理サーバ１００ｚの構成図である。
　複数のスレッド１１ｚは、それぞれデータのDMA転送を要求する旨のリクエスト（斜線が塗られた矩形として図示）をホストDRAM１２ｚに発行する。DMA転送ドライバ１ｚは、各リクエストを読み取って、順番にPCIe（Peripheral Component Interconnect Express）５９ｚを介して、デバイス５０ｚ内のデバイスDRAM５１ｚに転送する。
　デバイス５０ｚ内のFPGA（Field Programmable Gate Array）であるIPコア５２ｚは、デバイスDRAM５１ｚに転送された各リクエストを読み取って処理する。
　図２７は、図２６のDMA転送ドライバ１ｚの構成図である。
　DMA転送ドライバ１ｚは、受付キュー２０ｚと、転送キュー３０ｚと、転送エンジン４０ｚとを有する。
　受付キュー２０ｚは、各スレッド１１ｚから発行されたリクエストを、ホストDRAM１２ｚ内のデータの格納先を指すポインタとして格納する。転送キュー３０ｚは、受付キュー２０ｚから読み取ったリクエストのポインタを、転送エンジン４０ｚに通知するために格納する。
　転送エンジン４０ｚは、転送キュー３０ｚ内のポインタからホストDRAM１２ｚ内のリクエストのデータを順番に読み取り、そのデータをデバイスDRAM５１ｚに向けて転送する。
　複数のアプリケーション（スレッド１１ｚ）が同じ転送先に対してDMA転送を行う際には、あるリクエストの転送中に、次のリクエストの転送待ちが発生する。例えば以下の手順では、転送待ちの問題がある。
　（手順１）ファイル転送アプリケーションＡ１（第１のスレッド１１ｚ）は、データサイズの大きいファイルのリクエストＲ１を、転送エンジン４０ｚに依頼する。
　（手順２）転送エンジン４０ｚは、現時点で他に転送対象のリクエストが存在しないので、リクエストＲ１の転送を開始する。
　（手順３）通話アプリケーションＡ２（第２のスレッド１１ｚ）は、遅延（TAT：Turnaround Time）要件が短い高優先な通話データのリクエストＲ２を、転送エンジン４０ｚに依頼する。
　（手順４）転送エンジン４０ｚは、リクエストＲ１の転送が終わるまで、リクエストＲ２の転送を待たせる。
　（手順５）転送エンジン４０ｚは、リクエストＲ１の転送完了後に、リクエストＲ２の転送を完了するものの、転送待ちによりTAT要件を守れなかった。
　なお、ファイル転送アプリケーションＡ１と、通話アプリケーションＡ２とで事前に連携する仕組みを作成し、転送の順序を前もって制御するような拡張も検討する。しかし、このような拡張では、優先度の高いリクエストを先に出すことはできるものの、アプリケーションの作り込みが必要になり開発コストが高くなるので採用は避けたい。
　そこで、本発明は、複数の転送元から同じ転送先にデータ転送するときに、転送されるデータの転送効率と遅延要件とをバランスよく満たすことを主な課題とする。
　前記課題を解決するために、本発明の転送管理装置は、以下の特徴を有する。
　本発明は、転送元のデータが格納されるホストメモリを有するホスト部と、データの転送先であるデバイスメモリを有するデバイス部とを有する転送管理装置であって、
　前記ホスト部が、前記ホストメモリから前記デバイスメモリへのDMA転送を行う転送制御部と、DMA転送の対象となるデータを指定した転送要求を示すリクエストを格納する複数の転送キューとを有しており、
　前記転送制御部が、前記各転送キュー内のリクエストにより指定された前記ホストメモリのデータから１つ以上のサブセットを作成し、順番に選択した前記各転送キューのサブセットを、前記デバイスメモリにDMA転送することを特徴とする。
　本発明によれば、複数の転送元から同じ転送先にデータ転送するときに、転送されるデータの転送効率と遅延要件とをバランスよく満たすことができる。
本実施形態に関する物理サーバの構成図である。 本実施形態に関する図１のDMA転送ドライバの構成図である。 図２６で示した従来のDMA転送ドライバを用いた場合に、高優先のリクエストが待たされる場合のタイムチャートである。 図１で示した本実施形態のDMA転送ドライバを用いた場合に、リクエストのデータ分割により、高優先のリクエストの待ち時間を短縮した場合のタイムチャートである。 本実施形態に関するリクエストのサブセットサイズ変更により、図４の場合よりもさらに高優先のリクエストの待ち時間を短縮した場合のタイムチャートである。 本実施形態に関する自リクエストのサブセットサイズが大きい場合のタイムチャートである。 本実施形態に関する自リクエストのサブセットサイズが小さい場合のタイムチャートである。 本実施形態に関するDMA転送ドライバの詳細な構成図である。 本実施形態に関する図８のDMA転送ドライバの転送処理の状態を各時刻で示すテーブルである。 本実施形態に関するキューIDテーブルの構成図である。 本実施形態に関する転送キュー管理テーブルの構成図である。 本実施形態に関するサブセットサイズテーブルの構成図である。 本実施形態に関するリクエストカウンタテーブルの構成図である。 本実施形態に関する転送エンジンテーブルの構成図である。 本実施形態に関する優先度テーブルの構成図である。 本実施形態に関する物理サーバのハードウェア構成図である。 本実施形態に関する物理サーバのリクエスト転送処理を示すシーケンス図である。 図１７に続いて、物理サーバのリクエスト転送処理を示すシーケンス図である。 本実施形態に関する受付キューから転送キューにリクエストが通知される処理を示すフローチャートである。 本実施形態に関する転送キューから転送エンジンにリクエストのサブセットが通知される処理を示すフローチャートである。 本実施形態に関する転送エンジンからデバイスにサブセットがDMA転送される処理を示すフローチャートである。 本実施形態に関するリクエストのサブセットサイズの変更処理の第１例を示すフローチャートである。 図２２の第１例における高優先および低優先それぞれのサブセットサイズの時系列グラフである。 本実施形態に関するリクエストのサブセットサイズの変更処理の第２例を示すフローチャートである。 図２４の第２例における高優先および低優先それぞれのサブセットサイズの時系列グラフである。 従来の物理サーバの構成図である。 図２６のDMA転送ドライバの構成図である。
　以下、本発明の一実施形態について、図面を参照して詳細に説明する。
　図１は、物理サーバ１００の構成図である。
　物理サーバ（転送管理装置）１００は、転送元のデータが格納されるホストDRAM（ホストメモリ）１２を有するホスト（ホスト部）１０と、データの転送先であるデバイスDRAM（デバイスメモリ）５１を有するデバイス５０（デバイス部）とを有する。
　スレッド１１は、例えば、アクセラレータのデバイス５０を用いてデータ処理を高速化するネットワークアプリケーションであり、vRAN（virtual Radio Access Network）の規格に従って動作する。
　複数のスレッド１１は、それぞれデータの転送要求であるリクエストをホストDRAM１２に発行する。DMA転送ドライバ（転送制御部）１は、各リクエストのデータを読み取って、順番にPCIe５９を介して、デバイス５０内のデバイスDRAM５１に転送する。図２６と図１とでは、DMA転送ドライバ１の内部構成に差異がある（詳細は図８）。
　デバイス５０内のFPGAであるIPコア５２は、デバイスDRAM５１に転送された各リクエストのデータを読み取って処理する。
　図２は、図１のDMA転送ドライバ１の構成図である。
　DMA転送ドライバ１は、受付キュー２０と、転送キュー３０と、転送エンジン４０とを有する。DMA転送ドライバ１は、各転送キュー３０内のリクエストにより指定されたホストDRAM１２のデータから１つ以上のサブセットを作成し、順番に選択した各転送キュー３０のサブセットを、デバイスDRAM５１にDMA転送する。
　受付キュー２０は、各スレッド１１から発行されたリクエストをホストDRAM１２内のポインタとして格納する。転送キュー３０は、受付キュー２０から読み取ったリクエストのポインタを、転送エンジン４０に通知するために格納する。
　ここで、図２７では１つのDMA転送ドライバ１ｚ内に１つの転送キュー３０ｚを備える構成としたが、図２では、１つのDMA転送ドライバ１内に複数の転送キュー３０を備える構成とした。なお、各転送キュー３０は、例えば、リクエストの優先度ごとに用意され、同じ優先度となる１つ以上のリクエストが同じ転送キュー３０に格納される。なお、本明細書では、優先度の数値が高いリクエストほど他のリクエストよりも優先されてDMA転送の処理が実行される。
　よって、図２の各キューは、図２７の各キューから以下のように拡張される。
　受付キュー２０は、複数の転送キュー３０に対応し、図８の転送キュー決定部２１からの指示により、それらの転送キュー３０のいずれか１つにリクエストの振り分けを実行可能になる。
　複数の転送キュー３０には、個別の優先度が割り当てられ、その優先度のリクエストを格納する。各転送キュー３０は、１つのリクエストをエンキュー（キューに挿入）した後、そのリクエストを複数のサブセットに分割した状態でデキュー（キューから取り出し）できるように拡張される。そのため、転送キュー３０は、分割前のリクエストを格納する領域と、分割後のサブセットを格納する領域とを別々に設けてもよい。
　転送エンジン４０は、図８の転送キュー選択部４１からの指示により、複数の転送キュー３０からのサブセットを、順番に読み込んで転送できるように拡張される。
　なお、本明細書では、転送エンジン４０によりDMA転送されるリクエストがもともとサイズが小さいなどの理由により、転送キュー３０内で分割されなかった場合であっても、リクエストの「サブセット」（つまり、１分割のリクエスト）と呼ぶことにする。
　転送エンジン４０は、転送キュー３０内のポインタからホストDRAM１２内のリクエストを順番に読み取り、そのリクエストをデバイスDRAM５１に向けて転送する。
　各転送エンジン４０は、自身が受け付けたリクエストを転送完了するまでは、次のリクエストを受け付けない。そして、転送エンジン４０は、転送を行っていないready状態になった際、サブセットのある転送キュー３０が１つであれば、その転送キュー３０からサブセットを取り出して転送する。
　一方、DMA転送を待っているサブセットが格納されている転送キュー３０が複数ある場合、転送エンジン４０は、ラウンドロビンなどの方法で順番に選択した転送キュー３０からサブセットを取り出して転送する。転送キュー３０の選択方法は、ラウンドロビンや、重み付きラウンドロビンなど、柔軟に変更してもよいが、比較的負荷が軽いロジックが望ましい。
　なお、１つのDMA転送ドライバ１内に複数の転送エンジン４０を備えてもよい。各転送エンジン４０は、同時に同じ転送先にリクエストを転送しない限り、それぞれ並列に転送処理が可能である。
　以下、図３－図５のタイムチャートを参照して、図２６で示した従来のDMA転送ドライバ１ｚと、図１で示した本実施形態のDMA転送ドライバ１とで効果の違いを説明する。
　図３は、図２６で示した従来のDMA転送ドライバ１ｚを用いた場合に、高優先のリクエストＲ２，Ｒ３が待たされる場合のタイムチャートである。タイムチャートの横軸はタイムスロット（時刻ｔ０～ｔ９）を示し、縦軸は各時刻に物理サーバ１００ｚ内の各構成要素内に格納されるリクエストを示す。
　図３の時刻ｔ１では、受付キュー２０ｚ内に、３種類のリクエストＲ１，Ｒ２，Ｒ３の順にポインタが発行される。リクエストＲ１はデータサイズが大きいが低優先であり、リクエストＲ２、Ｒ３はデータサイズが小さいが高優先（TAT要件が厳しい）である。
　時刻ｔ２では、受付キュー２０ｚから転送キュー３０ｚ内に、リクエストＲ１，Ｒ２，Ｒ３のポインタがこの順にエンキューされる。
　時刻ｔ３～ｔ５では、転送エンジン４０ｚは、リクエストＲ１を転送キュー３０ｚから読み取り、ホストDRAM１２ｚからデバイスDRAM５１ｚにDMA転送する。これにより、IPコア５２ｚ（#1）には、時刻ｔ６以降にリクエストＲ１が最初に格納される。
　時刻ｔ６では、転送エンジン４０ｚは、残りのリクエストＲ２，Ｒ３を転送キュー３０ｚから読み取り、それぞれDMA転送する。これにより、IPコア５２ｚ（#1）には、時刻ｔ６にリクエストＲ２が到着し、IPコア５２ｚ（#2）には、時刻ｔ７にリクエストＲ３が到着する。
　しかし、時刻ｔ３～ｔ５のリクエストＲ１による長い待ち時間の影響により、高優先のリクエストＲ２，Ｒ３は、遅延要件を守れなかった。
　図４は、図１で示した本実施形態のDMA転送ドライバ１を用いた場合に、リクエストのデータ分割により、高優先のリクエストＲ２，Ｒ３の待ち時間を短縮した場合のタイムチャートである。
　時刻ｔ０では、図３の時刻ｔ１と同様に、受付キュー２０内に、３種類のリクエストＲ１，Ｒ２，Ｒ３の順にポインタが発行される（各リクエストの優先度、サイズや、図示する塗りパターンも図３と同一）。
　時刻ｔ１では、受付キュー２０内の各リクエストのポインタが２つの転送キュー３０に振り分けられる。低優先の転送キュー３０（#1）には、低優先のリクエストＲ１が振り分けられるとともに、高優先の転送キュー３０（#2）には、高優先のリクエストＲ２，Ｒ３が振り分けられる。この時点では、各リクエストのポインタが転送キュー３０にエンキューされるため、タイムチャートにはリクエストの大きさは直接は図示していない。
　そして、転送キュー３０内のリクエストは、デキューされるまでに決められた同じサイズで複数のサブセットに分割される。高優先のリクエストＲ２，Ｒ３はそれぞれ２分割され、低優先のリクエストＲ１は１２分割される。
　時刻ｔ２～ｔ３では、転送エンジン４０は、２つの転送キュー３０から順番に（ラウンドロビンで）サブセットを読み取り、ホストDRAM１２からデバイスDRAM５１にDMA転送する。
　これにより、IPコア５２（#1）には、時刻ｔ３にリクエストＲ２（＝２つのサブセット）が到着し、IPコア５２（#2）には、時刻ｔ４にリクエストＲ３（＝２つのサブセット）が到着する。
　一方、低優先のリクエストＲ１（＝１２個のサブセット）がIPコア５２（#1）に到着するのは、時刻ｔ６の時点となり、リクエストＲ２，Ｒ３の到着後になる。これにより、時刻ｔ０で後からDMA転送ドライバ１に入ってきたリクエストＲ２，Ｒ３は、時刻ｔ０で先に入っていたリクエストＲ１が分割された合間をぬって転送されることで、遅延を抑制できた。
　図５は、リクエストのサブセットサイズ変更により、図４の場合よりもさらに高優先のリクエストの待ち時間を短縮した場合のタイムチャートである。図５では、DMA転送ドライバ１は、リクエストごとの優先度を参照して、サブセットのサイズを決定する。
　時刻ｔ０、ｔ１は、図４と図５で同じである。
　転送キュー３０内のリクエストからは、リクエストごとの優先度に応じたサイズに応じて、１つ以上のサブセットが生成される。ここでは、DMA転送ドライバ１（図８の転送サイズ決定部３３）は、優先度が高いほど、サブセットのサイズも大きくする。その結果、高優先のリクエストＲ２，Ｒ３はそれぞれ分割されずに１つずつのサブセットとなる。低優先のリクエストＲ１は１２分割される。
　時刻ｔ２～ｔ３では、転送エンジン４０は、２つの転送キュー３０から順番に（ラウンドロビンで）サブセットを読み取り、ホストDRAM１２からデバイスDRAM５１にDMA転送する。
　これにより、IPコア５２（#1）には、時刻ｔ２にリクエストＲ２（＝１つのサブセット）が到着し、IPコア５２（#2）には、時刻ｔ３にリクエストＲ３（＝１つのサブセット）が到着する。つまり、図４に比べて、高優先のリクエストＲ２，Ｒ３がさらに早くDMA転送を完了できた。
　なお、自リクエストのサブセットサイズの変更は、自リクエストのスループットと、他リクエストのTATとに影響する。
　図６は、自リクエストＲ１のサブセットサイズが大きい場合のタイムチャートである。自リクエストＲ１のサブセットサイズを大きくとった結果、２つのセブセットに分割してDMA転送した。その結果、他リクエストＲ２は、時刻ｔ３にDMA転送を開始し、時刻ｔ４にIPコア５２（#2）に到着した。
　よって、自リクエストＲ１について一度の転送量が増え、その間は他リクエストＲ２を転送できないため、転送中断（プリエンプション）されにくくなる。そのため、自リクエストＲ１のスループットが大きくなり、他リクエストＲ２のTATが悪化する。
　図７は、自リクエストＲ１のサブセットサイズが小さい場合のタイムチャートである。自リクエストＲ１のサブセットサイズを小さくとった結果、４つのセブセットに分割してDMA転送した。その結果、他リクエストＲ２は、時刻ｔ２にDMA転送を開始し、時刻ｔ３にIPコア５２（#2）に到着した。
　よって、自リクエストＲ１について一度の転送量が減り、他リクエストＲ２を合間に転送でき、転送中断されやすくなる。そのため、自リクエストＲ１のスループットが小さくなり、他リクエストＲ２のTATが向上する。
　つまり、サブセットサイズは、スループットとTATとのトレードオフとなる。よって、DMA転送ドライバ１は、サブセットサイズを柔軟に変更することで最適化を図る。サブセットサイズを変更することにより、そのリクエストが他のリクエストからの転送要求により転送中断される頻度を調整する（詳細は図２２～図２５）。
　図８は、DMA転送ドライバ１の詳細な構成図である。
　DMA転送ドライバ１は、図２で説明した受付キュー２０と、Ｍ個の転送キュー３０と、Ｎ個の転送エンジン４０とに加えて、転送キュー決定部２１と、優先度決定部２２と、リクエストカウンタ３１と、リクエスト分割部３２と、転送サイズ決定部３３と、転送キュー選択部４１と、統合制御部４２と、外部コントローラIF６１とを有する。
　なお、図８の各矢印は、以下の通りである。
　・太線実線の矢印：リクエストの経路
　・太線破線の矢印：管理信号(m-plane)の経路
　・細線実線の矢印：制御信号(c-plane)の経路
　転送キュー決定部２１は、受付キュー２０内のリクエストをデキューし、どの転送キュー３０にエンキューするかを決定する。リクエストカウンタ３１は、各転送キュー３０に格納されるリクエストの数を計数する。優先度決定部２２は、リクエストの中身または外部コントローラIF６１からの情報を元に、リクエストの優先度を判断する。
　転送サイズ決定部３３は、リクエストの優先度や、リクエストに求められる通信要件（TAT、スループットなど）をもとに、リクエストを分割するときのサブセットのサイズを決定する。
　例えば、転送サイズ決定部３３は、リクエストの優先度が高いほど、サブセットのサイズを大きくすることが望ましい。これにより、高優先度のリクエストほど一度に多くのデータをまとめて転送できるので、その高優先度のリクエストのスループットやTATを向上できる。
　リクエスト分割部３２は、転送サイズ決定部３３が決定したサイズに基づいてリクエストを分割する。転送キュー選択部４１は、空いた転送エンジン４０が、どの転送キュー３０からサブセットをデキューするかを決定する。
　統合制御部４２は、転送サイズ決定部３３に対する設定情報（サブセットの最小・最大サイズの指定）や、転送キュー選択部４１に対する設定情報（読み出し回数ポリシーの指定）を設定するなどのDMA転送ドライバ１の制御を行う。
　外部コントローラ６０からの制御信号は、外部コントローラIF６１を介して、優先度決定部２２などのDMA転送ドライバ１内部に通知される。これにより、外部コントローラ６０が優先度決定部２２に各リクエストの優先度を通知するなど、外部連携を実行できる。
　なお、DMA転送ドライバ１は、リクエスト分割部３２と、転送キュー選択部４１とを有することで、図４で説明したように、各リクエストを固定サイズで複数のサブセットに分割してからDMA転送する。その結果、リクエストＲ１よりも後着のリクエストＲ２，Ｒ３であってもリクエストサイズが小さいから、サブセットとしては先着となり、TAT要件を守れた。さらに、図４では、リクエストごとの優先度を参照しない処理なので、DMA転送ドライバ１への改変に伴う開発コストを不要にできた。
　また、DMA転送ドライバ１は、リクエスト分割部３２と、転送キュー選択部４１とに加え、優先度決定部２２と、転送サイズ決定部３３とを有することで、図５で説明したように、各リクエストを優先度に応じた１つ以上のサブセットにしてからDMA転送する。その結果、図４よりもさらにリクエストＲ２，Ｒ３のDMA転送完了を早めることができた。一方、各リクエストの優先度をDMA転送ドライバ１に認識させるためのDMA転送ドライバ１への改変に伴う開発コストが、若干必要となる。
　図９は、図８のDMA転送ドライバ１の転送処理の状態を各時刻で示すテーブル７０である。
　テーブル７０では、時刻Ｔ１～Ｔ７ごとに、各構成要素である受付キュー２０、転送キュー３０（低優先用の#1,高優先用の#2）、転送エンジン４０、デバイスDRAM５１の格納データを示す。
　以下、時刻Ｔ１～Ｔ７に沿ってテーブル７０の内容を説明することで、図８のDMA転送ドライバ１の構成要素を明らかにする。
　時刻Ｔ１では、受付キュー２０にリクエストＢ（低優先）を受け付ける。この時点では、２つの転送キュー３０（#1,#2）はともに空（格納エントリ無し）であり、転送エンジン４０も空である。
　時刻Ｔ２では、転送キュー決定部２１は、受付キュー２０からデキューしたリクエストＢについて、優先度決定部２２が決定したリクエストの優先度を参照して決定した転送キュー３０（#1）にエンキューする。
　時刻Ｔ３では、転送サイズ決定部３３は、図１２のサブセットサイズテーブル７３を参照して、転送キュー３０（#1）内のリクエストＢの分割サイズと分割数（ここでは２）を決定する。リクエスト分割部３２は、リクエストＢをリクエストＢ１，Ｂ２という２つのサブセットに分割する。
　時刻Ｔ４では、転送キュー選択部４１は、図１４の転送エンジンテーブル７５を参照して選択した転送キュー３０（#1）からリクエストＢ１をデキューし、転送エンジン４０にDMA転送を依頼する。転送エンジン４０は、リクエストＢ１をデバイスDRAM５１にDMA転送する。このDMA転送中に、受付キュー２０にリクエストＡ（高優先）を受け付ける。
　時刻Ｔ５では、転送キュー決定部２１は、受付キュー２０からデキューしたリクエストＡについて、優先度決定部２２が決定したリクエストの優先度を参照して決定した転送キュー３０（#2）にエンキューする。リクエスト分割部３２は、転送キュー３０（#2）のリクエストＡについては、もともとのサイズが小さいので分割せずに１つのサブセットとする。
　時刻Ｔ６では、リクエストＢ１のDMA転送が完了する。転送キュー選択部４１は、転送エンジンテーブル７５を参照して、転送キュー３０（#1）のリクエストＢ２ではなく、転送キュー３０（#2）のリクエストＡを次の処理対象としてデキューする。転送エンジン４０は、リクエストＡをデバイスDRAM５１にDMA転送する。
　時刻Ｔ７では、リクエストＢよりも遅く受付キュー２０に到着したリクエストＡは、リクエストＢ２よりも優先的に送信されることでTATを守ることができた。
　以下、図１０－図１６を参照して、DMA転送ドライバ１が使用する各種のデータテーブルを説明する。
　図１０は、キューIDテーブル７１の構成図である。
　キューIDテーブル７１には、優先度ごとに、転送キューIDが登録される。
　転送キュー決定部２１は、キューIDテーブル７１を参照して転送先の転送キュー３０を選択する。統合制御部４２は、キューIDテーブル７１のエントリをあらかじめ書き込んでおく。
　図１１は、転送キュー管理テーブル７２の構成図である。
　転送キュー管理テーブル７２には、転送キューIDごとに、その使用状況が登録される。
　統合制御部４２が持っており、転送キュー決定部２１は、転送キュー管理テーブル７２を参照して、転送キュー３０の使用可否を確認する。統合制御部４２は、転送キュー３０の最新状況を転送キュー管理テーブル７２のエントリとして随時更新する。
　図１２は、サブセットサイズテーブル７３の構成図である。
　サブセットサイズテーブル７３には、転送キューIDごとの、サブセットサイズの範囲（最小サイズ、最大サイズ）と各タイムスロット（スロット0、スロット1…）でのサブセットサイズが登録される。
　リクエスト分割部３２は、サブセットサイズテーブル７３を参照して、各リクエストを分割するサイズを決定する。統合制御部４２は、サブセットサイズテーブル７３のサブセットサイズの範囲を事前に設定する。転送サイズ決定部３３は、リクエストカウンタテーブル７４（図１３）をもとに、サブセットサイズの範囲内で各タイムスロットでのサブセットサイズをサブセットサイズテーブル７３に書き出す。
　図１３は、リクエストカウンタテーブル７４の構成図である。
　リクエストカウンタテーブル７４は、転送キュー決定部２１が、転送キュー３０に到着したリクエストの合計数および各タイムスロット（スロット0、スロット1…）でのリクエスト数を、転送キューIDごとに（優先度ごとに）格納する。
　転送サイズ決定部３３は、リクエストカウンタテーブル７４を参照して、サブセットのサイズを決定する。
　図１４は、転送エンジンテーブル７５の構成図である。
　転送エンジンテーブル７５は、転送エンジン４０ごとに用意される。転送エンジンテーブル７５には、転送キューIDごとに、サブセットの読み出し回数と、サブセットのサイズとが対応付けられている。これらの内容は、統合制御部４２から設定される。
　転送キュー選択部４１は、転送エンジンテーブル７５を参照して、特定の転送エンジン４０がどの転送キュー３０からサブセットをデキューすればよいかを決定する。例えば、図１４の転送エンジンテーブル７５では、読み出し回数がそれぞれ１となっている。よって、転送キュー選択部４１は、今回は転送キュー（0）からサブセットを１つ読み出したら、次回は転送キュー（1）からサブセットを１つ読み出す。
　なお、転送キュー選択部４１は、読み出し回数の代わりに、読み出したサブセットサイズが転送エンジンテーブル７５に登録された値に達したら、次回は別の転送キュー３０からサブセットをデキューするように切り替えるようにしてもよい。
　図１５は、優先度テーブル７６の構成図である。
　優先度テーブル７６には、スレッド１１のスレッドIDごとに、ベースとなる優先度と、各タイムスロット（t1、t2、t3…）での優先度とが登録される。
　優先度決定部２２は、以下の（方法１）～（方法３）に例示するように、各スレッド１１から発行されるリクエストの優先度を決定する。
　（方法１）優先度テーブル７６を参照せず、リクエストごとにスレッド１１が個別に優先度をDMA転送ドライバ１にパラメータ渡しする。パラメータ渡しするためのスレッド１１のAPI（Application Programming Interface）例は、データの書き込み命令「write(priority, *buf, size);」などで実装される。
　この書き込み命令のAPIは、ホストDRAM１２内の*bufのポインタ位置からsizeのデータサイズ分のデータを、priorityの優先度でデバイスDRAM５１に書き出す旨のAPIである。
　（方法２）優先度テーブル７６のベースとなる優先度を参照して、特定のスレッドIDのリクエストごとに、時間経過でも固定の優先度を設定する。例えば、図１５の優先度テーブル７６では、スレッド#1では優先度「０」とし、スレッド#2では優先度「２」と決定する。
　（方法３）優先度テーブル７６の各タイムスロット（t1、t2、t3…）での優先度を参照して、外部コントローラ６０からのタイミング情報に応じたタイムスロットの優先度を設定する（時間経過に応じて動的に優先度を変更する）。例えば、図１５の優先度テーブル７６では、タイムスロット=t2の場合、スレッド#1では優先度「１」、スレッド#2では優先度「２」と決定する。
　図１６は、物理サーバ１００のハードウェア構成図である。
　物理サーバ１００は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
　アクセラレータ９０５は、通信Ｉ／Ｆ９０８からのデータ、または、ＲＡＭ９０２からのデータの少なくとも一方のデータを高速に処理するデバイス５０（図１）である。なお、アクセラレータ９０５として、ＣＰＵ９０１またはＲＡＭ９０２からの処理を実行した後にＣＰＵ９０１またはＲＡＭ９０２に実行結果を戻すタイプ（look-aside型）を用いてもよい。一方、アクセラレータ９０５として、通信Ｉ／Ｆ９０８とＣＰＵ９０１またはＲＡＭ９０２との間に入って、処理を行うタイプ（in-line型）を用いてもよい。
　アクセラレータ９０５は、通信Ｉ／Ｆ９０８を介して外部装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
　図１７は、物理サーバ１００のリクエスト転送処理を示すシーケンス図である。
　優先度決定部２２は、リクエストのメタデータ（説明情報）を受付キュー２０から読み取り（Ｓ２０１）、その中から抽出したリクエストの優先度情報を転送キュー決定部２１に通知する（Ｓ２０２）。転送キュー決定部２１は、リクエストの優先度情報をもとに、そのリクエストの格納先を転送キュー情報（＃０）として決定する（Ｓ２０３）。
　転送キュー決定部２１は、受付キュー２０からデキューしたリクエストを、転送キュー３０（＃０）にエンキューする（Ｓ２０４）。
　図１８は、図１７に続いて、物理サーバ１００のリクエスト転送処理を示すシーケンス図である。
　転送キュー選択部４１は、転送キュー３０（＃０）内にリクエストが格納されているか否かを確認し（Ｓ２１１）、格納されているリクエストの通知を受ける（Ｓ２１２）。転送エンジン４０（＃０）は、転送中ではない空き状態であり、新たなリクエストの受付可能の旨を転送キュー選択部４１に通知する（Ｓ２１３）。
　転送キュー選択部４１は、Ｓ２１２で通知されたリクエストを、Ｓ２１３で通知された転送エンジン４０（＃０）に転送させるように、転送キュー３０（＃０）に要求する（Ｓ２１４）。
　リクエスト分割部３２は、Ｓ２１４で転送要求されたリクエストを受けて（Ｓ２１５）、サブセットに分割し、そのサブセットを転送エンジン４０（＃０）に通知する（Ｓ２１６）。
　図１９は、受付キュー２０から転送キュー３０にリクエストが通知される処理を示すフローチャートである。
　転送キュー決定部２１は、スレッド１１から受付キュー２０に新規リクエストを受信したか否かを判定する（Ｓ１０１）。Ｓ１０１でYesなら、リクエストのメタデータ（説明情報）が、受付キュー２０から優先度決定部２２に送信される（Ｓ１０２）。Ｓ１０１でNoなら、Ｓ１０３に進む。
　転送キュー決定部２１は、エンキュー先となる転送キュー情報を決定したリクエストがあるか否かを判定する（Ｓ１０３）。Ｓ１０３でNoなら、Ｓ１０１に戻る。
　Ｓ１０３でYesなら、転送キュー決定部２１は、決定した転送キュー情報が示す転送キュー３０に空きがあるか否かを判定する（Ｓ１０４）。Ｓ１０４でNoなら、Ｓ１０１に戻る。
　Ｓ１０４でYesなら、転送キュー決定部２１は、転送キュー情報を元にリクエストを転送キュー３０に送信（エンキュー）する（Ｓ１０５）。
　図２０は、転送キュー３０から転送エンジン４０にリクエストのサブセットが通知される処理を示すフローチャートである。
　転送キュー選択部４１は、リクエストをデキューする転送キュー３０を選択する。そして、転送キュー選択部４１は、空いた転送エンジン４０から受付可能の旨を受信したか否かを判定する（Ｓ１１１）。Ｓ１１１でNoなら、Ｓ１１１に戻る。
　Ｓ１１１でYesなら、リクエスト分割部３２は、転送キュー３０内のリクエストをサブセットに分割する。サブセットのサイズは、転送サイズ決定部３３が決定する。
　そして、転送キュー選択部４１は、分割したサブセットを、Ｓ１１１で受付可能の通知を受けた転送エンジン４０に送信する（Ｓ１１２）。また、転送キュー選択部４１は、送付したサブセット数（優先度ごとのリクエスト数）をリクエストカウンタ３１に通知して、リクエストカウンタテーブル７４を更新させる（Ｓ１１３）。
　図２１は、転送エンジン４０からデバイス５０にサブセットがDMA転送される処理を示すフローチャートである。
　転送エンジン４０は、前回のサブセットを転送中か否かを判定する（Ｓ１２１）。Ｓ１２１でYesなら、Ｓ１２１に戻る。
　Ｓ１２１でNoなら、転送キュー選択部４１は、読み出し先となるいずれかの転送キュー３０の中に転送対象となるサブセットのデータが存在するか否かを判定する（Ｓ１２２）。Ｓ１２２でNoなら、Ｓ１２１に戻る。
　Ｓ１２２でYesなら、転送キュー選択部４１は、転送エンジンテーブル７５と、前回の転送履歴とを参照して、今回の読み出し先の転送キュー３０を決定する（Ｓ１２３）。
　転送キュー選択部４１は、サブセットの転送要求を転送キュー３０に送信し（Ｓ１２４）、その転送キュー３０からサブセットを受信する（Ｓ１２５）。転送キュー選択部４１は、Ｓ１２５のサブセットを転送エンジン４０に転送する（Ｓ１２６）。これにより、転送エンジン４０からデバイス５０にサブセットがDMA転送される。
　以下、転送サイズ決定部３３によるリクエストのサブセットサイズを動的に変更する処理について、図２２～図２６を参照して説明する。
　図２２は、リクエストのサブセットサイズの変更処理の第１例を示すフローチャートである。
　この第１例では、優先度「２」（高優先度）のリクエストの発生頻度が通常は少ないものの、ランダムな期間にバーストで（大量に）発生する場合を説明する。
　この場合、転送サイズ決定部３３は、リクエストのデータから作成するサブセットのサイズとして、高優先度「２」のリクエストが転送キュー３０に入ってこない期間には、低優先度「１」のサブセットのサイズを拡大し、一方、高優先度のリクエストが転送キュー３０に入ってくる期間には、低優先度のサブセットのサイズを縮小するように制御する。以下、フローチャートに沿って、サブセットサイズの制御内容を説明する。
　転送サイズ決定部３３は、現時点の各転送キュー３０に格納されているリクエスト数をカウントしたカウント値を抽出する（Ｓ３０１）。
　優先度「２」のカウント値が前回のカウント値と比べて増加した場合（Ｓ３０２でYes）、つまりバーストでリクエストが発生した場合、転送サイズ決定部３３は、優先度「１」に対応する転送キュー３０のサブセットサイズを初期値に戻す（Ｓ３０３）。
　Ｓ３０２でNo、かつ、優先度「１」のカウント値が前回のカウント値と比べて一定以上増加した場合（Ｓ３０４でYes）、転送サイズ決定部３３は、優先度「１」に対応する転送キュー３０のサブセットサイズを増やす（Ｓ３０５）。このサブセットサイズの増加処理は、最大値を超えない範囲で所定値ずつ（＋nずつ）増やす。
　図２３は、図２２の第１例における高優先および低優先それぞれのサブセットサイズの時系列グラフである。
　上側のグラフは、優先度「２」のタイムスロットkにおけるカウント値c2(k)を示す。
　下側のグラフは、優先度「１」のタイムスロットkにおけるサブセットサイズs1(k)を示す。このs1(k)は、スループット優先時には、優先度「１」の最大サブセットサイズs1maxまで増加する。一方、他優先度「２」のTATの優先時には、優先度「１」の最小サブセットサイズs1minまで減少する。
　期間Ｔ１１では、優先度「２」が発生していないので、優先度「１」のサブセットサイズはs1maxまで増加することで、スループットを優先する。期間Ｔ１２では、優先度「２」が発生したので、優先度「１」のサブセットサイズはs1minまで減少することで、優先度「２」のTATを優先する。
　期間Ｔ１３では、優先度「２」が発生していないので、優先度「１」のサブセットサイズをs1maxまで徐々に増加することで、スループットを優先する。期間Ｔ１４では、優先度「２」が発生したので、優先度「１」のサブセットサイズはs1minまで減少することで、優先度「２」のTATを優先する。
　期間Ｔ１５では、優先度「２」が発生していないので、優先度「１」のサブセットサイズをs1maxまで徐々に増加することで、スループットを優先する。
　図２４は、リクエストのサブセットサイズの変更処理の第２例を示すフローチャートである。
　この第２例では、優先度「２」（高優先度）が一定の周期で増減する場合を説明する。
　この場合、転送サイズ決定部３３は、リクエストのデータから作成するサブセットのサイズとして、転送キュー３０に入ってくる高優先度「２」のリクエストが増加する期間には、低優先度「１」のサブセットのサイズを縮小し、一方、転送キュー３０に入ってくる高優先度のリクエストが減少する期間には、低優先度のサブセットのサイズを拡大するように制御する。以下、フローチャートに沿って、サブセットサイズの制御内容を説明する。
　転送サイズ決定部３３は、ループ変数kについて、初期値k=0から、タイムスロット数未満の範囲で（k<タイムスロット数）１つずつ増加させる（k++）ループ処理を行う（Ｓ４０１～Ｓ４０５）。
　転送サイズ決定部３３は、タイムスロットkの優先度「２」に対応する転送キュー３０のカウント値を抽出し（Ｓ４０２）、s1(k)を（数式１）により計算する（Ｓ４０３）。
Figure JPOXMLDOC01-appb-M000001
　そして、転送サイズ決定部３３は、優先度「１」のタイムスロットkにおけるサブセットサイズを、Ｓ４０３で計算したs1(k)に更新する（Ｓ４０４）。
　図２５は、図２４の第２例における高優先および低優先それぞれのサブセットサイズの時系列グラフである。
　図２３と同様に、上側のグラフはc2(k)を示し、下側のグラフはs1(k)を示す。また、上のグラフの閾値c2Pは、優先度「２」を最優先で処理すべきカウント閾値である。
　期間Ｔ２１では、優先度「２」のリクエストがないので、優先度「１」は最大サイズs1maxとする。
　期間Ｔ２２では、優先度「２」のリクエストが増えてくるので、優先度「１」のサイズを縮小する。これにより、優先度「２」のTATを向上させる。
　期間Ｔ２３では、優先度「２」のリクエストが閾値c2Pを超えた場合は、優先度「１」は最小サイズs1minとする。
　期間Ｔ２４では、優先度「２」のリクエストが減ってくるので、優先度「１」のサイズを拡大する。これにより、優先度「１」のスループットを向上させる。
［効果］
　本発明は、転送元のデータが格納されるホストDRAM１２を有するホスト１０と、データの転送先であるデバイスDRAM５１を有するデバイス５０とを有する物理サーバ１００であって、
　ホスト１０が、ホストDRAM１２からデバイスDRAM５１へのDMA転送を行うDMA転送ドライバ１と、DMA転送の対象となるデータの転送要求を示すリクエストを格納する複数の転送キュー３０とを有しており、
　DMA転送ドライバ１が、各転送キュー３０内のリクエストにより指定されたホストDRAM１２のデータから１つ以上のサブセットを作成し、順番に選択した各転送キュー３０のサブセットを、デバイスDRAM５１にDMA転送することを特徴とする。
　これにより、リクエストのデータをDMA転送前に分割することで、各リクエストの転送遅延が抑制される。例えば、複数のスレッド１１が同じデバイス５０に対してDMA転送をリクエストする際、片方のスレッド１１からのサイズの大きなリクエストの転送中でも、後から入ってきた別のスレッド１１からのリクエストの転送が可能となる。
　よって、スレッド１１間の公平性が保たれるので、遅延要件の厳しいスレッド１１を他のスレッド１１（ノイジーネイバ）と同一の物理サーバ１００上で動作できる。
　このように、各スレッド１１からのリクエストのデータサイズの大小にもかかわらず、スレッド１１間で公平にデータ転送の機会を提供することで、複数の転送元から同じ転送先にデータ転送するときに、転送されるデータの転送効率と遅延要件とをバランスよく満たすことができる。
　本発明は、各転送キュー３０には、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
　DMA転送ドライバ１が、リクエストのデータから作成するサブセットのサイズとして、リクエストの優先度が高いほど、サブセットのサイズを大きくすることを特徴とする。
　これにより、リクエストの優先度が高いほど、サブセットのサイズを大きくすることでデータ転送の効率が高まる。よって、DMA転送ドライバ１が各リクエストの優先度を扱えるように汎用性を持つので、スレッド１１間で直接連携して優先度制御（転送順序の指定や必要帯域の指定）を行うように実装する開発コストを削減できる。
　また、互いに異なる優先度のスレッド１１同士を同じ物理サーバ１００に収容できるので、優先度ごとに複数の物理サーバ１００を稼働させる方式に比べ、筐体コストや消費電力を削減できる。
　本発明は、各転送キュー３０には、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
　DMA転送ドライバ１が、リクエストのデータから作成するサブセットのサイズとして、高優先度のリクエストが転送キュー３０に入ってこない期間には、低優先度のサブセットのサイズを拡大し、一方、高優先度のリクエストが転送キュー３０に入ってくる期間には、低優先度のサブセットのサイズを縮小するように制御することを特徴とする。
　これにより、高優先度のリクエストの発生頻度が通常は少ないものの、ランダムな期間にバーストで発生する場合に、高優先度および低優先度のリクエスト双方の転送要件をバランスよく満たすようなサブセットのサイズを動的に制御できる。
　本発明は、各転送キュー３０には、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
　DMA転送ドライバ１が、リクエストのデータから作成するサブセットのサイズとして、転送キュー３０に入ってくる高優先度のリクエストが増加する期間には、低優先度のサブセットのサイズを縮小し、一方、転送キュー３０に入ってくる高優先度のリクエストが減少する期間には、低優先度のサブセットのサイズを拡大するように制御することを特徴とする。
　これにより、高優先度のリクエストが一定の周期で増減する場合に、高優先度および低優先度のリクエスト双方の転送要件をバランスよく満たすようなサブセットのサイズを動的に制御できる。
　１　　　DMA転送ドライバ（転送制御部）
　１０　　ホスト（ホスト部）
　１１　　スレッド
　１２　　ホストDRAM（ホストメモリ）
　２０　　受付キュー
　２１　　転送キュー決定部
　２２　　優先度決定部
　３０　　転送キュー
　３１　　リクエストカウンタ
　３２　　リクエスト分割部
　３３　　転送サイズ決定部
　４０　　転送エンジン
　４１　　転送キュー選択部
　４２　　統合制御部
　５０　　デバイス（デバイス部）
　５１　　デバイスDRAM（デバイスメモリ）
　５２　　IPコア
　５９　　PCIe
　６０　　外部コントローラ
　６１　　外部コントローラIF
　７１　　キューIDテーブル
　７２　　転送キュー管理テーブル
　７３　　サブセットサイズテーブル
　７４　　リクエストカウンタテーブル
　７５　　転送エンジンテーブル
　７６　　優先度テーブル
　１００　物理サーバ（転送管理装置）

Claims (6)

  1. 　転送元のデータが格納されるホストメモリを有するホスト部と、データの転送先であるデバイスメモリを有するデバイス部とを有する転送管理装置であって、
    　前記ホスト部は、前記ホストメモリから前記デバイスメモリへのDMA転送を行う転送制御部と、DMA転送の対象となるデータを指定した転送要求を示すリクエストを格納する複数の転送キューとを有しており、
    　前記転送制御部は、前記各転送キュー内のリクエストにより指定された前記ホストメモリのデータから１つ以上のサブセットを作成し、順番に選択した前記各転送キューのサブセットを、前記デバイスメモリにDMA転送することを特徴とする
    　転送管理装置。
  2. 　前記各転送キューには、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
    　前記転送制御部は、リクエストのデータから作成するサブセットのサイズとして、リクエストの優先度が高いほど、サブセットのサイズを大きくすることを特徴とする
    　請求項１に記載の転送管理装置。
  3. 　前記各転送キューには、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
    　前記転送制御部は、リクエストのデータから作成するサブセットのサイズとして、高優先度のリクエストが前記転送キューに入ってこない期間には、低優先度のサブセットのサイズを拡大し、一方、高優先度のリクエストが前記転送キューに入ってくる期間には、低優先度のサブセットのサイズを縮小するように制御することを特徴とする
    　請求項１に記載の転送管理装置。
  4. 　前記各転送キューには、個別の優先度が割り当てられ、その優先度のリクエストを格納することとし、
    　前記転送制御部は、リクエストのデータから作成するサブセットのサイズとして、前記転送キューに入ってくる高優先度のリクエストが増加する期間には、低優先度のサブセットのサイズを縮小し、一方、前記転送キューに入ってくる高優先度のリクエストが減少する期間には、低優先度のサブセットのサイズを拡大するように制御することを特徴とする
    　請求項１に記載の転送管理装置。
  5. 　転送元のデータが格納されるホストメモリを有するホスト部と、データの転送先であるデバイスメモリを有するデバイス部とを有する転送管理装置が実行する転送管理方法であって、
    　前記ホスト部は、前記ホストメモリから前記デバイスメモリへのDMA転送を行う転送制御部と、DMA転送の対象となるデータを指定した転送要求を示すリクエストを格納する複数の転送キューとを有しており、
    　前記転送制御部は、前記各転送キュー内のリクエストにより指定された前記ホストメモリのデータから１つ以上のサブセットを作成し、順番に選択した前記各転送キューのサブセットを、前記デバイスメモリにDMA転送することを特徴とする
    　転送管理方法。
  6. 　コンピュータを、請求項１ないし請求項４のいずれか１項に記載の転送管理装置として機能させるための転送管理プログラム。
     
PCT/JP2021/044832 2021-12-07 2021-12-07 転送管理装置、転送管理方法、および、転送管理プログラム WO2023105603A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/044832 WO2023105603A1 (ja) 2021-12-07 2021-12-07 転送管理装置、転送管理方法、および、転送管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/044832 WO2023105603A1 (ja) 2021-12-07 2021-12-07 転送管理装置、転送管理方法、および、転送管理プログラム

Publications (1)

Publication Number Publication Date
WO2023105603A1 true WO2023105603A1 (ja) 2023-06-15

Family

ID=86729777

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/044832 WO2023105603A1 (ja) 2021-12-07 2021-12-07 転送管理装置、転送管理方法、および、転送管理プログラム

Country Status (1)

Country Link
WO (1) WO2023105603A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03191453A (ja) * 1989-12-15 1991-08-21 Internatl Business Mach Corp <Ibm> データ処理システム
JP2010262526A (ja) * 2009-05-08 2010-11-18 Canon Inc メモリ制御装置
JP2011175621A (ja) * 2010-01-27 2011-09-08 Fujitsu Semiconductor Ltd データ転送制御装置およびデータ転送制御方法
US20150067087A1 (en) * 2013-08-29 2015-03-05 International Business Machines Corporation Automatic pinning and unpinning of virtual pages for remote direct memory access

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03191453A (ja) * 1989-12-15 1991-08-21 Internatl Business Mach Corp <Ibm> データ処理システム
JP2010262526A (ja) * 2009-05-08 2010-11-18 Canon Inc メモリ制御装置
JP2011175621A (ja) * 2010-01-27 2011-09-08 Fujitsu Semiconductor Ltd データ転送制御装置およびデータ転送制御方法
US20150067087A1 (en) * 2013-08-29 2015-03-05 International Business Machines Corporation Automatic pinning and unpinning of virtual pages for remote direct memory access

Similar Documents

Publication Publication Date Title
US7350004B2 (en) Resource management device
JP4723260B2 (ja) ソースデバイスに対するリクエストをスケジューリングする装置及び方法
US8838853B2 (en) Access buffer
US20140115254A1 (en) Access scheduler
JP6072783B2 (ja) メモリコントローラおよびかかるメモリコントローラの動作方法
EP2241979A1 (en) Interrupt arbitration for multiprocessors
JP4034969B2 (ja) 共通メモリのメモリ管理システム
KR20050020942A (ko) 연속 매체 우선순위 인식 저장장치 스케줄러
US11093352B2 (en) Fault management in NVMe systems
US6745262B1 (en) Method, system, program, and data structure for queuing requests having different priorities
JP2016195375A5 (ja)
JP6146128B2 (ja) データ処理装置
US20060047874A1 (en) Resource management apparatus
JP5565204B2 (ja) データ転送装置、データ転送方法およびプログラム、ならびに、画像形成装置
KR20080071840A (ko) 복수의 ｄｍａ 요청 블록들을 가지는 직접 메모리 액세스장치의 우선 순위를 결정하는 방법 및 장치
KR20020008955A (ko) 버스 시스템 및 그 실행 순서 조정방법
EP3440547B1 (en) Qos class based servicing of requests for a shared resource
WO2023105603A1 (ja) 転送管理装置、転送管理方法、および、転送管理プログラム
JP2011232917A (ja) 半導体集積回路、及びリクエスト制御方法
CN116664377A (zh) 数据传输方法及相关装置
JP2000194683A (ja) 共有メモリの調停回路およびその調停方法
US20050066097A1 (en) Resource management apparatus
JP6036806B2 (ja) バスアクセス調停回路およびバスアクセス調停方法
KR20090128851A (ko) 버스 중재 방법 및 장치
US9977751B1 (en) Method and apparatus for arbitrating access to shared resources

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023565710

Country of ref document: JP

Kind code of ref document: A