KR102442118B1 - Method and apparatus for offloading file i/o based on remote diret memory access using unikernel - Google Patents

Abstract

The method of operating a file input/output offload device based on remote direct memory access (RDMA) using a unikernel according to the present invention comprises the steps of calling a file input/output kernel function in the unikernel application program, the file input/output generating file input/output information from a kernel function, transmitting the file input/output information from the unikernel to Linux, constructing and calling a file input/output function using the file input/output information in Linux, and the file input/output The function may include transmitting a file input/output request corresponding to the file input/output information to the file server.

Description

Method and apparatus for remote direct memory access-based file I/O offload using unikernel

The present invention relates to a remote direct memory access (RDMA) based file input/output offload method and apparatus using a unikernel.

In general, a unikernel is an executable image that can be run without a separate operating system. These images contain the application code and all operating system functions required by the corresponding applications. Unikernel can significantly reduce boot time, capacity, and attack surface by combining application code with the minimum operating system elements required to run the corresponding application. Unikernels are smaller than traditional operating systems and can be started up and shut down much faster and more safely. Unikernel adopts offloading method to handle file I/O because it does not include large size modules such as file system in its library. However, this unikernel's IO (Input/Output) offload processing transmits file input/output commands to the proxy of the host server and copies the file input/output results performed by the proxy from the proxy. This may result in offsetting the treatment.

Korean Patent Laid-Open Patent: 10-2016-0142681, Publication date: December 13, 2016, Title: Offloading apparatus and method using a nearby small cell file cloud. US Patent Publication: US 2010-0161855, Publication Date: June 24, 2010, Title: LIGHWEIGHT INPUT/OUTPUT PROTOCOL. US Patent Publication: US 2019/0114193, Publication Date: April 18, 2019, Title: METHOD FOR PROCESSING INPUT AND OUTPUT ON MULTI KERNEL SYSTEM AND APPARATUS FOR THE SAME.

An object of the present invention is to provide a file input/output offload method and apparatus capable of performing high-speed file input/output in a unikernel.

An object of the present invention is to offload file I/O to Linux to support file I/O to a unikernel application program, so that the data on the NVMe device of the file server is high-speed input/output to the buffer of the unikernel application program through RDMA. and to provide an apparatus.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

According to an embodiment of the present invention, there is provided a method of operating a remote direct memory access (RDMA) based file input/output offload device using a unikernel, the method comprising: calling a file input/output kernel function in the unikernel application program; generating file input/output information in the file input/output kernel function; transmitting the file input/output information from the unikernel to Linux; constructing and calling a file input/output function using the file input/output information in the Linux; and transmitting, in the file input/output function, a file input/output request corresponding to the file input/output information to a file server.

In an embodiment, the generating of the file input/output information includes: extracting a continuous physical address section for the file input/output buffer; and generating an IO vector corresponding to the extracted physical address section.

In an embodiment, the method may further include driving the Linux file input/output proxy.

In an embodiment, the method may further include receiving the file input/output information from the unikernel at the file input/output proxy.

In an embodiment, the file input/output information includes a file input/output command, a file descriptor, an IO vector, and a vector count.

In an embodiment, the step of transmitting the file input/output request to the file server may include transmitting the input/output request corresponding to the number of the IO vectors in the file system stub of the Linux to the file server.

In an embodiment, the method may further include receiving a result of the file input/output request from the file server in the Linux.

In an embodiment, when the result of the file input/output request is successful, the method may further include transmitting a result of the input/output request from the Linux to the unikernel.

In an embodiment, in response to the file input/output request, the method may include inputting and outputting data of the file server to the memory of the unikernel in a Remote Direct Memory Access (RDMA) method.

A method of operating a remote direct memory access (RDMA) based file input/output offload device using a unikernel according to an embodiment of the present invention comprises: receiving a file input/output request from Linux of a unikernel system in a file server; ; extracting file information corresponding to the file input/output request from a file system in a file server; inputting and outputting data from a non-volatile memory using the file information; and transmitting the input/output data to the unikernel system through an RDMA engine.

In an embodiment, the method may further include transmitting a file input/output result in response to the file input/output request from the file server to the Linux of the unikernel system.

In an embodiment, the extracting of the file information from the file system may include extracting the file information for executing a file command from a file corresponding to a file descriptor included in the file input/output request. have.

In an embodiment, the method may further include instructing the file server to copy the input/output data of the non-volatile memory to an RDMA network interface card (NIC).

In an embodiment, the RDMA engine transmits the input/output data to a unikernel physical memory of the unikernel system in an RDMA manner.

A remote direct memory access (RDMA) based file input/output offload device according to an embodiment of the present invention includes: at least one processor; and a memory for storing a unikernel and Linux that are executed in the at least one processor, wherein the unikernel calls a file input/output kernel function from an application program, and generates file input/output information from the file input/output kernel function; the unikernel transmits the file input/output information to Linux, and the Linux constructs and calls a file input/output function using the file input/output information; and transmitting a file input/output request corresponding to the file input/output information in the file input/output function to the file server.

In an embodiment, the Linux operates a file input/output proxy to receive the file input/output information from the unikernel.

In an embodiment, the Linux uses the file input/output information to transmit an input/output command to the file server as much as an IO vector size to a physical address of an IO vector for a file corresponding to a file descriptor.

In an embodiment, the Linux receives the result corresponding to the input/output command from the file server.

In an embodiment, the method further comprises an RDMA NIC for inputting and outputting data corresponding to the input/output command from the file server in an RDMA manner.

In an embodiment, the Linux is used as a device driver for the storage device of the file server.

A file input/output offload method and apparatus according to an embodiment of the present invention offload input/output generated in the unikernel to Linux in order to perform input/output in the unikernel at high speed, and the offloaded file input/output is performed between Linux and a file server Through the RDMA method, the data of the file stored in the NVMe can be input/output to the unikernel memory.

In an embodiment of the present invention, the file input/output offload method and apparatus are implemented by offloading the unikernel IO to Linux to access the NVMe device data storage on the network through RDMA.

The file input/output offload method and apparatus according to an embodiment of the present invention allow a user to remotely access a device on a network and perform all disk operations as if connected to a local machine.

A file input/output offload method and apparatus according to an embodiment of the present invention enable an application program to offload file input/output to Linux and a file server in a unikernel and perform high-speed file input/output based on RDMA.

The file input/output offload method and apparatus according to an embodiment of the present invention, in building a file input/output environment in a unikernel, uses a software stack (File system, Network File System) of a general-purpose operating system that is difficult to build in a unikernel environment. In terms of unikernel, file I/O can be offloaded to Linux, and file I/O can be performed at high speed through RDMA (Remote Direct Memory Access).

The file input/output offload method and apparatus according to an embodiment of the present invention may not configure a heavy software stack such as a file system in the unikernel by offloading I/O to a general-purpose operating system in order to perform high-speed file input/output in the unikernel. have.

The file input/output offload method and apparatus according to an embodiment of the present invention provide a light-weight size and low-profile configuration for a plurality of unikernels without the need to build a file system in each unikernel even when a plurality of unikernel applications are run in one system. Kernel libraries can be configured to support optimal performance.

The accompanying drawings below are provided to help understanding of the present embodiment, and provide embodiments together with detailed description. However, the technical features of the present embodiment are not limited to specific drawings, and features disclosed in each drawing may be combined with each other to constitute a new embodiment.
1 is a diagram exemplarily showing a file input/output offload device 10 according to an embodiment of the present invention.
FIG. 2 is a ladder diagram exemplarily illustrating a process of file I/O offloading from the unikernel of the input/output offload device 10 to Linux and the file server 200 according to an embodiment of the present invention.
3 is a diagram exemplarily showing a process of transmitting file input/output offload information from the unikernel 110 to the Linux 120 of the unikernel system 100 according to an embodiment of the present invention.
4 is a diagram exemplarily illustrating a file input/output offload process for a read operation by a unikernel application program according to an embodiment of the present invention.
5 is a flowchart exemplarily illustrating a process of offloading file input/output to Linux and file input/output through a file server in a unikernel application program according to an embodiment of the present invention.
6 is a diagram showing in more detail the file input/output offload device 10 for performing file input/output offload to the unikernel and the Linux/file server according to an embodiment of the present invention.
7 is a diagram exemplarily showing an electronic device 1000 according to an embodiment of the present invention.

Hereinafter, the content of the present invention will be described clearly and in detail to the extent that a person skilled in the art can easily implement it using the drawings.

Since the present invention can have various changes and can have various forms, specific embodiments are illustrated in the drawings and described in detail in the text. However, this is not intended to limit the present invention to the specific disclosed form, it should be understood to include all modifications, equivalents and substitutes included in the spirit and scope of the present invention. Terms such as first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms may be used for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. When an element is referred to as being “connected” or “connected” to another element, it is understood that it may be directly connected or connected to the other element, but other elements may exist in between. it should be On the other hand, when it is said that a certain element is "directly connected" or "directly connected" to another element, it should be understood that the other element does not exist in the middle.

The terms used in the present application are only used to describe specific embodiments, and are not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present application, terms such as "comprise" or "have" are intended to designate the existence of an embodied feature, number, step, operation, component, part, or combination thereof, but one or more other features or numbers , it should be understood that it does not preclude the possibility of the existence or addition of steps, operations, components, parts, or combinations thereof. Unless defined otherwise, all terms used herein, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having meanings consistent with the context of the related art, and unless explicitly defined in the present application, they are not to be interpreted in an ideal or excessively formal meaning. .

In general, the mapping relationship between the virtual address and the physical address allocated to the buffer of the application program that exists in the unikernel is a unique method of the operating system, and in Linux, the virtual Physical memory cannot be accessed by address. In addition, even if Linux knows the physical address corresponding to the virtual address of the starting point of the buffer in the unikernel, an arbitrary physical address in the buffer cannot be obtained unless the mapping from the virtual address of the buffer to the physical address is consecutive. . That is, since a buffer is generally composed of discrete physical pages, it is not guaranteed to obtain a physical address that maps to a corresponding contiguous virtual address at any point in the buffer. Therefore, the existing unikernel receives input/output results copied from the host OS (Operating System) or file server to perform file I/O.

In order to perform file I/O, a memory address to input/output data is required.

According to the present invention, a set having the address and size of a continuous physical page among physical pages mapped to the virtual address of the input/output buffer in the unikernel as one element and the number of elements in the set can be transmitted to Linux. That is, the file input/output command transmitted from the unikernel to Linux may transmit an IO (Input/Output) vector including a physical address and size of data of the unikernel. This is because Unikernel and Linux have their own virtual address for one physical address, and it is impossible to extract a physical address for memory with the other virtual address.

In addition, the reason for inputting and outputting data using RDMA (Remote Direct Memory Access) or DMA (Direct Memory Access) is that the physical address of the real memory is required, not the virtual address of the operating system. Using these physical addresses, Linux can high-speed input/output of data on the NVMe (Non-Volatile Memory Express) device to the corresponding physical address in the file server through RDMA to the I/O buffer of the unikernel.

In addition, a high-speed file input/output function is required to improve the performance of an application program requiring file input/output in the unikernel operating environment. According to the present invention, Linux is installed on some resources (core, memory) of the system, file input/output is offloaded to the installed Linux, and data in the NVMe device on the file server can be input/output at high speed through RDMA.

For example, in the present invention, in order to perform file input/output in the unikernel, Linux can be installed on some resources of the system and used as a device driver. Unikernel can send file I/O commands to I/O offload to installed Linux. After that, Linux can request file I/O from the file server for the memory pointed to by the physical address of the unikernel existing in the received file I/O command. The file server extracts information for accessing files stored in NVMe (Non-volatile Memory Express) devices from the file system, accesses NVMe data and performs input/output, and unikernel physical addresses at high speed through RDMA. Data can be transferred to the memory pointed to by .

In addition, according to the present invention, it is not necessary to construct an additional file system software stack for high-speed file input/output in the unikernel, and it is possible to minimize interference in the kernel during file input/output processing.

1 is a diagram exemplarily showing a file input/output offload device 10 according to an embodiment of the present invention. Referring to FIG. 1 , the file input/output offload device 10 may include a unikernel system 100 and a file server 200 .

The unikernel system 100 may include a unikernel 110 , a Linux 120 , and a shared memory 130 .

The unikernel 110 is an image with a single address space implemented as a library operating system. That is, the application program includes the necessary operating system functions in the form of a library, and the image itself becomes a special kernel unique to the corresponding application program. The unikernel 110 has a software stack in which user space and kernel space are a single address space. The unikernel 110 can maximize application program performance by eliminating mode switching between the kernel and the user by using a single space address and minimizing data copying. For example, the unikernel 110 may be MirageOS, Rump for POSIX compatible software (Software), IncludeOS for C++, Hermitcore for High Performance Computing (HPC), or the like.

Linux 120 ('first Linux') is a monolithic kernel, and may perform input/output operations with the file server 200 .

The shared memory 130 may include a uni-kernel memory 132 and an RDMA Remote Direct Memory Access Network Interface Card (NIC) 134 .

The file server 200 may include a Linux 220 ('second Linux') and a memory 230 . Here, the memory 230 may include a non-volatile memory (NVMe) 232 and an RDMA NIC 234 . Meanwhile, it should be understood that the non-volatile memory may be implemented as various types of non-volatile memory in addition to Non-Volatile Memory Express (NVMe).

The file input/output offload apparatus 10 according to an embodiment of the present invention may perform file input/output in the unikernel 110 at high speed.

The file input/output offload device 10 may offload the input/output generated in the unikernel 110 to the first Linux 120 in order to perform input/output in the unikernel 110 at high speed. Here, the offloaded file input/output is to input/output data of a file stored in the NVMe 232 through the first Linux 120 and the file server 200 to the memory 132 of the unikernel 110 in an RDMA manner. can In an embodiment, the unikernel input/output (IO) may offload the IO of the unikernel 110 to the Linux 120 to access the NVMe 232 on the network through the RDMA NICs 134 and 234 . . In an embodiment, the unikernel 110 may allow a user to remotely access the NVMe 232 over a network and perform all disk operations (read, write, etc.) as if connected to a local machine.

In summary, the file input/output offload device 10 according to an embodiment of the present invention transfers the input/output generated in the uni-kernel 110 to the uni-kernel system 100 in order to perform the input/output in the uni-kernel 110 at high speed. Offloaded to Linux 120, the offloaded file input/output is input/output to the unikernel memory 132 in the RDMA method with the data of the file stored in the NVMe 232 through the Linux 120 and the file server 200 can do.

In the file input/output offload device 10 according to an embodiment of the present invention, an application program offloads file input/output to the Linux 120 and the file server 200 in the unikernel 110 and performs high-speed file input/output based on RDMA. can be done

The file input/output offload device 10 according to an embodiment of the present invention uses a software stack (File system, Network File System) of a general-purpose operating system that is difficult to build in a unikernel environment to offload file input/output to Linux from the unikernel side. It can load and input/output files at high speed through RDMA.

The file input/output offload device 10 according to an embodiment of the present invention loads a heavy software stack such as a file system by offloading input/output to a general-purpose operating system in order to perform high-speed file input/output in the unikernel 110. 110) may not be configured.

The file input/output offload device 10 according to an embodiment of the present invention is a lightweight size for a plurality of unikernels without the need to build a file system in each unikernel even when a plurality of unikernel applications are driven in one system. and the kernel library can be configured to support optimal performance.

2 is a ladder diagram exemplarily illustrating a process of file I/O offloading from the unikernel of the input/output offload device 10 to the Linux and file server 200 according to an embodiment of the present invention. Referring to FIG. 2 , the file input/output offload process may be performed as follows.

The unikernel 110 may operate as follows. The unikernel 110 may start an application program of the unikernel (S111). The unikernel application program may call the file input/output function (S112). The unikernel 110 may extract a continuous physical address section for the file input/output buffer and generate file input/output information (eg, file input/output command and IO vector) (S113). When the unikernel application program is started and the file input/output function is called during execution, the unikernel 110 provides file input/output commands, file descriptors, and IO vectors of the unikernel 110 in order to offload the file input/output to the Linux 120 . , file input/output information such as vector count can be generated. File I/O commands are I/O commands such as read and write. A file descriptor is a value representing a file allocated from the system. The IO vector is a set having, as one element, the address and size of a continuous physical page among physical pages mapped to the virtual address of an input/output buffer. The vector count is the number of elements constituting the IO vector.

The unikernel 110 may transmit file input/output information (file input/output command and IO vector) to the Linux 120 (S114). The reason for transmitting the IO vector including the physical address and size of the buffer of the unikernel to the file input/output information transmitted from the unikernel 111 to the Linux 120 is that the unikernel 110 and the Linux 120 are one Each has its own virtual address for the physical address of , because it is impossible to extract the physical address of the memory with the other virtual address. In addition, the reason for inputting/outputting data using RDMA or DMA is that the physical address of the real memory is required, not the virtual address of the operating system. The file input/output information of the unikernel generated as above may be transmitted to the input/output offload proxy of the Linux 120 . Thereafter, the unikernel 110 may receive the file input/output function result as many as the number of IO vectors from the Linux 120 ( S115 ).

The operation of the Linux 120 may proceed as follows. Linux 120 may drive the file input/output Opredo proxy (S121). Linux 120 may receive file input/output information (file input/output command and IO vector) from the unikernel 110 (S122). Linux 120 may configure and call a file input/output function using file input/output information (file input/output command and IO vector) ( S123 ). The file input/output offload proxy of Linux 120 may configure a file input/output function to be transmitted to the file system stub by using the received file input/output information. When a corresponding file input/output function is performed in Linux 120 , a file input/output command may be transmitted to the file server 200 through a file system stub of Linux. Linux 120 may request an input/output command from the file server 200 to the physical address of the IO vector as much as the size of the IO vector for the file corresponding to the file descriptor (S124). In this case, the file system stub may request file I/O from the file server for one IO vector element as many as the number of IO vectors. That is, it is possible to process input/output by using consecutive physical addresses as one unit. At this time, the transmitted file I/O information is a file I/O command, a file descriptor, a physical address of an IO vector, and an I/O size of an IO vector.

Thereafter, the Linux 120 may receive the file input/output function result as many as the number of IO vectors from the NVMe 232/RDMA NIC 234 from the file server 200 ( 125 ). Thereafter, the Linux 120 may transmit the result of the file input/output function as many as the number of IO vectors to the unikernel memory 134 of the unikernel 110 .

The operation of the file server 200 may proceed as follows. The file server 200 may drive a file server daemon in Linux 220 (S131). The Linux 220 of the file server 200 may receive a file input/output request from the Linux 120 of the unikernel system 100 ( S132 ). The Linux 220 of the file server 200 may extract file information from the file system in order to perform an input/output command on the NVMe file corresponding to the file descriptor (S133). When the file server 200 receives a file input/output request from the Linux 120 of the unikernel system 100, information for input/output from the file system to the NVMe to perform an input/output command on a file corresponding to the file descriptor can be extracted. The file server 200 may input/output data corresponding to the input/output size in NVMe, transmit it in RDMA, and transmit the data as much as the size to a physical address to be input/output through the RDMA engine. The Linux 220 of the file server 200 may perform input/output commands to NVMe and RDMA (S134). The Linux 220 of the file server 200 may transmit data with a size corresponding to the physical address and transmit the file input/output result to the Linux 120 of the unikernel system 100 (S135).

3 is a diagram exemplarily showing a process of transmitting file input/output offload information from the unikernel 110 to the Linux 120 of the unikernel system 100 according to an embodiment of the present invention. Referring to FIG. 3 , the process of transmitting file input/output offload information from the unikernel 110 to the Linux 120 inside the unikernel system 100 may proceed as follows.

The unikernel 110 is file input/output offload information for offloading file input/output (IO) to the Linux 120 . can be sent to the I/O offload proxy of Here, the input/output command is an input/output command such as read (read) and write (write). A file descriptor is a value representing a file allocated from the system. The IO vector is a set having, as one element, the address and size of a continuous physical page among physical pages mapped to a virtual address (VA) of an input/output buffer. The vector count is the number of elements constituting the IO vector.

3, the file input/output command is read, and the file descriptor is fd. When the virtual address of the I/O buffer is va and the size is sz, the IO vector is {{pa1, sz1, a set of continuous physical addresses matching the sz (= sz1 + sz2) size interval from the virtual address (va) and its size. }, {pa2, sz2}}. The vector count is iov_cnt = 2, which is the number of elements in the IO vector. That is, when the buffer of the unikernel memory 130 consists of three pages, there are two elements of a set consisting of consecutive physical pages among three matching physical pages.

4 is a diagram exemplarily illustrating a file input/output offload process for a read operation by an application program of the unikernel 110 according to an embodiment of the present invention. 5 is a flowchart exemplarily showing a process of offloading file input/output to Linux 120 and file input/output through a file server in an application program of the unikernel 110 according to an embodiment of the present invention. 4 and 5 , the application program of the unikernel 110 may perform a file input/output offload operation for a read operation as follows.

The application program of the unikernel 110 may perform an input/output function (eg, read(fd, va, count) (S210). The unikernel 110 is located in the count size section from the virtual address va of the input/output buffer. An IO vector (= iov[]), which is a set of matching continuous physical addresses (pa) and their sizes, can be calculated (S220). The IO vector count is iov_cnt, which is the number of elements of the IO vector. A file input/output information message having parameters (eg, read, fd, iov[], iov_cnt) related to file input/output information may be transmitted to the Linux 120 (S230).

The waiting input/output offload proxy in Linux 120 may receive the file input/output information message, configure and perform the file input/output function (read(fd, iov[], iov_cnt) (S240).

The ith (0 <= i < iov_cnt) file input/output function (eg, write_io(fd, iov[i]. pa, iov[i].iov_cnt) that the file system stub of Linux 120 requests from the file server 200 ) can be configured (S250). The file system stub of Linux 120 may transmit an i-th file input/output message (eg, read, fd, iov[i].pa, iov[i].iov_cnt) to the file server 200 (S260). ).

The Linux 220 of the file server 200 may extract information for executing a file command from a file corresponding to the received file descriptor from the file system. For example, information for inputting/outputting a file stored in the NVMe 232 may be extracted with respect to a file having the file descriptor fd. The file server 200 may command to copy the file data to be input/output in the NVMe 232 to the RDMA NIC 234. The file input/output data may be copied from the NVMe 232 to the RDMA NIC 234 (S270) The RDMA engine may transmit the file input/output data to the physical memory (eg, iov[i].pa) of the unikernel 110 in an RDMA manner.

6 is a diagram showing in more detail the file input/output offload device 10 for performing file input/output offload to the unikernel and the Linux/file server according to an embodiment of the present invention. Referring to FIG. 6 , the file input/output offload device 10 may include a unikernel system 100 and a file server 200 .

The unikernel system 100 may include a first kernel system 101 and a second kernel system 102 .

The first kernel system 101 may include a unikernel 110 and a unikernel memory 130 . The unikernel 110 may include an application program 111 , an IO vector generator 112 , a file input/output information generator 113 , a file input/output offload request transmitter 114 , and a file input/output offload receiver 115 . can

The application program of the unikernel 110 includes all operating system functions necessary for the application program code and the corresponding application program, and thus can be executed without a separate operating system. The IO vector generation unit 112 generates an IO vector, which is a set in which the address and size of a continuous physical page among physical pages mapped to a virtual address (va) of an input/output buffer (Buffer) as one element. can

The file input/output information generation unit 113 may generate file input/output offload information necessary for offloading file input/output to Linux 1. Here, the file input/output information includes unikernel input/output commands, file descriptors, IO vectors, and vectors. count, etc.

The file input/output offload request transmitter 114 may transmit file input/output information to the Linux 120 .

File input/output offload result receiving unit 115 is the file input/output of Linux 120 ? A file input/output offload result may be received from the result transmitter 125 .

The second kernel system 102 may include a Linux 120 and an RDMA NIC 140 . Linux 120 includes a file input/output offload request receiver 121, an input/output offload function configuration and call unit 122, an IO vector request transmitter 123, an IO vector result receiver 124, and a file input/output offload result transmitter (125).

The file input/output offload request receiving unit 121 may receive file input/output information from the unikernel 110 .

The file input/output function configuration and call unit 122 may configure a file input/output function using the received file input/output information and execute file input/output.

The IO vector request transmitter 123 may transmit an IO request for one element of the IO vector to the file server 200 . Here, the IO vector request may be transmitted as many as the number of elements of the IO vector.

The IO vector result receiving unit 124 may receive a result corresponding to the IO vector request from the file server 200 . That is, the IO vector result receiving unit 124 may receive a file input/output result for one element of the IO vector from the file server through NVMe/RDMA. In an embodiment, if the IO vector request is successful, control may be branched to the IO vector request transmitter 123 to perform IO on the next element of the IO vector. On the other hand, if the IO vector request fails, control may be branched to the file input/output offload result transmission unit 125 .

The file input/output offload result transmitter 125 may transmit a file input/output offload result corresponding to the received IO vector result to the file input/output offload result receiver 115 of the unikernel 110 .

File server 200 may include Linux 220 , NVMe 230 , and RDMA NIC 240 . Linux 220 may include an IO vector request receiving unit 221 , file information extracting unit 222 , NVMe/RDMA IO processing performing unit 223 , and IO vector result transmitting unit 224 .

The IO vector request receiving unit 221 may receive an IO request for one element of the IO vector from the Linux 120 of the unikernel system 100 .

The file information extraction unit 222 may extract information for executing a file command from a file corresponding to the received file descriptor from the file system.

The NVMe/RDMA IO processing performing unit 223 copies the file data to be input/output in the NVMe 232 to the RDMA NIC 234, and copies the copied file data from the RDMA NIC 234 to the Linux ( 120) may be transmitted to the physical memory of the unikernel 110 through the RDMA NIC 134.

The IO vector result transmitter 224 may transmit the result of file input/output for one element of the IO vector to the Linux 120 of the unikernel system 100 through NVMe/RDMA.

The file input/output offload device 10 according to an embodiment of the present invention offloads file input/output to the Linux 120 and the file server 200 by an application program driven by the unikernel 110, and performs RDMA-based high-speed File I/O can be performed.

File input/output offload device 10 according to an embodiment of the present invention, when building a file input/output environment in the unikernel 110, by using a software stack (File system, Network file system) of a general-purpose operating system, uni-kernel side can offload file I/O to Linux, and high-speed file I/O through RDMA.

The file input/output offload device 10 according to an embodiment of the present invention offloads I/O to a general-purpose operating system in order to perform high-speed file input/output in the unikernel 110, thereby converting a heavy software stack such as a file system to the unikernel. (110) may not be configured.

The file input/output offload device 10 according to an embodiment of the present invention is a lightweight size for a plurality of unikernels without the need to build a file system in each unikernel even when a plurality of unikernel applications are driven in one system. and the kernel library can be configured to support optimal performance.

7 is a diagram exemplarily showing an electronic device 1000 according to an embodiment of the present invention. Referring to FIG. 7 , the electronic device 1000 may include at least one processor 1100 , a network interface 1200 , a memory 1300 , a display 1400 , and an input/output device 1500 . The electronic device 1000 illustrated in FIG. 7 may include the above-described unikernel system 100 .

The processor 1100 may include at least one device with reference to FIGS. 1 to 6 , or may be implemented with at least one method described above with reference to FIGS. 1 to 6 . The processor 1100, as described above, starts an application program of the unikernel; calling file input/output functions from a unikernel application; generate file input/output information in the unikernel; transfer file input/output information from unikernel to linux; Run a file I/O proxy in Linux, and receive file I/O information from a unikernel in Linux; Configure and call file input/output functions using file input/output information in Linux; In Linux, for the file corresponding to the file descriptor, request an input/output command from the file server with the physical address of the IO vector as much as the size of the IO vector; In Linux, the number of IO vectors in the file input/output information is executed, and the result is transmitted to the unikernel; In Unikernel, you can execute instructions to receive file input/output results from Linux.

The processor 1100 may execute a program and control the electronic device 1000 . The electronic device 1000 may be connected to an external device (eg, a personal computer or a network) through the input/output device 1500 and exchange data.

The network interface 1200 may be implemented to communicate with an external network through various wired/wireless methods.

The memory 1300 may include computer-readable instructions. The processor 1100 may perform the aforementioned operations as an instruction stored in the memory 1300 is executed in the processor 1100 . The memory 1300 may be a volatile memory or a non-volatile memory. The memory 1300 may include a storage device to store user data. The storage device may be an embedded multimedia card (eMMC), a solid state drive (SSD), a universal flash storage (UFS), or the like. The storage device may include at least one non-volatile memory device. Non-volatile memory devices include NAND flash memory (NAND flash memory), vertical NAND flash memory (VNAND), NOR flash memory (NOR flash memory), resistive random access memory (RRAM), phase change memory (Phase-Change Memory: PRAM), Magnetoresistive Random Access Memory (MRAM), Ferroelectric Random Access Memory (FRAM), Spin Transfer Torque Random Access Memory (STT-RAM), etc. this can be

The embodiments described above may be implemented by a hardware component, a software component, and/or a combination of a hardware component and a software component. For example, the apparatus, methods, and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate (FPGA). Array), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general-purpose or special-purpose computers. The processing device may execute an Operating System (OS) and one or more software applications running on the operating system.

The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing. It can be seen that elements can be included. For example, the processing device may include a plurality of processors or one processor and one controller. Other Processing Configurations are also possible, such as a Parallel Processor.

The software may include a computer program, code, instructions, or a combination of one or more thereof, and configure a processing device to operate as desired or process it independently or in combination (Collectively) You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or provide instructions or data to the processing device. , or may be permanently or temporarily embodied in a transmitted signal wave (Embody). The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magnetic media such as floppy disks. - Includes hardware devices specially configured to store and execute program instructions, such as Magneto Optical media, ROM, RAM, Flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

In offloading file I/O commands of unikernel to Linux and file servers,

When the unikernel application program is started and the file input/output function is called during execution, the unikernel transmits file input/output information such as file input/output commands, file descriptors, IO vectors, and vector counts of the unikernel to offload file I/O to Linux. create The reason for creating an IO vector including the physical address and size of the unikernel buffer in the file input/output information is that unikernel and Linux each have their own virtual address even though they have one and the same physical address. This is because it is not possible to extract the physical address for the memory with In addition, in order to perform file I/O from the file server to the unikernel, when data is input/output through RDMA or DMA, the physical address of the real memory is required, not the virtual address of the operating system.

Accordingly, the present invention constitutes an IO vector, which is a set in which the address and size of a continuous physical page among physical pages mapped to a virtual address of an input/output buffer, as one element, and the vector count, which is the number of elements constituting the IO vector. by sending file I/O information to Linux, Linux requests file I/O from the file server in units of elements of the IO vector, and RDMA-based high-speed input/output of file data as much as the size of the continuous area starting with the physical address. be able to

The present invention uses a software stack (File system, Network File System) of a general-purpose operating system that is difficult to build in a unikernel, and uses Linux as a device driver by using some resources in the system in terms of a unikernel.

The present invention enables high-speed file input/output through NVMe and RDMA in offloading file input/output from unikernel to Linux. The present invention is applicable to performing data-centric computing such as image processing, graph processing, and deep learning by using the kernel input/output technology for data-centric HPC (High Performance Computing). The present invention can be used as a kernel input/output technology of an in-memory DB that requires a lot of fast processing based on large-scale/frequent data and a NIC supporting 100G.

On the other hand, the present invention will not be limited to offloading file input/output from unikernel to Linux. According to the present invention, file I/O can be offloaded from the uni-kernel to any type of operating system (Unix kernel, Solaris kernel, Windows NT kernel, Bellona 2 kernel, AIX kernel, etc.) of a monolithic kernel. will have to be understood

On the other hand, the contents of the present invention described above are only specific examples for carrying out the invention. The present invention will include not only concrete and practically usable means, but also technical ideas that are abstract and conceptual ideas that can be used in future technologies.

10: File I/O offload system
100: unikernel system
110: uni-kernel
111: application
112: IO vector generator
113: file input/output information generation unit
114: file input/output offload request transmitter
115: file input/output offload result receiving unit
120, 220: Linux
121: file input/output offload request receiving unit
122: File input/output function configuration and call part
123: IO vector request transmitter
124: IO vector result receiving unit
125: file input/output offload result transmitter
200: file server
1000: electronic device

Claims (20)

A method of operating a remote direct memory access (RDMA)-based file input/output offload device using a unikernel, the method comprising:
calling a file input/output kernel function in the unikernel application program;
generating file input/output information in the file input/output kernel function;
transmitting the file input/output information from the unikernel to Linux;
constructing and calling a file input/output function using the file input/output information in the Linux; and
Transmitting a file input/output request corresponding to the file input/output information in the file input/output function to a file server,
The step of generating the file input/output information includes:
extracting a continuous physical address section for the file input/output buffer; and
generating an IO vector, which is a set having an address and a size corresponding to the extracted physical address section as one element,
The file input/output information includes a file input/output command, a file descriptor, the IO vector, and a vector count indicating the number of elements of the IO vector. delete The method of claim 1,
The method further comprising the step of driving the file input/output proxy of the Linux. 4. The method of claim 3,
The method further comprising the step of receiving the file input/output information from the unikernel at the file input/output proxy. delete The method of claim 1,
Transmitting the file input/output request to the file server comprises:
and transmitting the input/output request corresponding to the number of IO vectors from the file system stub of the Linux to the file server. The method of claim 1,
The method further comprising receiving a result of the file input/output request from the file server in the Linux. 8. The method of claim 7,
When the result of the file input/output request is successful, the method further comprising the step of transmitting the result of the input/output request from the Linux to the unikernel. The method of claim 1,
and inputting and outputting data from the file server to the memory of the unikernel in a Remote Direct Memory Access (RDMA) method in response to the file input/output request. A method of operating a remote direct memory access (RDMA)-based file input/output offload device using a unikernel, the method comprising:
Receiving a file input/output request from Linux of a unikernel system in a file server;
extracting file information corresponding to the file input/output request from a file system in a file server;
inputting and outputting data from a non-volatile memory using the file information; and
Transmitting the input/output data to the unikernel system through an RDMA engine,
the linux is
Transmitting a file input/output request corresponding to the file input/output information received from the unikernel of the unikernel system,
The file input/output information is
A file input/output command, a file descriptor, an IO vector that is a set in which a physical address and size corresponding to a continuous physical address section for the file input/output buffer of the unikernel are one element, and a vector indicating the number of elements of the IO vector A method comprising a count. 11. The method of claim 10,
The method further comprising the step of transmitting a file input/output result for the file input/output request from the file server to the Linux of the unikernel system. 11. The method of claim 10,
The step of extracting the file information from the file system,
and extracting the file information for executing a file command from a file corresponding to a file descriptor included in the file input/output request. 11. The method of claim 10,
The method further comprising the step of instructing the file server to copy the input/output data of the non-volatile memory to an RDMA NIC. 11. The method of claim 10,
The RDMA engine transmits the input/output data to the unikernel physical memory of the unikernel system in an RDMA manner. For a Remote Direct Memory Access (RDMA) based file I/O offload device:
at least one processor; and
A memory for storing a unikernel and Linux running on the at least one processor,
the unikernel calls a file input/output kernel function from an application program, and generates file input/output information from the file input/output kernel function; Transmitting the file input/output information from the unikernel to Linux,
the Linux constructs and calls a file input/output function using the file input/output information; and transmitting a file input/output request corresponding to the file input/output information in the file input/output function to the file server,
The unikernel is
Extracting a continuous physical address section for the file input/output buffer, and generating an IO vector, which is a set having an address and size corresponding to the extracted physical address section as one element,
The file input/output information includes a file input/output command, a file descriptor, the IO vector, and a vector count indicating the number of elements of the IO vector. 16. The method of claim 15,
The Linux file input/output offload device, characterized in that by driving a file input/output proxy to receive the file input/output information from the unikernel. 16. The method of claim 15,
The Linux file input/output offload device, characterized in that for the file corresponding to the file descriptor by using the file input/output information, the file input/output offload device, characterized in that it transmits the input/output command to the file server as much as the size of the IO vector to the physical address of the IO vector. 18. The method of claim 17,
The Linux file input/output offload device, characterized in that the result corresponding to the input/output command is received from the file server. 18. The method of claim 17,
The file input/output offload device further comprising an RDMA NIC (Network Interface Card) for inputting and outputting data corresponding to the input/output command from the file server in an RDMA manner. 16. The method of claim 15,
The file input/output offload device, characterized in that the Linux is used as a device driver for the storage device of the file server.

Images