Toe acceleration system for improving application network performance

Abstract

The application discloses a TOE acceleration system for improving application network performance, which comprises an interface replacement module, a TOE network driver and a TOE network card device; the interface replacement module is used for judging whether a data receiving / sending related interface needs to be subjected to TCP uninstallation; for the interface needing TOE processing, the interface replacement module enters the TOE network driver for corresponding processing, otherwise, the interface replacement module enters a kernel protocol stack according to a function original path; the TOE network driver is used for processing a receiving / sending command issued by the interface replacement module, maintaining a corresponding sending / receiving task queue and controlling the TOE network card device to complete corresponding operation; the TOE network card device is arranged in an FPGA, and the TOE network card device is used for processing protocol work involved in a receiving / sending data packet process. The TOE acceleration system for improving application network performance can be quickly deployed without modifying an operating system kernel, and can be conveniently and quickly used for TOE acceleration network transmission in various application programs based on a TCP socket, so that the network performance of the application is improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of network, and particularly relates to a TOE acceleration system for improving application network performance. BACKGROUND

[0002] The rapid increase of data volume brought by the accelerated innovation of modern science and technology runs through various aspects of daily life and work, and puts forward higher requirements for data transmission bandwidth. Ethernet is the most widely used data transmission network at present. In Ethernet communication, the processing of the network protocol stack is usually completed by CPU. With the continuous increase of network transmission bandwidth, the resource consumption of the processor is increasingly serious, and gradually becomes a bottleneck in high-speed network transmission.

[0003] TCP protocol offload engine (TOE) technology offloads the processing work of the network protocol stack from CPU to a special processing unit such as a network card (NIC), FPGA, ASIC, etc., to reduce CPU occupation and bypass the operating system, thereby simplifying the processing path of the network protocol and relieving the pressure of the processor. It is an important direction in the research of TCP acceleration technology.

[0004] The mainstream TOE technology can be divided into Chimney TOE and Full Offload TOE. The former is a semi-offload technology, which only offloads the data transmission path that consumes the most CPU resources, and the functions such as connection establishment and disconnection maintenance are still processed by the operating system kernel. The latter needs to completely implement the functions required by the entire network protocol stack by hardware. Compared with the full offload mode, the semi-offload mode has smaller design difficulty and better compatibility with upper application programs.

[0005] At present, the Linux operating system does not provide good support and specifications for TOE technology. Compared with the general Linux TCP / IP protocol stack, various TOE solutions are all proprietary, the actual deployment is relatively complex, and the support for application programs is also very limited. Moreover, most TOE solutions need to modify the network protocol stack source code, which has certain risks to the stability and inheritability of the system. Therefore, how to quickly deploy without modifying the operating system kernel and how to use TOE to accelerate network transmission conveniently and quickly in the application program have become a problem that needs to be solved urgently, and have important significance in the field of network technology. SUMMARY

[0006] The application provides a TOE acceleration system for improving application network performance to solve the above technical problems, and specifically adopts the following technical scheme:

[0007] A TOE acceleration system for improving application network performance, comprising: an interface replacement module, a TOE network driver and a TOE network card device;

[0008] The interface replacement module is arranged in the user mode of the host, and is used for judging whether a data transceiving related interface needs to be subjected to TCP offloading, and entering the TOE network driver for corresponding processing if TOE processing is needed, or entering a kernel protocol stack for system call according to a function original path if not;

[0009] The TOE network driver is arranged in the kernel mode of the host, and is used for processing a transceiving command issued by the interface replacement module, maintaining a corresponding sending / receiving task queue, and controlling the TOE network card device to complete corresponding operations;

[0010] The TOE network card device is arranged in an FPGA, and is used for processing protocol work involved in a data transceiving message process.

[0011] Further, the interface replacement module replaces a socket interface related to data transceiving in an application program through a hook function.

[0012] Further, the protocol work processed by the TOE network card device includes out-of-order transmission, timer management, flow control and congestion control, and protocol encapsulation and analysis.

[0013] Further, the TOE network driver interacts with the TOE network card device through registers and interrupts, completes sending / receiving task control, bypasses message transmission and configures hardware states.

[0014] Further, the interface replacement module acquires a local IP address according to a socket handle of an interface parameter, and queries a virtual network port IP hash table generated by the TOE network driver, so as to judge whether TCP offloading needs to be called.

[0015] Further, the TOE network driver controls data transceiving of the TOE network card device based on a task command instead of a TCP message, as follows:

[0016] A sending / receiving circular task queue is arranged in the TOE network card device for each TCP connection;

[0017] Each time a data sending interface is called, it is regarded as issuing a sending command to a hardware sending task queue, and the command contains a data address and a length;

[0018] Each time a data receiving interface is called, corresponding length data is read from a receiving buffer composed of a plurality of receiving commands.

[0019] Further, the TOE network driver comprises a hardware configuration unit, a bypass processing unit and a data transceiving unit;

[0020] The hardware configuration unit initializes the TOE network card device when the driver is mounted, including register region mapping, virtual network port configuration, interrupt management and FPGA hardware logic initialization configuration.

[0021] The bypass processing unit is used for processing low-speed protocol packets that do not need TCP offloading by the kernel protocol stack, and sending packets that need to be sent by the kernel protocol stack to the TOE network card device through the hardware configuration unit. The bypass processing unit maintains TCP connection state synchronization to correctly configure the hardware of the TOE network card device at different stages, and performs ARP response analysis to update and maintain the ARP table in the TOE network card device.

[0022] The data transceiving unit is used for processing commands sent by the interface replacement module, and maintains a 256-length sending / receiving circular task queue in the TOE network card device. The physical address and length of the data to be sent are written into the sending task queue through the command register, and the network card hardware logic tries to complete the commands in the sending queue in order. When data is received, the network card hardware logic will sequentially put the data into the address specified by the command in the receiving task queue.

[0023] Further, the method for processing the sending-related interface by the data transceiving unit is as follows:

[0024] S200: preprocessing, judging whether the connection information is normal and the sending size is less than the sending buffer;

[0025] S201: after the preprocessing passes the requirements, the sending queue is actively maintained once, and the completed commands are cleaned up;

[0026] S202: the remaining size of the buffer is calculated, and the head and tail offset address and size of the sending task queue maintained in the driver are combined with the total size of the buffer to calculate. When the remaining size of the buffer is greater than the size of the data to be sent, S203 is entered, otherwise if the sending option is set to non-blocking, an error is returned directly;

[0027] S203: the application data is copied to the corresponding address of the sending buffer, and when zero-copy is set, S203 is skipped and the data address is verified;

[0028] S204: the data address and size are written into the sending queue of the TOE network card device through the hardware configuration unit, and the sending queue simulated in the driver is synchronously maintained.

[0029] Further, the method for processing the receiving interface of the data transceiving unit is:

[0030] S210: preprocessing, judging whether the connection information is normal, when the receiving option is set as MSG_WAITALL, it is also needed to judge whether the size of this time receiving is less than the maximum value that can be used for receiving, i.e. the total receiving buffer size minus the confirmed unreleased part;

[0031] S211: calculating the size of the received data in the receiving buffer according to the receiving window calculation mode, when the received size is greater than the size of this time receiving command, or the receiving size is greater than 0 and the MSG_WAITALL option is not set, entering the step S212, when the receiving size is zero and the connection is disconnected or the receiving is in the non-blocking mode, exiting the receiving and returning the corresponding error value, when it is in the blocking mode, continuing to repeat the step S211 to calculate the received data size until the exit condition is met;

[0032] S212: copying the received data in the receiving buffer to the application specified address, when it is set as zero copy, skipping the step S212 and verifying whether the data address is correct;

[0033] S213: maintaining the receiving window, right shifting the left boundary of the receiving buffer, if the left boundary crosses one or more receiving commands, then writing the corresponding number of receiving commands to the TOE network card device to keep the buffer size unchanged.

[0034] Further, a plurality of addresses of continuous equal length receiving commands are spliced as the receiving buffer to simulate the traditional TCP receiving window, and the receiving window is dynamically maintained at each time of reading out data, and the data from the transmission network is put into the specified receiving buffer address by the TOE network card device.

[0035] The TOE acceleration system for improving the network performance of the application has the advantages that it can be quickly deployed without modifying the operating system kernel, and can be conveniently and quickly used in various application programs based on TCP socket to improve the network performance of the application.

[0036] The TOE acceleration system for improving the network performance of the application also has the advantages that the network data transceiving is managed by using the network card driver software, and the control ability of the kernel protocol stack for TCP connection establishment and disconnection is reserved, so that the application program can use the normal socket interface to manage the TCP connection.

[0037] The advantages of this invention also lie in the TOE acceleration system provided for improving application network performance. It offloads the TCP protocol processing related to data transmission path to the TOE network card hardware and uses FPGA logic for processing. This not only helps to maximize the high-speed transmission performance of the network card, increase network transmission bandwidth, and reduce transmission latency, but also significantly reduces CPU utilization and alleviates processor pressure. Attached Figure Description

[0038] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a schematic diagram of the TOE acceleration system of the present invention for improving application network performance;

[0040] Figure 2 This is a schematic diagram of the internal structure of the TOE network driver of the present invention;

[0041] Figure 3a A flowchart illustrating the steps of calling a data sending interface according to an embodiment of the present invention;

[0042] Figure 3b A flowchart illustrating the steps of calling the data receiving interface according to another embodiment of the present invention;

[0043] Figure 4 This is a schematic diagram illustrating the implementation of the receiving window in this invention. Detailed Implementation

[0044] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0045] like Figure 1 The diagram shows a TOE acceleration system for improving application network performance, comprising: an interface replacement module, a TOE network driver, and a TOE network card device.

[0046] The interface replacement module is configured in user space on the Linux host. This module determines whether TCP offloading is required for interfaces related to sending and receiving data. If TOE processing is needed, it enters the TOE network driver for appropriate handling; otherwise, it performs a system call along the original function path to enter the kernel protocol stack.

[0047] Specifically, the interface replacement module includes two parts of driver opening and interface transmission.

[0048] Driver opening: a static variable is set to represent the handle of the driver, the driver is opened at the first time of mobilizing the interface, the handle is saved, and the IP addresses of all TOE ports on the local machine are detected and saved in a hash table.

[0049] Interface transmission: first, the source IP is obtained through the socket handle, if found in the hash table, the function parameters are packaged, the TOE network driver corresponding interface is called through the ioctl function, otherwise, the source path enters the system call. The interfaces include recv, send, writev, sendfile, epoll_create, epoll_ctl, epoll_wait, etc. In addition, in order to achieve zero-copy feature, get_recv_addr, get_send_addr and other custom interfaces are added to obtain the address and length of the network card data buffer.

[0050] The TOE network driver is set in the kernel state of the Linux host. The TOE network driver is used to process the transmission and reception commands issued by the interface replacement module, maintain the corresponding sending / receiving task queue, and control the TOE network card device to complete the corresponding operation. The interface replacement module and the TOE network driver program communicate with each other using the ioctl function call.

[0051] The TOE network card device is set in the FPGA and is completed by FPGA hardware logic. The TOE network card device is used to process the protocol work involved in the process of transmitting and receiving data packets, including out-of-order transmission, timer management, flow control and congestion control, and protocol encapsulation and analysis. Among them, the TOE network card device uses a TCP work module to uniformly manage all TCP connections, and separates the information related to the TCP connection for caching, achieving high resource utilization of multi-TCP connection concurrent transmission and improving the scalability of the system.

[0052] In the embodiments of the present application, the TOE network driver interacts with the TOE network card device through registers and interrupts, completes the control of the sending / receiving task, bypasses the transmission of the message, and configures the hardware state.

[0053] In the embodiments of the present application, the interface replacement module replaces the socket interface related to data transceiving in the application program through a hook function. Specifically, the replaced data transceiving related API interface includes but is not limited to recv, send, writev, readv, sendfile, and the interface replacement module acquires the local IP address according to the socket handle of the interface parameter, queries in the virtual network port IP hash table generated by the TOE network driver, and judges whether the TCP offload needs to be called to implement the TOE network driver.

[0054] In the embodiments of the present application, the TOE network driver controls the data transceiving of the TOE network card device based on the task command instead of the TCP packet, as follows:

[0055] A sending / receiving circular task queue is set for each TCP connection in the TOE network card device.

[0056] Each time the data sending interface is called, it is regarded as issuing a sending command to the hardware sending task queue, and the command contains the data address and length.

[0057] Each time the data receiving interface is called, the corresponding length of data is read from the receiving buffer composed of a plurality of receiving commands.

[0058] As shown in FIG. 1, in the embodiments of the present application, the TOE network driver includes a hardware configuration unit, a bypass processing unit and a data transceiving unit. Figure 2

[0059] The hardware configuration unit initializes the TOE network card device when the driver is mounted, including register region mapping, virtual network port configuration, interrupt management, and FPGA hardware logic initialization configuration. The hardware configuration unit also serves as a bridge for interacting with the hardware, and assists other units in the network driver to complete the corresponding functions.

[0060] The bypass processing unit is used to process the low-speed protocol packet which does not need TCP offload by the kernel protocol stack, and sends the packet which needs to be sent by the kernel protocol stack to the TOE network card device through the hardware configuration unit. The bypass processing unit maintains the TCP connection state synchronization to correctly configure the TOE network card device hardware in different stages, and analyzes the ARP response to update and maintain the ARP table in the TOE network card device.

[0061] ​The bypass processing unit needs to process the packet according to the packet type. Specifically, for the SYN, FIN, RST and other packets of TCP in the connection establishment and disconnection stage, a TCP connection state is synchronously maintained in the driver before being delivered to the kernel for processing, so as to correctly configure the TOE network card device hardware in different stages. It should be noted that since the data transmission process in the middle after the connection is established is offloaded by the TOE, the SEQ and ACK sequence numbers maintained by the kernel at this time are quite different from the actual transmission situation. In order to enable the TCP packets related to connection disconnection to be correctly recognized by the kernel, the SEQ and ACK fields of the packets need to be recorded and modified, and the checksum needs to be modified synchronously to verify the correctness. In addition, when the bypass processing unit receives an ARP response, the packet needs to be parsed and the ARP table in the TOE network card device needs to be maintained.

[0062] The data transceiver unit is used to process the commands sent by the interface replacement module. The data transceiver unit maintains a 256-length sending / receiving circular task queue in the TOE network card device. The physical address and length of the data to be sent are written into the sending task queue through the command register. The network card hardware logic tries to complete the commands in the sending queue in order. When receiving data, the network card hardware logic will sequentially put the data into the address specified by the command in the receiving task queue.

[0063] Specifically, the application program calls the data sending related socket interface, performs interface replacement through the hook function, judges whether TCP offloading is needed according to the IP address corresponding to the socket handle, and if needed, enters the TOE network driver corresponding interface through the ioctl function. Next, as shown in the following Figure 3a In the embodiment of the present application, the method for the data transceiver unit to process the sending related interface is as follows:

[0064] S200: preprocessing, judging whether the connection information is normal and the sending size is less than the sending buffer.

[0065] S201: after the preprocessing passes the requirements, the sending queue is actively maintained, and the completed commands are cleaned. The number of completed sending commands in this period of time is obtained by calculating the difference between the two times of tail of the sending task queue related register, and the simulated sending task queue in the driver is maintained according to the number, so as to keep consistent with the circular queue in the TOE network card device hardware.

[0066] S202: calculating the remaining size of the buffer, combining the head and tail offset address and size of the sending task queue maintained in the driver with the total size of the buffer to calculate, when the remaining size of the buffer is greater than the size of the data to be sent, entering S203, otherwise if the sending option is set to non-blocking, directly returning an error.

[0067] S203: Copy the application data to the sending buffer corresponding address, when set to zero copy, skip S203 step and check if the data address is correct.

[0068] S204: Write the data address and size to the sending queue of the TOE network card device through the hardware configuration unit, and synchronously maintain the simulated sending queue in the driver.

[0069] The application program calls the data receiving related socket interface, replaces the interface through the hook function, judges whether TCP offloading is needed according to the IP address corresponding to the socket handle, and if needed, enters the interface of the TOE network driver through the ioctl function. Next, as shown in Figure 3b In the embodiments of the present application, the method for processing the receiving related interface by the data transceiving unit is as follows:

[0070] S210: Preprocessing, judging whether the connection information is normal, when the receiving option is set to MSG_WAITALL, it is also needed to judge whether the size of this time receiving is less than the maximum value that can be used for receiving, that is, the total receiving buffer size minus the confirmed unreleased part.

[0071] S211: Calculate the size of the received data in the receiving buffer according to the receiving window calculation method, when the received size is greater than the size of this time receiving command, or the receiving size is greater than 0 and the MSG_WAITALL option is not set, enter S212 step, when the receiving size is zero and the connection is disconnected or the receiving is in the non-blocking mode, exit the receiving and return the corresponding error value, when in the blocking mode, continue to repeat S211 step to calculate the received data size until the exit condition is met.

[0072] S212: Copy the received data in the receiving buffer to the application specified address, when set to zero copy, skip S212 step and check if the data address is correct.

[0073] S213: Maintain the receiving window, right shift the left boundary of the receiving buffer, if the left boundary crosses one or more receiving commands, write the corresponding number of receiving commands to the TOE network card device to keep the buffer size unchanged.

[0074] In the embodiments of the present application, a plurality of equal-length receiving commands with continuous addresses are spliced as a receiving buffer to simulate the traditional TCP receiving window, and the receiving window is dynamically maintained at each time of reading out data, and the data from the transmission network is put into the specified receiving buffer address by the TOE network card device.

[0075] As shown in Figure 4The description shows the calculation and processing of the receiving window in the data transceiving unit processing receiving related interface flowchart, and specifically explains the calculation and adjustment method of the receiving window in steps S210, S211 and S213.

[0076] In the embodiments of the present application, the receiving window is a ring-shaped task queue spliced by a plurality of address-continuous and equal-length receiving commands. In order to facilitate understanding, Figure 4 The ring-shaped task queue is horizontalized, and the number of receiving commands is specialized as 64.

[0077] Specifically, Figure 4 In the formula, rwq represents the receiving task queue, rwq_tail, rwq_cur and rwq_head are three pointers of the receiving task queue, the task command is increased from rwq_head, rwq_tail is deleted, and rwq_cur represents the command being executed for receiving. The area ACKED represents the part that has been confirmed in TCP and received by the application program, ACKED NOT RECEIVED represents the part that has been confirmed but not received by the application program, and NOT ACKED represents the part remaining in the buffer.

[0078] In Figure 4 In the formula, area ① is part of ACKED, recording the received part in the tail of rwq_tail, represented by tail_rwq_recv_done. Areas ② and ③ are both parts that have been confirmed but not received by the application program, in which ③ represents the part that has been confirmed in rwq_cur, represented by cur_rwq_recv_done. tail_rwq_recv_done and cur_rwq_recv_done can be zero, and rwq_tail can be equal to rwq_cur. When rwq_tail = rwq_cur, it always satisfies cur_rwq_recv_done > tail_rwq_recv_done.

[0079] Area ② is the size of the received data in the receiving buffer that needs to be calculated in step S211, which is (rwq_cur-rwq_tail)*rwq_size+cur_rwq_recv_done-tail_rwq_recv_done.

[0080] Area ④ is the size of the remaining receiving buffer that needs to be calculated in step S210, which is (rwq_head-rwq_cur)*rwq_size-cur_rwq_recv_done.

[0081] It should be noted that the rwq is a circular queue, so the difference of the rwq pointer in the above two formulas can be negative, and 256 should be added and then the remainder of 256 should be taken to ensure that the difference is positive.

[0082] In the S213 step, the left boundary of the receiving buffer is right shifted to maintain the size of the receiving buffer, that is, the rwq_tail pointer in the above formula is right shifted, and the value of this pointer is maintained by the driver software and is not the same as the value in the actual TOE network card device, because in the hardware logic, the value of the rwq_tail is automatically right shifted after the ACK confirmation, and the actual receiving interface needs to be called by the application software to receive and then modified. Figure 4

[0083] Preferably, a plurality of registers related to the receiving window can be added to simplify the CPU calculation.

[0084] The basic principles, main features and advantages of the present application are shown and described above. Those skilled in the art should understand that the above examples do not limit the present application in any form, and any technical solutions obtained by equivalent replacement or equivalent transformation fall within the protection scope of the present application.​

Claims

1. A TOE acceleration system for improving application network performance, characterized in that, Includes: interface replacement module, TOE network driver, and TOE network card device; The interface replacement module is set in the user space of the host. The interface replacement module is used to determine whether the interfaces related to sending and receiving data need to be TCP offloaded. If TOE processing is required, the TOE network driver is entered to perform the corresponding processing. Otherwise, the system call is performed according to the original function path to enter the kernel protocol stack. The TOE network driver is set in the kernel mode of the host. The TOE network driver is used to process the send and receive commands issued by the interface replacement module, maintain the corresponding send / receive task queue, and control the TOE network card device to complete the corresponding operations. The TOE network card device is installed in the FPGA and is used to handle the protocol work involved in the process of sending and receiving data packets. The TOE network driver controls the data transmission and reception of the TOE network card device based on task commands rather than TCP packets, as follows: In the TOE network card device, a send / receive circular task queue is set up for each TCP connection; Each call to the data sending interface is regarded as issuing a send command to the hardware send task queue. The command contains the data address and length. Each time the data receiving interface is called, data of the corresponding length is read from the receive buffer, which is composed of several receive commands. The TOE network driver includes a hardware configuration unit, a bypass processing unit, and a data transceiver unit. The hardware configuration unit initializes the TOE network card device when the driver is mounted, including register area mapping, virtual network port configuration, interrupt management, and FPGA hardware logic initialization configuration. The bypass processing unit is used to hand over low-speed protocol messages that do not require TCP offloading to the kernel protocol stack for processing, and at the same time send the messages that the kernel protocol stack needs to send to the TOE network card device through the hardware configuration unit. The bypass processing unit performs TCP connection state synchronization maintenance to correctly configure the hardware of the TOE network card device at different stages. The bypass processing unit performs ARP reply parsing to update and maintain the ARP table inside the TOE network card device. The data transceiver unit is used to process commands sent by the interface replacement module. The data transceiver unit maintains a 256-length transmit / receive ring task queue in the TOE network card device. The physical address and length of the data to be transmitted are written into the transmit task queue through the command register. The network card hardware logic attempts to complete the commands in the transmit queue in sequence. When data is received, the network card hardware logic will put the data into the address specified by the command in the receive task queue in sequence.

2. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The interface replacement module replaces the socket interfaces for data sending and receiving in the application through hook functions.

3. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The protocol processing functions of the TOE network card device include out-of-order transmission, timer management, flow control, congestion control, and protocol encapsulation and parsing.

4. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The TOE network driver interacts with the TOE network card device through registers and interrupts to control the sending / receiving tasks, pass-through of bypass messages, and configure hardware status.

5. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The interface replacement module obtains the local IP address based on the socket handle of the interface parameters and queries the virtual network port IP hash table generated by the TOE network driver to determine whether it is necessary to call the TOE network driver to implement TCP offloading.

6. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The method for the data transceiver unit to process the sending-related interfaces is as follows: S200: Preprocessing, determining whether the connection information is normal and whether the sending size is less than the sending buffer; S201: After preprocessing meets the requirements, actively maintain the sending queue once and clean up completed commands; S202: Calculate the remaining size of the buffer by combining the head and tail offset addresses and sizes of the send task queue maintained in the driver with the total size of the buffer. If the remaining size of the buffer is greater than the size of the data to be sent, proceed to S203; otherwise, if the send option is set to non-blocking, return an error directly. S203: Copy the application data to the corresponding address in the send buffer. When zero copy is set, skip step S203 and verify whether the data address is correct. S204: The data address and size are written into the transmission queue of the TOE network card device through the hardware configuration unit, and the simulated transmission queue in the driver is maintained synchronously.

7. The TOE acceleration system for improving application network performance according to claim 1, characterized in that, The method for the data transceiver unit to process the receive-related interfaces is as follows: S210: Preprocessing, determining whether the connection information is normal. When the receive option is set to MSG_WAITALL, it is also necessary to determine whether the size of this receive is less than the maximum value that can be used for receiving, that is, the total receive buffer size minus the confirmed but not released portion. S211: Calculate the size of the received data in the receive buffer according to the receive window calculation method. If the received size is greater than the size of this receive command, or the received size is greater than 0 and the MSG_WAITALL option is not set, proceed to step S212. If the received size is zero and the connection is broken or the receive is in non-blocking mode, exit the receive and return the corresponding error value. If it is in blocking mode, continue to repeat step S211 to calculate the size of the received data until the exit condition is met. S212: Copy the received data in the receive buffer to the address specified by the application. When zero copy is set, skip step S212 and check whether the data address is correct. S213: Maintain the receiving window, move the left boundary of the receiving buffer to the right. If the left boundary crosses one or more receiving commands, write the corresponding number of receiving commands to the TOE network card device to keep the buffer size unchanged.

8. The TOE acceleration system for improving application network performance according to claim 7, characterized in that, Multiple consecutive equal-length receive commands are concatenated to form a receive buffer to simulate a traditional TCP receive window. The receive window is dynamically maintained each time data is read, and the TOE network card device puts the data from the transmission network into the specified receive buffer address.

Images