JP2012226471A - Communication method and communication server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce a load of a server when performing communication in a virtualized environment.SOLUTION: A communication method includes a server 1 in which a plurality of virtual OSs 2 are executed and a driver OS 3 for managing communication processing is executed, and which comprises a communication device 5 for performing communication. In a shared memory 4, a communication buffer 42 for storing communication data and a communication ring queue 41 for storing a memory address of the communication buffer 42 are set. The driver OS 3 manages the memory address in the communication ring queue 41. The virtual OSs 2 and the communication device 5 refer to the memory address stored in the communication ring queue 41 and perform reading/writing of the communication data to the communication buffer 42.

Description

  The present invention relates to a communication method and a communication server technology in a virtual environment.

There is a virtualization technology that makes it possible to simultaneously operate a plurality of virtual computers on one computer by using virtualization software that makes the physical resources of the computer appear as a plurality of logical resources.
Hereinafter, a physical computer that operates a plurality of virtual computers is simply referred to as a “server”, and a virtual computer that operates on the physical computer (server) is referred to as a “guest OS (Operating System)”.
With such a virtualization technology, physical resources (hardware) such as processors and memories on one server can be shared and used by multiple guest OSes, and multiple servers are prepared for each OS. Compared to the above, the cost for operation and management of the server can be saved.

In a virtual environment, a method using a driver OS as an interface between a guest OS and a hardware is used. The driver OS is a driver OS dedicated to device driver management, which is one of guest OSes operating on the server. Each guest OS accesses the hardware through this driver OS.
By using this method, when a problem occurs in the driver running on the guest OS, the entire server including other guest OSs that do not use the driver is affected, and multiple device drivers are added to the virtualization software. Incorporating it solves the problem that the size of the software for virtualization grows accordingly.

However, the method of installing the driver OS has a problem that the system performance of the entire server is limited by the load of the driver OS.
For example, since access from a plurality of guest OSs concentrates on the driver OS and the driver OS inputs / outputs data to / from the plurality of guest OSs from the hardware, the data is distributed and the memory is copied. Increases the processor load and memory access load.
In particular, when a plurality of guest OSs communicate using a single network card, the communication speed is limited by the processor load and memory access load of the driver OS.

  As a countermeasure against such a problem, in Patent Document 1, when a server receives communication data, an ID (Identification) of a guest OS is set in advance in the driver OS, and a distribution destination is determined based on the ID. An information processing apparatus having a load distribution function for reducing the processor load and memory load of a server by transferring and simplifying settings and transfer routes is disclosed.

JP 2010-66931 A

  Although the technology described in Patent Document 1 reduces the processor load used for table search for data distribution, the hardware and driver OS each time the driver OS receives input / output from / to the multiple guest OSs. The memory copy performed between the guest OSs must be executed. Further, in the case of communication using a communication protocol having a packet structure having a header and a payload such as TCP / IP (Transmission Control Protocol / Internet Protocol), each guest OS is a driver executed on the guest OS. Separately, a transmission / reception packet transmission / reception process is performed by executing a communication application. The existence of processor load and memory access load when this communication application generates and analyzes transmitted / received packets is also a problem.

  There is a method of offloading the communication processing from the guest OS and processing it with dedicated hardware. However, the problems of the processor load and the memory access load in the processing between the guest OS and the hardware are not solved.

  The present invention has been made in view of such a background, and an object of the present invention is to reduce the load on the server when performing communication in a virtual environment.

  In order to solve the above-described problem, the present invention provides a processing device for executing a plurality of virtual OSs and further executing a driver OS for managing communication processing, a communication device as a device for performing communication, A communication method in a communication server having a storage device, wherein the storage device stores a first storage area for storing communication data, which is data to be communicated, and a memory of the first storage area A second storage area for storing an address is set, the driver OS manages the memory address in the second storage area, and the virtual OS and the communication device The communication data is read / written from / to the first storage area with reference to the memory address stored in the second storage area.

  According to the present invention, it is possible to reduce a load on a server when performing communication in a virtual environment.

It is a figure which shows the structural example of the virtual system which concerns on 1st Embodiment. It is a figure which shows an example of the hardware constitutions of a server. It is a figure which shows the path | route which passes when communication data is transmitted / received. It is a figure which shows an example which converts a communication function into a communication I / F packet. It is a figure which shows the example of the switch variable management table which concerns on 1st Embodiment. It is a flowchart which shows the procedure of the communication I / F packet generation process which concerns on 1st Embodiment. It is explanatory drawing of the communication ring queue which concerns on 1st Embodiment. It is a figure which shows the structural example of the communication ring queue which concerns on 1st Embodiment. It is a figure which shows the structure of a communication I / F driver, and the relationship with another function part. It is a flowchart which shows the procedure of the communication I / F packet process which concerns on 1st Embodiment. It is a sequence diagram which shows an example of the process sequence of the active open which concerns on 1st Embodiment (the 1). It is a sequence diagram which shows an example of the process sequence of the active open which concerns on 1st Embodiment (the 2). It is a sequence diagram which shows an example of the process sequence of the passive open which concerns on 1st Embodiment (the 1). It is a sequence diagram which shows an example of the process sequence of the passive open which concerns on 1st Embodiment (the 2). It is a sequence diagram which shows an example of the process sequence of the passive open which concerns on 1st Embodiment (the 3). It is a sequence diagram which shows an example of the process sequence of the data transmission process which concerns on 1st Embodiment. It is a sequence diagram which shows an example of the process sequence of the data reception process which concerns on 1st Embodiment. It is a sequence diagram which shows an example of the process sequence of the active close which concerns on 1st Embodiment. It is a sequence diagram which shows an example of the process sequence of the passive close which concerns on 1st Embodiment. It is a figure which shows the structural example of the virtual system which concerns on 2nd Embodiment. It is a flowchart which shows the procedure of the communication I / F packet generation process which concerns on 2nd Embodiment.

  Next, modes for carrying out the present invention (referred to as “embodiments”) will be described in detail with reference to the drawings as appropriate.

<< First Embodiment >>
First, a first embodiment of the present invention will be described with reference to FIGS.

[System configuration]
FIG. 1 is a diagram illustrating a configuration example of a virtual system according to the first embodiment.
In the virtual system Z, a server (communication server) 1 that is a physical computer and a communication destination server 9 are connected to each other via a network 8.
A communication offload is performed in the server 1 through a hardware I / F (Interface) 6 such as PCI (Peripheral Component Interface) Express (registered trademark) instead of a CPU (Central Processing Unit). An engine (communication device) 5 is connected. The communication offload engine 5 is connected to the network 8 via a hardware I / F 7 such as a PHY (Physical Layer) serving as an NI (Network Interface).

In the server 1, a hypervisor (processing device) 10 is executed, and the hypervisor 10 executes and manages a plurality of guest OS 2 and driver OS 3.
The hypervisor 10 is one of virtualization technologies, and is virtualization software that realizes a virtualization environment. The hypervisor 10 operates on the main memory, and all the OSs including the driver OS 3 and the guest OS 2 operate on the hypervisor 10. In some cases, a host OS (not shown) is first run on the main memory, and then the hypervisor 10 is run as an application of the host OS, and the hypervisor 10 executes the driver OS 3 and the guest OS 2.

The guest OS 2 is a virtual OS (virtual computer: virtual OS) that runs on the server 1. The guest OS 2 operates in the same manner as an OS that operates in a non-virtualized computer environment. In the server 1 under the virtual environment, a plurality of guest OSs 2 can operate, and various types of OSs can be executed as the guest OSs 2.
In the present embodiment, the guest OS 2 executes the communication application 21 and the communication I / F library processing unit 23. However, other applications can be executed.
The communication application 21 executes a function for performing communication (hereinafter referred to as a communication function), and performs communication processing on the guest OS 2.

The communication I / F library processing unit 23 is an interface between the communication application 21 and the communication I / F driver 31.
The communication I / F library processing unit 23 converts the communication function executed by the communication application 21 into a communication I / F packet (communication information) that can be executed by the communication I / F driver 31, so that the existing communication application An I / F that passes communication information and communication data to the communication I / F driver 31 is provided without changing 21.
Details of the communication I / F library processing unit 23 will be described later.

  The driver OS 3 is one of virtual OSs that operate on the server 1. The driver OS 3 manages drivers of various hardware, so that the guest OS 2 can use various hardware in the server 1. Since the driver OS 3 can use various types of OSs, a driver that can be used only by a specific OS can be supported by changing the OS used according to the hardware driver.

  The driver OS 3 executes a communication I / F driver 31 that is a communication driver as one of the drivers. The communication I / F driver 31 stores communication information in the communication ring queue 41 based on the communication I / F packet acquired from the communication I / F library processing unit 23. Details of the communication I / F driver 31 will be described later.

  A software I / F 22 is interposed between the communication application 21 and the communication I / F library processing unit 23, and between the communication I / F library processing unit 23 and the communication I / F driver 31. Software I / Fs 24 and 32 are interposed. A general communication function can be used as the communication function. For example, a socket function widely used in TCP / IP communication processing is used as the communication function.

  Further, the server 1 has a communication ring queue (second storage area) 41, which will be described later, and a common memory (storage device) 4 holding a communication buffer (first storage area) 42. The virtual memory 2, the communication I / F driver 31, and the communication offload engine 5 can access the common memory 4.

The communication offload engine 5 is dedicated hardware that performs communication processing. The communication offload engine 5 includes a protocol stack engine 51 and a session management table 52.
The session management table 52 is a table for managing session information such as unique state information related to a communication session.
The protocol stack engine 51 can access the common memory 4 via the hardware I / F 6. The session information in the session management table 52, the communication information in the communication ring queue 41 in the common memory 4, the communication buffer 42 Based on the communication data, a communication packet is generated and analyzed, and transmitted / received to / from the communication destination server 9.

[Hardware configuration]
FIG. 2 is a diagram illustrating an example of a hardware configuration of the server.
The hypervisor 10, guest OS 2, driver OS 3, communication application 21, communication I / F library processing unit 23, communication I / F driver 31, and the like in FIG. 1 include a ROM (Read Only Memory) 203 and a HDD (Hard Disk Drive) 204. The program stored in is expanded in a RAM (Random Access Memory) 202 and executed by the CPU 201.
1 is held on the RAM 202 or the HDD 204, and communication data is transmitted to the network 8 via the communication interface 205 (corresponding to the communication offload engine 5 and the hardware I / F 7 in FIG. 1). Is done.

[Communication path]
FIG. 3 is a diagram illustrating a route through which communication data is transmitted and received.
With reference to FIG. 3, an example of a path when communication data is transmitted and received from the communication application 21 will be described. Details of the processing in each unit 21, 23, 31 will be described later.

  As shown in FIG. 3, the communication application 21 and the communication I / F library processing unit 23 exchange information for communication via the software I / F 22, and the communication I / F library processing unit 23. The communication I / F driver 31 exchanges information for communication via the software I / Fs 23 and 32. In addition, the communication I / F driver 31 and the communication offload engine 5 exchange information for communication via a hardware I / F 6 such as PCI Express (registered trademark). Further, the communication offload engine 5 and the communication destination server 9 communicate with each other via a hardware I / F 7 such as a PHY that is an NI and the network 8.

[Communication I / F Library Processing Unit]
Next, the communication I / F library processing unit 23 will be described in detail with reference to FIGS.
(Communication I / F packet)
FIG. 4 is a diagram illustrating an example of converting a communication function into a communication I / F packet.
As shown in the description of FIG. 3, the communication I / F library processing unit 23 receives communication information and communication data from an existing communication function executed by the communication application 21, for example, a socket function used in TCP / IP. A communication I / F packet to be acquired and transmitted to the communication I / F driver 31 is generated.
FIG. 4 shows an example of a conversion method from the send function 401, which is a communication function related to transmission, to the communication I / F packet 402 as an example.
The send function 401 includes, as arguments, “sockfd” that is a socket number for identifying a communication connection, “sbuf” that indicates a memory address for storing data to be transmitted, “len” that indicates the length of data to be transmitted, and at the time of transmission. “Flags” for setting various functions in the. The send function returns the size of the data that can be transmitted as a return value.

At the head of the communication I / F packet 402, a switch variable 421 indicating the type of communication function is set. As will be described later in FIG. 5, the switch variable 421 is set for each function, and the switch variable 421 of the communication I / F packet 402 corresponding to the send function 401 is set as No. 5 (switch (5)). . The communication I / F library processing unit 23 converts the communication function into the communication I / F packet 402 by setting the communication function argument in the communication I / F packet 402 following the switch variable 421.
Note that the method of generating the communication I / F packet 402 shown in FIG. 4 is an example, and it is natural that the communication I / F packet 402 may be generated by other methods.

(Switch variable management table 501)
FIG. 5 is a diagram illustrating an example of a switch variable management table according to the first embodiment.
The switch variable management table 501 is stored in the HDD 204 (FIG. 2), for example, and the communication I / F library processing unit 23 converts the communication function into a communication I / F packet according to the information in the switch variable management table 501. .
As shown in FIG. 5, in the switch variable management table 501, the switch variable corresponding to each communication function and the variable (communication information) set thereafter are set by the number of bits after the communication I / F packet. ing. That is, the relationship between the communication function and the bit arrangement of the communication I / F packet is set.

Note that the size of the communication I / F packet may be increased or decreased in accordance with the corresponding communication function.
In the example of FIG. 5, various communication functions are identified by the first switch variable (135 to 128 bits), and the various variables after the switch variable match the arguments of the respective communication functions. The portion corresponding to the argument of the communication function is communication information.

(flowchart)
FIG. 6 is a flowchart illustrating a procedure of communication I / F packet generation processing according to the first embodiment.
Generally, when communication by the communication application 21 is performed, a communication function is used, and communication processing is performed by a protocol stack that is software for communication processing operating on the guest OS 2.
In contrast, in this embodiment, the communication function executed by the communication application 21 is converted into a communication I / F packet that can be executed by the communication I / F driver 31 by the communication I / F library processing unit 23.

The communication application 21 executes a communication function (S101).
Then, the communication I / F library processing unit 23 generates a communication I / F packet from the communication function (S102).
The method of generating a communication I / F packet by the communication I / F library processing unit 23 is as described with reference to FIGS.

Then, the communication I / F library processing unit 23 transmits a communication I / F packet to the communication I / F driver 31 (S103).
The communication I / F driver 31 that has received the communication I / F packet processes the communication I / F packet by performing processing described later in FIGS. 7 to 10, and returns a return value to the communication I / F library processing unit 23. The communication I / F library processing unit 23 acquires the return value transmitted from the communication I / F driver 31 (S104).
Then, the communication I / F library processing unit 23 transmits the acquired return value as the return value of the communication function to the communication application 21 (S105), and completes the communication I / F packet generation process.

[Communication ring queue]
Next, the communication ring queue 41 will be described in detail with reference to FIGS.
(Explanation of communication ring queue 41)
FIG. 7 is an explanatory diagram of the communication ring queue according to the first embodiment.
The communication I / F driver 31 uses the communication ring queue 41 to exchange communication information and communication data with the communication offload engine 5.
The communication ring queue 41 includes a transmission ring queue 702 and a reception ring queue 701. The transmission ring queue 702 and the reception ring queue 701 are generated for each communication session.
The transmission ring queue 702 stores a memory address of a transmission buffer 711 that stores communication data to be transmitted. Similarly, the reception ring queue 701 stores the memory address of the reception buffer 712 that stores communication data (communication data). Note that the transmission buffer 711 and the reception buffer 712 constitute the communication buffer 42 and store data bodies (communication data) that are actually transmitted and received.

At the time of transmission of communication data, the communication I / F driver 31 stores communication information (queue data) regarding each variable regarding communication data in the transmission ring queue 702, and the protocol stack engine 51 of the communication offload engine 5 stores the communication information. Communication data is acquired from the transmission buffer 711 based on the queued data. The queue data will be described later.
Similarly, when receiving communication data, the protocol stack engine 51 of the communication offload engine 5 stores the memory address of the reception buffer 712 storing the received communication data in the reception ring queue 701 as queue data, The communication I / F driver 31 acquires communication data from the reception buffer 712 based on the stored queue data.

  The transmission ring queue 702 and the reception ring queue 701 are configured by a plurality of queues (one section in FIG. 7), and this queue has a ring-shaped (cyclicity) configuration, and sequentially processes in one direction. Therefore, the communication I / F driver 31 and the protocol stack engine 51 of the communication offload engine 5 set the queue data successively in order as long as the queues in the transmission ring queue 702 and the reception ring queue 701 are empty. You can get it. When the queues in the transmission ring queue 702 and the reception ring queue 701 are full, the communication I / F driver 31 and the communication offload engine 5 are in a standby state until the queues become empty.

(Communication ring queue configuration)
FIG. 8 is a diagram illustrating a configuration example of a communication ring queue according to the first embodiment. FIG. 8 shows a configuration example of the communication ring queue 41 (FIG. 7) taking TCP / IP communication as an example. Further, FIG. 8 shows a configuration example of one queue of the communication ring queue 41 (one section of the communication ring queue 41 in FIG. 7).
FIG. 8A is a diagram illustrating a configuration example of the transmission ring queue 702.
The transmission ring queue 702 stores a flag (storage information) indicating that the queue is valid, a destination port number used in TCP / IP communication, an expansion reserved area, a destination address, a transmission data size, and communication data. A transmission buffer address which is a memory address of the transmission buffer 711. When the transmission ring queue 702 is expanded, the data content of each queue may be changed or the data of each queue may be increased.
Here, in both FIG. 8 (a) and FIG. 8 (b), “address” indicates an address on the common memory 4 (FIG. 1) in which the data is stored, and the bit is the number of bits from the head of the address. .

  The reception ring queue 701 has the same configuration as that of the transmission ring queue 702, a flag indicating that the queue is valid, a transmission source port number used in TCP / IP communication, an expansion reserved area, a transmission It has a reception buffer address which is a memory address of the reception buffer 712 in which the original address, the reception data size, and the communication data are stored. When the reception ring queue 701 is expanded, the data contents of each queue may be changed or the data of each queue may be increased.

[Communication I / F driver 31]
Next, the communication I / F driver 31 will be described in detail with reference to FIGS. 9 and 10.
(Diagram)
FIG. 9 is a diagram illustrating the relationship between the configuration of the communication I / F driver and other functional units. In FIG. 9, the same components as those of FIG. In FIG. 9, the communication I / F library processing unit 23, the software I / Fs 22, 24, and 32, and the hardware I / F 6 are omitted.
The communication I / F driver 31 includes a communication I / F switch processing unit 901 and an interrupt processing unit 902. Note that the communication I / F driver 31 can also read and write to an internal register (not shown) and a memory (not shown) in the protocol stack engine 51 of the direct communication offload engine 5 via the line 921. Is possible.
The communication I / F switch processing unit 901 performs function processing according to the switch number of the communication I / F packet passed from the communication I / F library processing unit 23. Details of the communication I / F switch processing unit 901 will be described later.
The interrupt processing unit 902 processes an interrupt to the communication I / F driver 31 by various hardware such as the interrupt processing unit 911 in the protocol stack engine 51 of the communication offload engine 5.

  The communication ring queue 41 in the common memory 4 is a guest such as the communication ring queue 41 (# 1) corresponding to the guest OS2 (# 1) and the communication ring queue 41 (# 2) corresponding to the guest OS2 (# 2). Generated for each OS2. Further, the communication ring queue 41 is generated for each communication application process 951 operating on the guest OS 2. In the example of FIG. 9, the communication ring queue 41 (# 1a) for the communication application process 951 (# 1a) executed in the guest OS2 (# 1) and the communication application process 951 executed in the guest OS2 (# 2) The communication ring queue 41 (# 2a) corresponding to (# 2a) and the communication ring queue 41 (# 2b) corresponding to the communication application process 951 (# 2b) are generated. As described above, each communication ring queue 41 has a transmission ring queue 702 and a reception ring queue 701. Here, the communication application process 951 is a process in the communication application 21 (FIG. 1).

When transmitting communication data to the destination server 9, the communication I / F switch processing unit 901 of the communication I / F driver 31 stores various communication information in the transmission ring queue 702, and flags the corresponding queue (see FIG. 8). ) To “Enable”.
When transmission is executed continuously, the communication I / F switch processing unit 901 of the communication I / F driver 31 stores communication information in each queue of the transmission ring queue 702 one after another, and sets the flag of the queue to “valid”. To.

  The protocol stack engine 51 of the communication offload engine 5 refers to the flag of the transmission ring queue 702. If “valid”, the destination port number and destination address information of the transmission ring queue 702 (both refer to FIG. 8). Further, the memory address of the transmission buffer 711 storing the communication data is acquired from the transmission buffer address (see FIG. 8). Then, the protocol stack engine 51 of the communication offload engine 5 refers to the transmission data size of the transmission ring queue 702, acquires data having a length corresponding to the transmission data size referred to from the acquired transmission buffer address, and acquires the acquired data. Is transmitted as communication data to the destination address (communication destination server 9). Thereafter, the protocol stack engine 51 of the communication offload engine 5 sets the flag of the transmission ring queue 702 to “invalid” and processes the next transmission ring queue 702.

When receiving communication data from the communication destination server 9, the communication application 21 executes a recv (receive) function. In the recv function, a reception buffer address is set as an argument, and the communication I / F driver 31 that has received this reception buffer address as communication information of the communication I / F packet receives the reception buffer address in the reception ring queue 701. Store in the receive buffer address.
When the protocol stack engine 51 of the communication offload engine 5 receives the communication data from the communication destination server 9, the protocol stack engine 51 acquires the reception buffer address of the queue whose flag is “invalid” from the reception ring queue 701 and acquires the received buffer address The received communication data is stored in the reception buffer 712 corresponding to the reception buffer address. Then, the protocol stack engine 51 of the communication offload engine 5 sets the size of the stored communication data in the reception data size (see FIG. 8) portion of the reception ring queue 701, and sets the processing target flag ( “Refer to FIG. 8” is set to “valid”. The communication I / F switch processing unit 901 of the communication I / F driver 31 refers to the reception buffer address and communication data size of the queue for which the flag of the reception ring queue 701 is “valid”, and the communication I / F library processing unit 23 Then, the communication I / F library processing unit 23 transmits the return value to the communication application 21.
When receiving the return value from the communication I / F driver 31, the communication application 21 acquires the received communication data from the reception buffer address set in the argument of the executed recv function.

Thereafter, the communication I / F switch processing unit 901 of the communication I / F driver 31 sets the processing target flag of the reception ring queue 701 to “invalid”.
When the communication application 21 executes the recv function again, the reception buffer address, the reception buffer size, and the like are set, and the flag of the reception ring queue 701 is set to be receivable.

  By doing so, since communication data is exchanged between the functional units at the time of transmission and reception at the memory address of the communication buffer 42, it is possible to reduce the processor load related to the copy of the communication data. That is, the communication data is managed by the memory address of the communication buffer 42 (for example, a pointer in C language), and the main body of the communication data stored in the communication buffer 42 is not moved (copied). Processor load and memory load can be reduced.

(Communication I / F packet processing)
FIG. 10 is a flowchart illustrating a communication I / F packet processing procedure according to the first embodiment.
First, the communication I / F switch processing unit 901 of the communication I / F driver 31 receives the communication I / F packet 301 from the communication I / F library processing unit 23 (S201).
Then, the communication I / F switch processing unit 901 determines the head switch variable (FIG. 4) of the received communication I / F packet (S202). As a result, the communication I / F switch processing unit 901 determines which communication function the received communication I / F packet corresponds to. The correspondence between the communication I / F switch variable and the type of the communication function conforms to the switch variable management table 501 described above with reference to FIG.

If the switch variable is “0” (S202 → 0), the communication I / F switch processing unit 901 determines that the communication function name is “socket”, and the communication I / F driver 31 and the communication offload engine 5 perform FIG. A socket used for communication is generated via the line 921 in FIG. 5 and socket function processing for generating the communication ring queue 41 on the common memory 4 is performed (S203).
If the switch variable is “1” (S202 → 1), the communication I / F switch processing unit 901 determines that the communication function name is “bind”, and sends the self-information to the generated socket via the line 921 in FIG. A bind function process for assigning (address, port number) is performed (S204).
If the switch variable is “2” (S202 → 2), the communication I / F switch processing unit 901 determines that the communication function name is “listen”, and the communication I / F driver 31 and the communication offload engine 5 perform FIG. The listen function process for registering the socket to which the self information is assigned as a standby socket is performed via the line 921 (S205).

If the switch variable is “3” (S202 → 3), the communication I / F switch processing unit 901 determines that the communication function name is “accept”, and the communication I / F driver 31 and the communication offload engine 5 perform FIG. The connection partner is waited for through the line 921, and when the connection is established, an accept function process for generating a new socket is performed (S206).
If the switch variable is “4” (S202 → 4), the communication I / F switch processing unit 901 determines that the communication function name is “connect”, and the communication I / F driver 31 and the communication offload engine 5 perform FIG. Then, a connect function process for issuing a connection request to the designated address and port number is performed via the line 921 (S207).

If the switch variable is “5” (S202 → 5), the communication I / F switch processing unit 901 determines that the communication function name is “send”, and the communication I / F driver 31 and the communication offload engine 5 communicate data. The send function processing for transmitting is performed (S208).
If the switch variable is “6” (S202 → 6), the communication I / F switch processing unit 901 determines that the communication function name is “recv (receive)”, and the communication I / F driver 31 and the communication offload engine 5 Performs recv function processing for receiving communication data (S209).
If the switch variable is “7” (S202 → 7), the communication I / F switch processing unit 901 determines that the communication function name is “close”, and the communication I / F driver 31 and the communication offload engine 5 perform FIG. A close function process for closing the socket is performed via the line 921 (S210).
Details of each processing in steps S203 to S210 will be described later.
Note that these functions may be increased or decreased as application processing is offloaded.

  After completing each processing of steps S203 to S210, the communication I / F switch processing unit 901 transmits a return value requested by each communication function to the communication I / F library (S211), and performs communication I / F packet processing. Exit.

[Example of TCP / IP communication]
Next, a sequence when TCP / IP communication is performed as an example of the present embodiment will be described along FIGS. 11 to 19 with reference to FIGS. 1, 7, and 9.
In TCP / IP communication, a connection establishment sequence is required as preparation prior to transmission / reception communication. In TCP / IP communication, a number called a sequence number is used to manage how far the data has been transmitted and received. The initial value of this sequence number is exchanged between the transmitting side and the receiving side, and communication is started.

(Active open)
FIG. 11 and FIG. 12 are sequence diagrams showing an example of an active open processing procedure according to the first embodiment. The active open is an open process in which the server 1 transmits a connection establishment request to the communication destination server 9 first.
First, the communication application 21 of the guest OS 2 executes a socket function (S301), and generates a communication socket.
Then, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the executed socket function, and generates a communication I / F packet corresponding to the socket function. Then, the generated communication I / F packet is transmitted to the communication I / F driver 31 (S302: equivalent to S103 in FIG. 6).

The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the socket function. If it is determined that there is a communication ring queue 41 corresponding to the communication application 21 being executed on the common memory 4 (S303). Further, the communication I / F switch processing unit 901 generates session information, and stores the generated session information in the session management table 52 of the communication offload engine 5 (S304). The processing in steps S303 and S304 is processing (socket function processing) corresponding to step S203 in FIG.
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value to the communication I / F library processing unit 23 (S305: equivalent to S211 in FIG. 10), and further, the communication I / F The library processing unit 23 transmits a return value (socket identifier) to the communication application 21 (S306).

Subsequently, the communication application 21 executes a connect function (S307).
Based on the executed connect function, the communication I / F library processing unit 23 generates a corresponding communication I / F packet by the processing in step S102 of FIG. 6, and transmits it to the communication I / F driver 31 (S308). : Equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received this communication I / F packet performs the process of step S202 of FIG. 10, and the received communication I / F packet corresponds to the connect function. If it is determined, the session information such as the destination address of the communication destination server 9 is stored in the session management table 52 of the communication offload engine 5 to establish a connection (S309).

Then, the protocol stack engine 51 of the communication offload engine 5 accesses the communication ring queue 41 corresponding to the guest OS 2 (S310), acquires the queue data of the transmission ring queue 702 and the reception ring queue 701 (S311), and receives the data. Ready for reception (ready for reception). Hereinafter, the reception ring queue 701 to be accessed is the reception ring queue 701 corresponding to the guest OS 2 to be processed (see FIG. 9). Each queue data stores a memory address of the corresponding reception buffer 712 in advance, and other information is blank.
Then, the protocol stack engine 51 of the communication offload engine 5 transmits a TCP / IP packet (SYN packet) in which a SYN (Synchronize) flag is set through the network 8 to the communication destination server 9 with which the connection has been established. (S312 in FIG. 12).

The communication destination server 9 that has received the SYN packet transmits a TCP / IP packet (SYN-ACK packet) in which a SYN flag and an ACK (ACKnowledgement) flag are set to the server 1 as a response to the received TCP / IP packet (S313). ).
The protocol stack engine 51 of the communication offload engine 5 that has received the SYN-ACK packet from the communication destination server 9 sends a TCP / IP packet (ACK packet) in which an ACK flag indicating that this TCP / IP packet has been received is set. It transmits to the communication destination server 9 (S314).

.
Then, the interrupt processing unit 911 of the communication offload engine 5 notifies the interrupt processing unit 902 of the communication I / F driver 31 of the connection establishment completion interrupt (S315), and the communication I that has received the connection establishment completion interrupt. The interrupt processing unit 902 of the / F driver 31 clears the interrupt that notifies the interrupt processing unit 911 of the communication offload engine 5 that the connection establishment completion interrupt has been received (S316). The communication offload engine 5 is notified that the notification has been received. Note that the processing in steps S309 to S316 corresponds to the processing in step S207 (connect function processing) in FIG.

Subsequently, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value indicating that the connection establishment is completed to the communication I / F library process (S317: equivalent to S211 in FIG. 10). Then, the communication I / F library processing unit 23 sends a return value to the communication application 21 (S318: corresponding to S105 in FIG. 6), thereby notifying the communication application 21 of the completion of connection establishment.
The above is the active open sequence. The virtual system Z can transmit and receive communication data by this sequence.

(Passive open)
13 to 15 are sequence diagrams illustrating an example of a passive open processing procedure according to the first embodiment. Passive open is an open process in which a partner sends a connection establishment request to itself first.
First, the communication application 21 of the guest OS 2 executes a socket function (S401).
Then, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the generated socket function, and generates a communication I / F packet corresponding to the socket function. Then, the generated communication I / F packet is transmitted to the communication I / F driver 31 (S402: equivalent to S103 in FIG. 6).

The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the socket function. When it is determined that there is a communication ring queue 41 on the common memory 4 (S403), session information is generated, and the generated session information is stored in the session management table 52 of the communication offload engine 5 (S404). Note that the processing in steps S403 and 404 corresponds to the processing in step S203 (socket function processing) in FIG.
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value (socket identifier) to the communication I / F library processing unit 23 (S405: equivalent to S211 in FIG. 10). The communication I / F library processing unit 23 transmits a return value to the communication application 21 (S406: corresponding to S105 in FIG. 6).

Next, the communication application 21 executes the bind function (S407).
The communication I / F library processing unit 23 generates a corresponding communication I / F packet from the executed bind function by the communication I / F packet generation processing in step S <b> 102 of FIG. 6, and sends it to the communication I / F driver 31. Transmit (S408 :: equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received this communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the bind function. If it is determined, the session information is generated, and the generated session information is stored in the session management table 52 (S409). Note that the processing in step S409 corresponds to the processing in step S204 (bind function processing) in FIG.
Subsequently, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value to the communication I / F library processing unit 23 (S410: equivalent to S211 in FIG. 10), and further, the communication I / F The F library processing unit 23 transmits a return value to the communication application 21 (S411: corresponding to S105 in FIG. 6), thereby notifying the communication application 21 that the storage of the session information has been completed.

Subsequently, the communication application 21 executes a listen function (S412 in FIG. 14).
The communication I / F library processing unit 23 generates a corresponding communication I / F packet by performing the communication I / F packet generation process in step S102 of FIG. 6 on the executed listen function, and generates a communication I / F. The data is transmitted to the driver 31 (S413: equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received this communication I / F packet performs the process of step S202 of FIG. 10, and the received communication I / F packet corresponds to the listen function. If it is determined, the reception establishment flag is set in the session management table 52 of the communication offload engine 5 (S414). Accordingly, the communication offload engine 5 can receive connection establishment from the communication destination server 9.
Then, the protocol stack engine 51 of the communication offload engine 5 accesses the communication ring queue 41 (S415), acquires the queue data of the transmission ring queue 702 and the reception ring queue 701 (S416), and can handle reception. (Reception ready) Each queue data stores a memory address of the corresponding reception buffer 712 in advance, and other information is blank.

When step S416 ends, the interrupt processing unit 911 of the communication offload engine 5 transmits a reception preparation completion interrupt for notifying completion of reception preparation to the communication I / F driver 31 (S417).
The interrupt processing unit 902 of the communication I / F driver 31 that has received the reception ready preparation notification notifies the communication offload engine 5 that the reception ready preparation notification has been received by clearing the interrupt (S418). To do. Note that the processing in steps S414 to S418 corresponds to the processing in step S205 (listen function processing) in FIG.

  Thereafter, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value indicating that the listen function processing has been completed to the communication I / F library processing unit 23 (S419: S211 in FIG. 10). Correspondingly), the communication I / F library processing unit 23 transmits a return value to the communication application 21 (S420: corresponding to S105 in FIG. 6), thereby notifying the communication application 21 of completion of reception correspondence preparation.

By receiving the return value of the listen function process, the communication application 21 that has received the notification of completion of reception correspondence execution executes the accept function (S421).
Then, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the generated accept function, and generates a communication I / F packet corresponding to the accept function. Then, the generated communication I / F packet is transmitted to the communication I / F driver 31 (S422: equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the accept function. If it is determined that there is a connection established server 9 is set in a connection establishment standby state (S423).

The communication destination server 9 transmits a TCP / IP packet (SYN packet) with the SYN flag set to the server 1 via the network 8 (S424 in FIG. 15), and the protocol stack engine 51 of the communication offload engine 5 However, when receiving this SYN packet, the interrupt processing unit 911 of the communication offload engine 5 transmits a connection establishment interrupt for notifying the connection establishment to the communication I / F driver 31 (S425).
Then, the interrupt processing unit 902 of the communication I / F driver 31 notifies the communication offload engine 5 that the notification of the connection establishment interrupt has been received by clearing the interrupt (S426).

Subsequently, the protocol stack engine 51 of the communication offload engine 5 transmits a TCP / IP packet (SYN-ACK packet) in which the SYN flag and the ACK flag for notifying the communication destination server 9 of the connection establishment are set to the communication destination server 9. (S427).
Upon receiving the SYN-ACK packet, the communication destination server 9 transmits a TCP / IP packet (ACK packet) in which an ACK flag for notifying that the TCP / IP packet has been received is set to the communication destination server 9 ( S428).

The interrupt processing unit 911 of the communication offload engine 5 in the server 1 that has received the ACK packet transmits a connection establishment success interrupt to the communication I / F driver 31 (S429).
The interrupt processing unit 902 of the communication I / F driver 31 notifies the communication offload engine 5 that the notification of the successful communication establishment interrupt has been received by clearing the interrupt (S430).
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 newly generates the communication ring queue 41 on the common memory 4 (S431).

The communication I / F switch processing unit 901 of the communication I / F driver 31 communicates with the server 1 by notifying the communication offload engine 5 that the communication ring queue 41 for communication has been generated on the common memory 4. A communication session with the destination server 9 is generated (S432).
Subsequently, the protocol stack engine 51 of the communication offload engine 5 accesses the communication ring queue 41 generated in step S431 (S433), acquires data from the communication ring queue 41 (S434), and sets the communication ready state. Become. Note that the processing in steps S423 to S434 corresponds to the processing in step S206 (accept function processing) in FIG.

Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits the newly generated socket identifier as a return value to the communication I / F library processing unit 23 (S435), and further the communication I / F. The library processing unit 23 transmits this return value to the communication application 211 (S436), and ends the passive open process.
The above is the passive open sequence. The virtual system Z can transmit and receive communication data by this sequence.

(Transmission process)
FIG. 16 is a sequence diagram illustrating an example of a processing procedure of data transmission processing according to the first embodiment.
The process shown in FIG. 16 is executed after the connection is established by active open or passive open.
First, prior to the transmission process, the communication application 21 generates communication data to be transmitted, secures an area for storing the communication data on the common memory 4 (transmission buffer), and stores the communication data in the transmission buffer 711. The memory address of the stored transmission buffer 711 is acquired.
Then, the communication application 21 executes the send function (S501). At this time, the memory address of the transmission buffer 711 storing the communication data is set as an argument of the send function.
Subsequently, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the generated send function, and generates a communication I / F packet corresponding to the send function. The generated communication I / F packet is transmitted to the communication I / F driver 31 (S502: equivalent to S103 in FIG. 6).

  The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the send function. If it is determined that there is, the size of the communication data to be transmitted to the transmission ring queue 702 (transmission data size (FIG. 8)) and the memory address (transmission buffer address (FIG. 8)) of the transmission buffer 711 in which the communication data is stored. Store (S503), and set the flag of the corresponding queue to “valid”. As described above, since the communication function argument is set in the communication I / F packet, the address of the transmission buffer 711 and the size of the communication data are also set in the communication I / F packet.

  Thereafter, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a data transmission request to the communication offload engine 5 (S504). At this time, when transmission is continuously executed, the communication offload engine 5 checks the flag of the transmission ring queue 702 one after another without transmitting the data transmission request to the communication offload engine 5 each time. The communication data in the transmission buffer 711 corresponding to the “valid” queue may be transmitted to the communication destination server 9.

The protocol stack engine 51 of the communication offload engine 5 that has received the data transmission request accesses the transmission ring queue 702 (S505), and acquires data in the transmission ring queue 702 (S506).
Then, the protocol stack engine 51 of the communication offload engine 5 accesses the transmission buffer 711 of the communication buffer 42 corresponding to the transmission buffer address (FIG. 8) in the transmission ring queue 702 (S507), and transmits the transmission data in the transmission ring queue 702. Communication data for the size (FIG. 8) is acquired (S508).

Then, the protocol stack engine 51 of the communication offload engine 5 generates a transmission packet from the acquired communication data (S509), and transmits the transmission packet to the communication destination server 9 based on the destination address (FIG. 8) in the transmission ring queue 702. Is transmitted (S510).
Upon receiving the communication data (all communication packets), the communication destination server 9 transmits to the server 1 a TCP / IP packet (ACK packet) in which the ACK flag is set, indicating that the data has been received (S511).

The interrupt processing unit 911 of the communication offload engine 5 that has received the ACK packet notifies the communication I / F driver 31 of a transmission completion interrupt for notifying the completion of transmission (S512).
The interrupt processing unit 902 of the communication I / F driver 31 notifies the communication offload engine 5 that the notification of the transmission completion interrupt has been received by transmitting an interrupt clear to the communication offload engine 5 (S513). To do. Note that the processing in steps S503 to S513 corresponds to the processing in step S208 (send function processing) in FIG.
Thereafter, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits the number of bytes of communication data that can be transmitted to the communication I / F library processing unit 23 as a return value (S514: equivalent to S211 in FIG. 10). ), The communication I / F library processing unit 23 transmits the size of the communication data transmitted to the communication application 21 as a return value (S515: equivalent to S105 in FIG. 6).
The above is the data transmission sequence. The virtual system Z transmits communication data to the communication destination server 9 by this sequence.

(Another transmission example 1)
In this embodiment, an area on the common memory 4 (that is, the transmission buffer 711) for the communication application 21 to store communication data is secured. However, the present invention is not limited to this, and the following processing is also possible. Good.
That is, not the communication application 21 but the communication I / F driver 31 reserves an area on the common memory 4 in advance and transmits the memory address to the communication application 21. When executing the send function, the communication application 21 executes the memory address acquired from the communication I / F driver 31 as an argument, and stores the communication data to be transmitted in the memory address transmitted from the communication I / F driver 31. To do. Thereafter, steps S501 to S515 in FIG. 16 may be performed.

(General transmission processing used so far)
Here, a general transmission process used so far will be described.
(A1) Prior to the transmission process, the communication application generates communication data to be transmitted, secures an area for storing the communication data on the memory, and stores the communication data in the transmission buffer.
(A2) The communication application executes a send function with the memory address of the memory storing the communication data as an argument.
(A3) The protocol stack executed in the guest OS copies the communication data stored in the memory address set as the argument of the send function to the memory area reserved by itself (1) Second data copy).
(A4) The protocol stack generates a communication packet from the copied communication data.
(A5) The protocol stack copies the generated communication packet to the driver OS (second data copy).
(A6) The driver OS transfers the communication packet to the network card, and the network card transmits the communication packet to the communication destination server.

  As described above, in the general transmission processing that has been used so far, two data copies are generated during the transmission processing. In contrast, in the transmission process according to the present embodiment, the memory address (transmission buffer address) of the transmission buffer 711 in which communication data is stored is stored in the transmission buffer address (FIG. 8) of the transmission ring queue 702, and the communication I The / F driver 31 and the communication offload engine 5 read the communication data with reference to the transmission buffer address and transmit it. For this reason, the communication data is not copied to another place until the communication offload engine 5 transmits the communication data (communication packet) after the communication application 21 stores the communication data in the transmission buffer 711. That is, data copy does not occur in the transmission processing according to the present embodiment.

(Another transmission example 2)
Further, the virtual system Z may perform the following processing in the transmission processing of the present embodiment.
(B1) The communication I / F driver 31 reserves an area for storing communication data in advance in the common memory 4 (this is the transmission buffer 711) and holds the memory address of that area. .
(B2) Generate communication data to be transmitted by the communication application 21, and store the communication data in an area on the common memory 4 secured by the communication application 21 (separate from the area secured by the communication I / F driver 31). Store.
Thereafter, the processing of steps S501 and S502 in FIG. 16 is performed, and the communication I / F driver 31 receives a communication I / F packet having a memory address where the communication application 21 stores communication data. When the communication I / F driver 31 acquires the communication data from the memory address in the communication I / F packet, the communication I / F driver 31 copies it to the area (transmission buffer 711) secured by itself (data copy).
Then, the communication I / F driver 31 stores the memory address of the copied area (transmission buffer 711) in the transmission ring queue 702 as a transmission buffer address.
Thereafter, communication data is transmitted in the same manner as in FIG.

  In this method, data copying occurs once, but the number of times of data copying can be reduced as compared with general transmission processing in which data copying occurs twice.

(Reception processing)
FIG. 17 is a sequence diagram illustrating an example of a processing procedure of data reception processing according to the first embodiment. The process of FIG. 17 is executed after the connection is established by the active open of FIGS. 11 and 12 or the passive open of FIGS.
Prior to the reception process, the communication application 21 secures an area for storing communication data on the common memory 4.
First, the communication application 21 executes a recv (receive) function (S601). In this recv function, the memory address of the reception buffer 712 in which the received communication data is stored is set.
Subsequently, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the executed recv function, and generates a communication I / F packet corresponding to the recv function. The generated communication I / F packet is transmitted to the communication I / F driver 31 (S602: equivalent to S103 in FIG. 6). In this communication I / F packet, the memory address of the reception buffer 712 in which the received communication data set in the recv function is stored is set as one piece of communication information.

  The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the recv function. After determining that there is, the communication information of the communication I / F packet is stored in the reception ring queue 702 of the communication ring queue 42 (S603), and a reception standby state is entered (S604). In the processing of step S603, the communication I / F switch processing unit 901 stores the memory address of the reception buffer 712 set in the communication I / F packet in the reception ring queue 701 as the reception buffer address (FIG. 8). . At this time, the communication I / F switch processing unit 901 stores a resv function (communication application process 951) corresponding to the stored queue.

Then, the communication destination server 9 transmits communication data as a TCP / IP packet to the server 1 (S605), and when the protocol stack engine 51 of the communication offload engine 5 receives this communication data, it becomes “invalid”. Referring to the reception ring queue 701, the communication data is stored in the reception buffer 712 indicated by the reception buffer address (FIG. 8) of the queue (S606), and the flag of the corresponding queue is set to “valid”. At this time, the protocol stack engine 51 stores the size of the received communication data in the reception data size of the reception ring queue 701 (FIG. 8).
When the storage of the communication data is completed, the protocol stack engine 51 of the communication offload engine 5 transmits a TCP / IP packet (ACK packet) with the ACK flag set to the communication destination server 1 (S607).

  After transmitting the ACK packet, the interrupt processing unit 911 of the communication offload engine 5 transmits a reception completion interrupt for notifying the completion of reception to the communication I / F driver 31 (S608). In the case of continuous reception, the protocol stack engine 51 of the communication offload engine 5 does not have to transmit a reception completion interrupt every time it is received, and the communication I / F switch 31 performs communication I / F switch processing. The unit 901 checks the flag of the reception ring queue 701 at regular intervals, and if there is a queue whose flag is “valid”, the interrupt processing unit 911 receives a reception completion interrupt for notifying the completion of reception. May be transmitted to the communication I / F driver 31.

The interrupt processing unit 902 of the communication I / F driver 31 that has received the reception completion interrupt communicates that the reception completion interrupt notification has been received by transmitting an interrupt clear to the communication offload engine 5 (S609). Notify the off-road engine 5.
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 accesses the reception ring queue 701 (S610). If there is a queue whose flag is “valid”, the queue data of the queue is stored. Obtaining (S611), the size of the received communication data stored in the received data size is obtained. The communication I / F switch processing unit 901 transmits a return value to the communication I / F library processing unit 23 toward the recv function (communication application process 951) corresponding to this queue (S612: S211 in FIG. 10). The communication I / F library processing unit 23 transmits a return value to the communication application 21 (S613: corresponding to S105 in FIG. 6). This return value is the size of the received communication data. The communication application 21 that has received the return value acquires data (communication data) for the size acquired as the return value from the memory address set in the argument of the recv function executed by itself (S614).
The above is the data reception sequence. Communication data is received by this sequence.

(Another reception example 1)
In this embodiment, the memory address of the reception area (reception buffer 712) is notified to the communication I / F driver 31 by the communication I / F packet associated with the execution of the recv function. Before, the memory address of the area (reception buffer 712) secured by the communication application 21 may be notified to the communication I / F driver 31 in advance. In this notification, the communication I / F driver 31 is notified by setting the memory address in the communication I / F packet generated by the communication I / F library processing unit 23.
In this case, after the memory address notified by the communication I / F driver 31 is stored in the reception buffer address (FIG. 8) of the reception ring queue 701, the communication application 21 executes the recv function. In the recv function at this time, the memory address notified to the communication I / F driver 31 is set as an argument.
In this example, it is also possible for the communication offload engine 5 to receive communication data from the communication destination server 9 and store the communication data in the reception buffer 712 indicated by the reception buffer address before executing the recv function.
In this case, the processing of FIGS. 6 and 10 may not be performed.

(General reception processing used so far)
Here, a general reception process used so far will be described.
(C1) The communication application executes the recv function. In this recv function, a memory address to the reception buffer is set as an argument.
(C2) When the network card receives the communication data (communication packet) from the communication destination server, the network card transfers the communication data (communication packet) to the driver OS. Note that the communication application may execute the recv function after receiving the communication data.
(C3) The driver OS copies the transferred communication data (communication packet) to the protocol stack of the guest OS (first data copy).
(C4) When packet processing is performed on the copied communication data (communication packet), the protocol stack copies the communication data to the memory address set as an argument in the recv function (second data copy).
(C5) The protocol stack transmits the received communication data size as a return value to the communication application.

As described above, in the general reception process used so far, two data copies are generated during the reception process. On the other hand, in the reception process according to the present embodiment, the memory address (transmission buffer address) of the reception buffer 712 in which communication data is stored is stored in the reception buffer address (FIG. 8) of the reception ring queue 701. The offload engine 5 stores the received communication data in the reception buffer 712 indicated by the reception buffer address.
Then, the communication application 21 reads communication data based on this reception buffer address.
For this reason, the communication data is not copied to another location until the communication application 21 reads the communication data (communication packet) after the communication offload engine 5 stores the communication data in the reception buffer 712. That is, no data copy occurs in the reception process according to the present embodiment.

(Reception form example 2)
Further, the virtual system Z may perform the following processing in the reception processing of the present embodiment.
(D1) The communication application 21 secures an area for storing communication data on the common memory 4.
(D2) The communication I / F driver 31 secures an area for storing communication data on the common memory 4, and stores the memory address of this area in the reception buffer address (FIG. 8) of the reception ring queue 701. . Note that the area secured by the communication I / F driver 31 is different from the area secured by the communication application 21. An area secured by the communication I / F driver 31 is a reception buffer 712. The processing order of (1) and (2) may be reversed.
(D3) The communication application 21 executes the recv function. The memory address of the area secured by the communication application 21 is set as an argument of the recv function.
(D4) The communication I / F library processing unit 23 generates a communication I / F packet having a memory address that is an argument of the recv function, and transmits it to the communication I / F driver 31.

(D4) When the communication offload engine 5 receives the communication data from the communication destination server 9, processing similar to S604 to S608 in FIG. 17 is performed. The processing order of (3) and (4) may be reversed.
(D5) If there is a queue of the reception ring queue 701 that is “valid”, the communication I / F driver 31 acquires the communication data from the reception buffer 712 indicated by the reception buffer address of the queue, and transmits the communication data. The data is copied (data copy) to the memory address of the received communication I / F packet (that is, indicated by the argument of the recv function). That is, the communication I / F driver 31 copies the communication data acquired from the reception buffer 712 to an area on the common memory 4 secured by the communication application 21. The communication data size is acquired from the received data size of the queue to be processed.
(D6) The communication I / F driver 31 transmits the return value to the communication application 21 via the communication I / F library processing unit 23 using the size of the received communication data as a return value.
(D7) The communication application 21 acquires communication data for the size acquired as the return value from the memory address set as the argument of the recv function.
In this case, the processing of FIGS. 6 and 10 may not be performed.

  In this method, data copying occurs once, but the number of times of data copying can be reduced as compared with general reception processing in which data copying occurs twice.

(Active close)
In TCP / IP communication, a communication end sequence is required as a transmission / reception communication end process. With reference to FIGS. 18 and 19, a close process will be described as a communication end process.
FIG. 18 is a sequence diagram illustrating an example of an active close processing procedure according to the first embodiment. Active close is processing in which the server 1 performs close processing.
First, the communication application 21 executes a close function (S701).
Subsequently, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the executed close function, and generates a communication I / F packet corresponding to the close function. The generated communication I / F packet is transmitted to the communication I / F driver 31 (S702: equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the close function. If it is determined that there is a session, the communication offload engine 5 is instructed to close the session (S703).

The protocol stack engine 51 of the communication offload engine 5 instructed to perform the close process transmits a TCP / IP packet (FIN packet) in which the FIN (FINish) flag is set to the communication destination server 9 (S704).
The destination server 9 that has received the FIN packet transmits a TCP / IP packet (FIN-ACK packet) in which the FIN flag and the ACK flag are set to the server 1 (S705).
The protocol stack engine 51 of the communication offload engine 5 that has received the FIN-ACK packet transmits a TCP / IP packet (ACK packet) in which the ACK flag is set to the communication destination in order to notify the communication destination server 9 that the packet has been received. It transmits to the server 9 (S706).

The interrupt processing unit 911 of the communication offload engine 5 that has transmitted the ACK packet transmits an end process completion interrupt for notifying the end of the end (close) process to the communication I / F driver 31 (S707).
The interrupt processing unit 902 of the communication I / F driver 31 notifies the communication offload engine 5 that the end processing completion interrupt notification has been received by clearing the interrupt (S708).
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 clears the communication ring queue 41 of the common memory 4 (S709), and clears the session management table 52 of the communication offload engine 5 (S710). Clear session information. Note that the processing in steps S703 to S710 corresponds to the processing in step S210 (close function processing) in FIG.

Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value indicating completion of the communication end processing to the communication I / F library processing unit 23 (S711: equivalent to S211 in FIG. 10). Further, the communication I / F library processing unit 23 transmits this return value to the communication application 21 (S712: corresponding to S105 in FIG. 6).
The above is the active close sequence. The virtual system Z can close communication by this sequence.

(Passive close processing)
FIG. 19 is a sequence diagram illustrating an example of a processing procedure for passive close according to the first embodiment. The passive close is a close process in which the communication destination server 9 transmits a communication end first.
First, the communication destination server 9 transmits a TCP / IP packet (FIN packet) with the FIN flag set to the server 1 (S801).
The protocol stack engine 51 of the communication offload engine 5 that has received the FIN packet transmits a TCP / IP packet (ACK packet) in which the ACK flag is set to the communication destination server 9 (S802).
Then, the interrupt processing unit 911 of the communication offload engine 5 transmits an end notification reception interrupt for notifying that the FIN packet has been received to the communication I / F driver 31 (S803).
The interrupt processing unit 902 of the communication I / F driver 31 that has received the interrupt notifies the communication offload engine 5 that the notification of the end notification reception interrupt has been received by clearing the interrupt (S804).

Thereafter, the communication application 21 executes a close function (S805).
Subsequently, the communication I / F library processing unit 23 performs communication I / F packet generation processing in step S102 of FIG. 6 based on the generated close function, and generates a communication I / F packet corresponding to the close function. The generated communication I / F packet is transmitted to the communication I / F driver 31 (S806: equivalent to S103 in FIG. 6).
The communication I / F switch processing unit 901 of the communication I / F driver 31 that has received the communication I / F packet performs the process of step S202 in FIG. 10, and the received communication I / F packet corresponds to the close function. If it is determined, close processing is instructed to the communication offload engine 5 (S807).

  The protocol stack engine 51 of the communication offload engine 5 instructed to perform the close process transmits a TCP / IP packet (FIN packet) with the FIN flag set to the communication destination server 9 (S808). Note that step S802 is omitted, and steps S803 to S807 are performed. In step S808, the protocol stack engine 51 transmits a FIN-ACK packet that is a combination of the ACK packet in step S802 and the FIN packet in step S808 to the communication server. You may make it transmit to 9.

The destination server 9 that has received the FIN packet notifies the server 1 that the FIN packet has been received by transmitting a TCP / IP packet (ACK packet) in which the ACK flag is set to the server 1 (S809).
Receiving the ACK packet, the interrupt processing unit 911 of the communication offload engine 5 transmits an end process completion interrupt for notifying the end of the end (close) process to the communication I / F driver 31 (S810).
Then, the interrupt processing unit 902 of the communication I / F driver 31 notifies the communication offload engine 5 that the notification of the end processing completion interrupt has been received by clearing the interrupt to the communication offload engine 5 (S811). To do.

Thereafter, the communication I / F switch processing unit 901 of the communication I / F driver 31 clears the communication ring queue 41 (S812), and clears the session management table 52 of the communication offload engine 5 (S813). Clear information. Note that the processing in steps S807 to S813 corresponds to the processing in step S210 (close processing) in FIG.
Then, the communication I / F switch processing unit 901 of the communication I / F driver 31 transmits a return value indicating completion of the communication end processing to the communication I / F library processing unit 23 (S814: equivalent to S211 in FIG. 10). Further, the communication I / F library processing unit 23 returns this return value to the communication application 21 (S815: corresponding to S105 in FIG. 6).
The above is the passive close sequence. With this sequence, communication can be closed.

[Summary]
According to the first embodiment, the exchange of communication data is managed by the memory address of the communication buffer 42 (for example, a pointer in C language), and the communication data main body stored in the communication buffer 42 is not moved (copied). Thus, it is possible to reduce the processor load related to the copy of communication data. That is, it is possible to improve processing overhead such as processor load and memory access load of the guest OS 2 and driver OS 3 due to communication processing, and to reduce communication processing load and communication performance of the entire server 1 on which the guest OS 2 operates.

Further, according to the first embodiment, the communication I / F library processing unit 23 converts an existing communication function (such as a socket function) into a communication I / F packet and uses it, thereby operating on the guest OS 2. The communication I / F driver 31 and the communication offload engine 5 according to the present embodiment can be introduced without changing the communication application 21 or renewing the communication function to be used.
Further, the number of guest OSs 2 accommodated in the server 1 can be increased by reducing the processing load of the entire server 1 due to the reduction of the processor load related to the copy of communication data.

  In the present embodiment, it is assumed that the size and memory address of the communication buffer 42 are managed by the communication application 21, but the present invention is not limited to this, and the communication I / F driver 31 may manage the size and memory address. . In this case, since the communication application 21 cannot use the communication buffer 42, the communication application 21 needs to pass communication data to the communication I / F driver 31. Therefore, data copy of communication data occurs between the communication application 21 and the communication I / F driver 31.

  In the virtual environment, there is a technique called live migration that moves the guest OS 2 operating on the operating server 1 to the server 1 of another virtual environment without stopping. With this technology, the server 1 on which the guest OS 2 operates can be changed while continuing to provide various services. Therefore, when the server 1 is heavily loaded, load distribution is achieved by moving the guest OS 2 to another server 1. Management with a higher degree of freedom is possible.

  When live migration is realized in the environment of the communication I / F library processing unit 23, the communication I / F driver 31, and the communication offload engine 5 according to the first embodiment, the communication ring queue 41 of the communication I / F driver 31; This can be dealt with by moving the session management table 52 in the communication offload engine 5 to the destination server 1. When the migration destination server 1 does not have the communication offload engine 5, the information of the session management table 52 is stored in the corresponding part of the protocol stack 25 that performs communication processing in the guest OS 2, and the communication ring queue 41, the communication buffer 42 is stored in the common memory 4 to realize live migration.

<< Second Embodiment >>
Next, a second embodiment of the present invention will be described with reference to FIGS.
[System configuration]
FIG. 20 is a diagram illustrating a configuration example of a virtual system according to the second embodiment. 20, the same components as those in FIG. 1 are denoted by the same reference numerals, description thereof is omitted, and differences from FIG. 1 are described.
The virtual system Za in FIG. 20 is different from the virtual system Z in FIG. 1 in that each guest OS 2 a has a protocol stack 25. The protocol stack 25 is an existing technology for performing communication processing.
The protocol stack 25 is realized by a program stored in the ROM 203 or the HDD 204 shown in FIG. 2 being expanded in the RAM 202 and executed by the CPU 201.

For example, when a communication function that is not registered in the switch variable management table 501 of FIG. 5 is executed, the communication I / F library processing unit 23 in the second embodiment performs communication processing via the existing protocol stack 25. . In other words, the communication I / F library processing unit 23 is an existing communication function that is not registered as a communication function for transmitting and receiving communication data via the communication ring queue 41 and the communication buffer 42. The communication processing is performed via the protocol stack 25.
However, the present invention is not limited to this, and the communication function to be communicated by the protocol stack 25 may be arbitrarily set by the user.
Note that the communication I / F driver 31a of the driver OS 3a can perform a RAW mode in which a communication process for a communication I / F packet and a communication function that has not been converted into a communication I / F packet are processed.

When the communication offload engine 5 receives a communication packet that is not registered in the switch variable management table 501 (non-compliant), the communication application 21 is notified in advance that the mode for non-compliant communication is taken, In this case, the communication offload engine 5 behaves as a normal network card. Then, the communication offload engine 5 transmits this communication data to the communication I / F driver 31 or an existing network 8 driver (not shown). The communication I / F driver 31 or the existing network card transmits communication data to the protocol stack 25, and the protocol stack 25 performs existing reception processing. Thereafter, the received communication data is transmitted to the communication application 211 via the communication I / F library processing unit 23 or an existing communication function I / F (not shown).
Note that the communication function registered in the switch variable management table 501 is also determined by the socket number for identifying the communication connection (communication connection) of the argument shown in FIG. You may make it process by. The communication connection is specified by, for example, a socket number, but is not limited thereto, and may be specified by a user or the like.

"flowchart"
(Communication I / F packet)
FIG. 21 is a flowchart illustrating a procedure of communication I / F packet generation processing according to the second embodiment.
After step S101 (FIG. 6), the communication I / F library processing unit 23 determines whether or not the communication function executed in step S101 is registered in the switch variable management table 501 shown in FIG. 5 (S101a). .
As a result of step S101a, when the executed communication function is registered in the switch variable management table 501 (S101a → Yes), the communication I / F library processing unit 23 performs the same processing as steps S102 to S105 of FIG. .
As a result of step S101a, when the executed communication function is not registered in the switch variable management table 501 (S101a → No), the existing protocol stack 25 processes the communication function (S102a). It should be noted that whether or not the existing protocol stack 25 processes the communication function based on the socket number for identifying the communication connection, rather than whether or not the communication function is registered in the switch variable management table 501. You may make it discriminate | determine.

(Summary of the second embodiment)
According to the second embodiment, it is not registered in the switch function management table, that is, communicates with the technology according to the first embodiment using a non-compliant communication function, a non-compliant protocol, or a non-compliant packet. Communication is possible even at times. Note that migration (live migration) during communication in the virtual system Z according to the second embodiment can be realized by transferring information of the protocol stack 25 on the guest OS 2 as well.

  In addition, according to the second embodiment, when communication is performed using an incompatible communication function, an incompatible protocol, an incompatible packet, or a specified communication connection, by switching processing to the existing protocol stack 25, Without changing the communication application 21 running on the guest OS 2 or using a new communication function, the communication I / F library processing unit 23, the communication I / F driver 31, and the communication offload engine according to the first embodiment. 5 can be used for communication.

1, 1a server (communication server)
2, 2a Guest OS
3, 3a Driver OS
4 Common memory (storage device)
5 Communication off-road engine (communication device)
6, 7 Hardware I / F
8 Network 9 Destination server (communication destination device)
10 Hypervisor (Processor)
21 Communication application 22, 24, 32 Software I / F
23 Communication I / F Library Processing Unit 25 Protocol Stack 31, 31a Communication I / F Driver 41 Communication Ring Queue (Second Storage Area)
42 Communication buffer (first storage area)
51 Protocol Stack Engine 52 Session Management Table 401 Socket Function 402 Communication I / F Packet (Communication Information)
501 Switch variable management table 701 Reception ring queue 702 Transmission ring queue 711 Transmission buffer 712 Reception buffer 901 Communication I / F switch processing unit 902 Interrupt processing unit (communication I / F driver)
911 Interrupt processing unit (communication offload engine)
Z, Za virtual system

Claims (10)

A communication method in a communication server having a processing device for executing a plurality of virtual OSs and further executing a driver OS for managing communication processing, a communication device as a device for performing communication, and a storage device Because
The storage device includes a first storage area for storing communication data, which is data to be communicated, and a second storage area for storing a memory address of the first storage area. Is set,
The driver OS is
Managing the memory address in the second storage area;
The virtual OS and the communication device are:
A communication method, wherein the communication data is read from and written to the first storage area with reference to a memory address stored in the second storage area. A plurality of the second storage areas are present and have cyclicity, and the second storage area in which the memory address is stored is information indicating whether or not the communication data is stored. Storage information is given,
The virtual OS and the communication device are:
The communication method according to claim 1, wherein the memory address is sequentially referred to from the second storage area to which the storage information is assigned. At the time of transmission of the communication data,
The virtual OS is
Executing a communication function for transmitting the communication data;
Storing the communication data in the first storage area;
Generating communication information including a memory address of a first storage area storing the communication data;
The driver OS is
Storing the memory address of the communication information in the second storage area;
The communication device
Obtaining the communication data from the first storage area indicated by the memory address stored in the second storage area;
The communication method according to claim 1 or 2, wherein the communication data is transmitted to a communication destination device. At the time of transmission of the communication data,
The driver OS is
Obtaining a memory address of a first storage area for storing the communication data;
Notifying the acquired memory address to the virtual OS,
The virtual OS is
Executing a communication function for transmitting the communication data;
Storing the communication data in the first storage area indicated by the notified memory address;
Generating communication information including a memory address of a first storage area storing the communication data;
The driver OS is
Storing the memory address of the communication information in the second storage area;
The communication device
Obtaining the communication data from the first storage area indicated by the memory address stored in the second storage area;
The communication method according to claim 1 or 2, wherein the communication data is transmitted to a communication destination device. At the time of transmission of the communication data,
The driver OS has acquired the memory address of the first storage area in advance,
The virtual OS is
Executing a communication function for transmitting the communication data;
Storing the communication data in a third storage area different from the first storage area and the second storage area;
Generating communication information including a memory address of the third storage area;
The driver OS is
When acquiring communication data from the third storage area based on the memory address in the communication information,
Based on the memory address of the first storage area acquired in advance, copy the acquired communication data to the first storage area,
The communication device
Obtaining the communication data from the first storage area indicated by the memory address stored in the second storage area;
The communication method according to claim 1 or 2, wherein the communication data is transmitted to a communication destination device. When receiving the communication data,
The virtual OS is
Executing the communication function with the memory address of the first storage area as an argument to receive the communication data;
Generating communication information including the memory address of the argument of the communication function;
The driver OS is
Storing the memory address in the communication information in the second storage area;
The communication device
Receiving the communication data from the communication destination device;
Storing the received communication data in the first storage area indicated by the memory address stored in the second storage area;
The driver OS is
When detecting that the communication data is stored in the second storage area,
Notifying the virtual OS that the communication data is stored in the first storage area,
The virtual OS that has received the notification
The communication method according to claim 1 or 2, wherein the communication data is acquired from the first storage area indicated by the memory address in an argument of the communication function. When receiving the communication data,
The virtual OS is
Obtaining a memory address of the first storage area for storing the communication data;
Generating communication information including the acquired memory address;
The driver OS is
Storing the memory address of the communication information in the second storage area;
The communication device
Receiving the communication data from the communication destination device;
Storing the received communication data in the first storage area indicated by the memory address stored in the second storage area;
The driver OS is
When detecting that the communication data is stored in the second storage area,
Notifying the virtual OS that the communication data is stored in the first storage area,
The virtual OS that has received the notification
The communication method according to claim 1 or 2, wherein the communication data is acquired from the first storage area indicated by the acquired memory address. When receiving the communication data,
The driver OS is
Obtaining a memory address of the first storage area in advance, storing the memory address in the second storage area;
The virtual OS is
Storing the communication data in a third storage area different from the first storage area and the second storage area;
Executing the communication function with the memory address of the third storage area as an argument;
Generating communication information having a memory address of a third storage area which is an argument of the communication function;
The communication device
Receiving the communication data from the communication destination device;
Storing the received communication data in the first storage area indicated by the memory address stored in the second storage area;
The driver OS is
When detecting that the communication data is stored in the second storage area,
Obtaining the communication data from the first storage area indicated by the memory address stored in the second storage area;
Copy the acquired communication data to the storage area indicated by the memory address of the third storage area in the communication information,
Notifying the virtual OS that the communication data is stored in the first storage area,
The virtual OS that has received the notification
The communication method according to claim 1, wherein the communication data is acquired from a storage area indicated by a memory address of the third storage area that is an argument of the communication function. The virtual OS is
A communication function that is not registered as a function for processing communication data via the first storage area and the second storage area, or a protocol stack for processing a specified communication connection is provided. The communication method according to any one of claims 1 to 8. A communication server including a processing device for executing a plurality of virtual OSs, and further executing a driver OS for managing communication processing, a communication device as a device for performing communication, and a storage device. ,
A storage device in which a first storage area for storing the communication data and a second storage area for storing a memory address of the first storage area are set;
The driver OS is
Managing the memory address in the second storage area;
The virtual OS and the communication device are:
The communication server reads / writes the communication data to / from the first storage area with reference to a memory address stored in the second storage area.

Images