A pipeline arbitration method and device supporting massive TCP connections
By reading and verifying the TCP status description table after arbitration, the problem of large memory bandwidth consumption in massive TCP connections is solved, the arbitration efficiency is improved, and more efficient packet transmission is achieved.
Patent Information
- Application Number
- CN202311617335.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-29
- Publication Date
- 2024-12-24
- Estimated Expiration
- 2043-11-29
AI Technical Summary
When maintaining massive TCP connections, the prior art requires frequent reading of TCP status description tables, resulting in large memory bandwidth consumption and increased latency, affecting arbitration efficiency.
The TCP connection is qualified by writing the doorbell register. After arbitration, the packet indicator and status description table are read and verified to avoid reading the status description table in the absence of unknown results, and to send packets only on the verification results.
Effectively reduce off-chip memory access, improve arbitration efficiency, and avoid valuable system bandwidth waste.
Smart Images
Figure CN117651025B_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the field of communication technology, and in particular relates to a pipeline arbitration method and device supporting massive TCP connections. Background Art
[0002] In the current computer communication protocols, TCP, as the most basic protocol of the Internet, provides connection-oriented reliable end-to-end communication. However, in the process of using the TCP protocol to handle network communication, the common practice is to use the operating system protocol stack to handle it. However, this processing will take up a lot of server resources. In order to reduce the pressure on the server, the TCP offload engine technology was proposed. The TCP offload engine is usually integrated in the network adapter. When sending a data packet of a TCP connection, it is necessary to check the status description table of the TCP connection, and determine whether the data packet of the current TCP connection can be sent through the information stored in the status description table, such as the send buffer size, send window size, and congestion window size.
[0003] When the TCP offload engine maintains a large number of TCP connections, it is difficult to ensure that the status information of all TCP connections is stored inside the offload engine. Generally, it is stored in an external memory, such as a system memory or an off-chip memory of the offload engine. The usual practice is that after the software notifies the TCP offload engine to transmit a data packet, the TCP offload engine first reads the data packet indicator and the TCP status description table of the TCP connection that needs to send a data packet to determine which TCP connection is allowed to send a data packet, and then arbitrates all the TCP connections that are allowed to send data packets, and finally determines the TCP connection that can send data packets.
[0004] The problem with this implementation is that if there are a large number of TCP connections, then before each arbitration, it is necessary to read the TCP state description table of all packets to be sent, which will cause the TCP offload engine to cache a large number of packet indicators and TCP state description tables, resulting in the consumption of very valuable memory bandwidth resources. In addition, a very large delay is introduced between two arbitrations. Summary of the invention
[0005] In view of the problems existing in the above background technology, the purpose of the present invention is to provide a pipeline arbitration method and device supporting massive TCP connections, which can significantly reduce the access to off-chip memory and improve arbitration efficiency.
[0006] The technical solution adopted by the present invention is:
[0007] A pipeline arbitration method supporting massive TCP connections, the specific steps of which are as follows:
[0008] S1, by writing the doorbell register, a TCP connection obtains arbitration qualification;
[0009] S2, arbitrates all TCP connections that need to send data packets;
[0010] S3, according to the arbitration result, read the corresponding TCP state description table and data packet indicator;
[0011] S4, confirming the validity of the data packet indicator read in step S3, if the data packet indicator is valid, proceeding to step S5;
[0012] S5, determining whether the TCP connection data packet can be sent based on the TCP status description table read in step S3, and if sending is allowed, proceeding to step S6;
[0013] S6, reading the TCP connection data packet according to the data packet indicator, and sending the data packet;
[0014] S7, after the TCP connection data packet is sent, the TCP state description table is updated and the corresponding data packet indicator is deleted. The present invention does not query the TCP state description table before arbitration, but reads and queries the TCP state description table after arbitration, and then reads and verifies the validity of the data packet indicator to determine whether the output result of the arbitration module is valid. The TCP transmission module only sends data packets for arbitration results that have been verified for validity. This method avoids reading the TCP state description table without knowing the arbitration result, wasting precious system bandwidth, thereby improving arbitration efficiency.
[0015] Furthermore, the specific steps of arbitration in step S2 include:
[0016] S21, selecting any arbitration mode to select one TCP connection from multiple TCP connections as the current TCP connection that can send data and performing arbitration;
[0017] S22, repeat step S21, and arbitrate all TCP connections that need to send data packets.
[0018] Further, in step S22, before all TCP connections are disqualified from arbitration, and the subsequent functional modules are able to receive the arbitration result, arbitration of the TCP connections can continue.
[0019] Furthermore, step S4 also includes: if the data packet indicator is invalid, discarding the arbitration result and canceling the arbitration qualification of the TCP connection.
[0020] Furthermore, the TCP connection whose arbitration qualification is cancelled in step S4 can regain arbitration qualification for the TCP connection by writing the doorbell register.
[0021] Furthermore, the sending conditions for allowing sending in step S5 include the remaining capacity of the sending buffer, the sending window size, and the congestion window size.
[0022] Furthermore, step S5 also includes: if sending is not allowed, discarding the current arbitration result.
[0023] A pipeline arbitration device supporting massive TCP connections, comprising:
[0024] The doorbell register is used to write to it to notify that there is a TCP connection that needs to send a data packet;
[0025] TCP send request vector table, used to record whether all TCP connections need to send data packets;
[0026] The arbitration module is used to arbitrate all TCP connections that need to send data packets and output the arbitration results;
[0027] A reading module, used for reading the corresponding data packet indicator and TCP state description table according to the arbitration result;
[0028] A validity check module, used for checking the validity of the data packet indicator read according to the arbitration result and the sending condition of the TCP state description table;
[0029] The transmission module is used to read data according to the data packet indicator for the TCP connection that has passed the validity check, create a TCP data packet in combination with the TCP state description table, and send it;
[0030] The post-processing module is used to update the TCP state description table and delete the corresponding data packet indicator after the data packet is sent.
[0031] Furthermore, it also includes: an arbitration result caching module, which is used to cache all arbitration results; when the arbitration result caching module cannot receive a new arbitration result, the arbitration module suspends arbitration until the arbitration result caching module can receive a new arbitration result again, and the arbitration module resumes arbitration.
[0032] Furthermore, the validity check module cancels the arbitration qualification of the TCP connection that fails to pass the data packet indicator validity check, and discards the arbitration result of the condition check that fails to pass the TCP state description table, but does not cancel the arbitration qualification of the TCP connection.
[0033] Compared with the prior art, the present invention has the following significant advantages: the TCP state description table is not queried before arbitration, but the TCP state description table is read and queried after arbitration, and then the validity of the data packet indicator is read and verified to determine whether the output result of the arbitration module is valid. The TCP transmission module only sends data packets for arbitration results that have been verified for validity. This method avoids reading the TCP state description table without knowing the arbitration result, which wastes precious system bandwidth, thereby improving arbitration efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] Figure 1 It is a flow chart of a pipeline arbitration method supporting massive TCP connections of the present invention;
[0035] Figure 2 It is a structural schematic diagram of a pipeline arbitration device supporting massive TCP connections of the present invention. DETAILED DESCRIPTION
[0036] The present invention is further described below in conjunction with specific embodiments, but the present invention is not limited to these specific embodiments. Those skilled in the art should recognize that the present invention covers all possible alternatives, improvements and equivalents within the scope of the claims.
[0037] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "clockwise", "counterclockwise" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first" and "second" are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, the meaning of "multiple" is two or more, unless otherwise clearly defined.
[0038] In the present invention, unless otherwise clearly specified and limited, the terms "installed", "connected", "connected", "fixed" and the like should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be an indirect connection through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.
[0039] In the present invention, unless otherwise clearly specified and limited, a first feature being "above" or "below" a second feature may include that the first and second features are in direct contact, or may include that the first and second features are not in direct contact but are in contact through another feature between them. Moreover, a first feature being "above", "above" and "above" a second feature includes that the first feature is directly above and obliquely above the second feature, or simply indicates that the first feature is higher in level than the second feature. A first feature being "below", "below" and "below" a second feature includes that the first feature is directly below and obliquely below the second feature, or simply indicates that the first feature is lower in level than the second feature.
[0040] Embodiment 1
[0041] See also Figure 1 This embodiment provides a pipeline arbitration method that supports massive TCP connections, and the specific steps are as follows:
[0042] S1, write the doorbell register through software to make a TCP connection obtain arbitration qualification;
[0043] S2, arbitrates all TCP connections that need to send data packets, without limiting the arbitration algorithm;
[0044] The specific steps of arbitration include:
[0045] S21, selecting any arbitration mode to select one TCP connection from multiple TCP connections as the current TCP connection that can send data and performing arbitration;
[0046] S22, repeating step S21, arbitrating all TCP connections that need to send data packets, before all TCP connections are disqualified from arbitration, and subsequent functional modules are able to receive arbitration results, and the arbitration of TCP connections can continue.
[0047] S3, according to the arbitration result, read the corresponding TCP state description table and data packet indicator; the arbitration result enters the arbitration result cache after the data packet indicator and state description table read request are sent. The function of the arbitration result cache is to temporarily store the arbitration result before the data packet indicator and state description table read are returned. When the data packet indicator and state description table read request are returned, the arbitration result is transmitted to the validity check module to perform data packet sending validity check.
[0048] S4, confirm the validity of the data packet indicator read in step S3. If the data packet indicator is valid, proceed to step S5; if the data packet indicator is invalid, discard the arbitration result and cancel the arbitration qualification of the TCP connection. The TCP connection whose arbitration qualification has been cancelled can regain arbitration qualification for the TCP connection by writing the doorbell register.
[0049] S5, the TCP state description table read in step S3 is used to determine whether the TCP connection data packet can be sent. If sending is allowed, step S6 is entered; the sending conditions for allowing sending include but are not limited to the remaining capacity of the sending buffer, the sending window size, and the congestion window size. If sending is not allowed, the current arbitration result is discarded.
[0050] S6, reading the TCP connection data packet according to the data packet indicator, and sending the data packet;
[0051] S7, after the TCP connection data packet is sent, the TCP state description table is updated and the corresponding data packet indicator is deleted. The TCP state description table may be updated by adjusting the sending window size, updating the TCP sequence number, etc.
[0052] The present invention will discard the arbitration result in two cases: the first is that the data packet indicator is invalid, indicating that the current sending request has been processed by the previous arbitration result, and the current arbitration result is only a false arbitration result caused by the advance of the arbitration module, and the arbitration result needs to be discarded. At the same time, since the current TCP connection has no data packets to be sent, the arbitration qualification of the TCP connection is cancelled, and the TCP sending request vector table is waited for to be reset. The second is that the data packet indicator is valid, but the TCP state description table shows that the sending of this data packet is not allowed at the current moment. In this case, the arbitration result is valid, but since the data packet of the current TCP connection is not allowed to be sent, in order not to affect the data packet sending of other TCP connections, the current arbitration result is temporarily discarded, and when the next arbitration result is the TCP connection, it is continued to check whether the data packet sending condition is met.
[0053] The present invention is mainly applied to the transmission of TCP messages, and of course, can also be applied to other messages that need to be transmitted.
[0054] The present invention does not query the TCP state description table before arbitration, but reads and queries the TCP state description table after arbitration, and then reads and verifies the validity of the data packet indicator to determine whether the output result of the arbitration module is valid. The TCP transmission module only sends data packets for arbitration results that have been verified for validity. This method avoids reading the TCP state description table without knowing the arbitration result, wasting precious system bandwidth, and thus improves arbitration efficiency.
[0055] Embodiment 2
[0056] See also Figure 2 ,This embodiment provides a pipeline arbitration device supporting massive TCP connections, including a doorbell register M11, a TCP send request vector table M12, an arbitration module M13, a reading module M14, an arbitration result cache M15, a validity check module M16, a transmission module M17 and a post-processing module M18.
[0057] The doorbell register M11 described in this embodiment is used to write to it through software to notify that a TCP connection needs to send a data packet. Writing the doorbell register by software will trigger the setting of the corresponding position of the TCP request vector table.
[0058] Specifically, the content of the doorbell register M11 can be the TCP connection number. Of course, the doorbell register can also be implemented so that each TCP connection occupies a doorbell register. The software writes one of the doorbell registers to indicate that the corresponding TCP connection has a data packet to send. In this case, the TCP send request vector table can be omitted, and the doorbell register M11 directly sends an arbitration request to the arbitration module.
[0059] The TCP sending request vector table M12 described in this embodiment is used to record whether all TCP connections need to send data packets. Each TCP connection corresponds to one bit, and if the bit is set high, it means that a data packet needs to be sent, and if the bit is set low, it means that no data packet needs to be sent.
[0060] Specifically, when the software writes the doorbell register M11, it triggers the corresponding bit in the vector table to be set to 1. When the data packet indicator read by the validity check module according to the arbitration result is invalid, it triggers the corresponding bit in the vector table to be cleared.
[0061] The arbitration module M13 described in this embodiment is used to arbitrate all TCP connections that need to send data packets and output the arbitration result. Of course, the arbitration module M13 can also directly receive the data packet sending request output from the doorbell register M11, perform arbitration, and output the arbitration result.
[0062] The reading module M14 described in this embodiment is used to read the corresponding data packet indicator and TCP state description table according to the arbitration result; specifically, the reading module M14 reads the data packet indicator and state description table of the TCP connection according to the arbitration result output by the arbitration module M13. After the data packet indicator and state description table read request are sent, the arbitration result enters the arbitration result cache. The function of the arbitration result cache is to temporarily store the arbitration result before the data packet indicator and state description table read are returned. When the data packet indicator and state description table read request are returned, the arbitration result is transmitted to the validity check module to perform a data packet sending validity check.
[0063] The arbitration result cache module M15 described in this embodiment is used to cache all arbitration results; when the arbitration result cache module M15 cannot receive a new arbitration result, the arbitration module M13 suspends arbitration until the arbitration result cache module M15 can receive a new arbitration result again, and the arbitration module M13 resumes arbitration.
[0064] The arbitration result cache receives the arbitration result and outputs the arbitration result when the validity check module returns the data packet indicator and the TCP state description table and is ready to perform the validity check of the arbitration result. The function of the arbitration result cache is that, since it takes a certain amount of time to read the data packet indicator and the TCP state description table, especially if both are stored in the host system memory, the arbitration result cache module can store all arbitration results from the issuance of the read request to the read return.
[0065] The validity check module M16 described in this embodiment is used to check the validity of the data packet indicator read according to the arbitration result and the sending condition of the TCP state description table.
[0066] Specifically, the validity check module first performs a validity check on the data packet indicator. If it is invalid, the arbitration result is discarded and the arbitration qualification of the TCP connection is cancelled. If it is valid, the sending condition check of the TCP state description table is performed. Under normal conditions, this check mainly checks whether the current data packet can be sent at the TCP protocol layer. For arbitration results that do not pass the TCP state description table sending condition check, the arbitration result is directly discarded, but the arbitration qualification of the TCP connection is not cancelled.
[0067] The sending condition check of the TCP status description table is not limited to the sending condition check at the TCP protocol level, but can also include TCP and lower-level service quality assurance checks, sending packet buffer size checks, and so on.
[0068] The transmission module M17 described in this embodiment is used to read data according to the data packet indicator for the TCP connection that has passed the validity check, create a TCP data packet in combination with the TCP state description table, and send it.
[0069] The post-processing module M18 in this embodiment is used to update the TCP state description table and delete the corresponding data packet indicator after the data packet is sent.
[0070] The present invention is mainly applied to network devices. Of course, it can also be applied to various terminal devices, such as mobile terminals such as mobile phones and tablets, and computer devices such as personal computers and portable computers.
[0071] The present invention does not query the TCP state description table before arbitration, but reads and queries the TCP state description table after arbitration, and then reads and verifies the validity of the data packet indicator to determine whether the output result of the arbitration module is valid. The TCP transmission module only sends data packets for arbitration results that have been verified for validity. This method avoids reading the TCP state description table without knowing the arbitration result, wasting precious system bandwidth, and thus improves arbitration efficiency.
Claims
1. A pipeline arbitration method supporting massive TCP connections, the specific steps of which are as follows: S1, by writing the doorbell register, a TCP connection obtains arbitration qualification; S2, arbitrates all TCP connections that need to send data packets; S3, according to the arbitration result, read the corresponding TCP state description table and data packet indicator; S4, confirming the validity of the data packet indicator read in step S3, if the data packet indicator is valid, proceeding to step S5; S5, determining whether the TCP connection data packet can be sent based on the TCP status description table read in step S3, and if sending is allowed, proceeding to step S6; S6, reading the TCP connection data packet according to the data packet indicator, and sending the data packet; S7, after the TCP connection data packet is sent, the TCP state description table is updated and the corresponding data packet indicator is deleted.
2. A pipeline arbitration method supporting massive TCP connections according to claim 1, characterized in that: The specific steps of arbitration in step S2 include: S21, selecting any arbitration mode to select one TCP connection from multiple TCP connections as the TCP connection that can currently send data and performing arbitration; S22, repeat step S21, and arbitrate all TCP connections that need to send data packets.
3. A pipeline arbitration method supporting massive TCP connections according to claim 2, characterized in that: In step S22, before all TCP connections are disqualified from arbitration, and the subsequent functional modules are able to receive the arbitration results, arbitration of the TCP connections can continue.
4. The pipeline arbitration method supporting massive TCP connections according to claim 1, characterized in that: Step S4 also includes: if the data packet indicator is invalid, discarding the arbitration result and canceling the arbitration qualification of the TCP connection.
5. A pipeline arbitration method supporting massive TCP connections according to claim 4, characterized in that: The TCP connection whose arbitration qualification is cancelled in step S4 can regain arbitration qualification for the TCP connection by writing the doorbell register.
6. The pipeline arbitration method supporting massive TCP connections according to claim 1, characterized in that: The sending conditions for allowing sending in step S5 include the remaining capacity of the sending buffer, the sending window size, and the congestion window size.
7. A pipeline arbitration method supporting massive TCP connections according to claim 6, characterized in that: Step S5 also includes: if sending is not allowed, discarding the current arbitration result.
8. A pipeline arbitration device supporting massive TCP connections, characterized in that: include: The doorbell register is used to write to it to notify that there is a TCP connection that needs to send a data packet; TCP send request vector table, used to record whether all TCP connections need to send data packets; The arbitration module is used to arbitrate all TCP connections that need to send data packets and output the arbitration results; A reading module, used for reading the corresponding data packet indicator and TCP state description table according to the arbitration result; A validity check module, used for checking the validity of the data packet indicator read according to the arbitration result and the sending condition of the TCP state description table; The transmission module is used to read data according to the data packet indicator for the TCP connection that has passed the validity check, create a TCP data packet in combination with the TCP state description table, and send it; The post-processing module is used to update the TCP state description table and delete the corresponding data packet indicator after the data packet is sent.
9. A pipeline arbitration device supporting massive TCP connections according to claim 8, characterized in that: Also includes: Arbitration result cache module, used to cache all arbitration results; When the arbitration result cache module cannot receive a new arbitration result, the arbitration module suspends arbitration until the arbitration result cache module can receive a new arbitration result again, and then the arbitration module resumes arbitration.
10. The pipeline arbitration device supporting massive TCP connections according to claim 8, characterized in that: The validity check module cancels the arbitration qualification of the TCP connection that fails to pass the data packet indicator validity check, and discards the arbitration result of the arbitration result that fails to pass the TCP state description table sending condition check, but does not cancel the arbitration qualification of the TCP connection.