Multi-source data stream order preserving method and device

Abstract

The invention provides a multi-source data stream order preserving method and device, and the method comprises the steps: determining a first source data stream of a first data message in response to a receiving request of the first data message; the first source data stream corresponds to one of the following three order-preserving types: an irrelevant data stream without an order-preserving correlation requirement, a data stream to be subjected to order-preserving with an order-preserving requirement and a relevant data stream influencing the order-preserving of the data stream to be subjected to order-preserving; if the order preserving type corresponding to the first source data stream of the first data message is a data stream to be subjected to order preserving, obtaining a public counter value corresponding to a related data stream influencing the order preserving of the first data message; setting a latch counter value corresponding to the first data message as the common counter value; and when the latch counter value of the first data message is not 0, setting the first data message to be not allowed to be sent. According to the technical scheme, the hardware overhead is saved, and the performance is improved.

Description

Technical Field

[0001] This application belongs to the field of chip technology, and particularly relates to a method and device for preserving the order of multi-source data streams. Background Art

[0002] As the complexity of chip systems increases, the correlation processing between multi-source data streams becomes particularly important. Some data stream processing has little impact on the performance of the system, while some is particularly important in system processing as it needs to meet both performance requirements and the constraints of correlation processing.

[0003] Related technologies usually adopt an order-preserving processing method that restricts software interfaces or uses hardware timestamps. The order-preserving method that restricts software interfaces has a certain impact on the flexibility and generality of use. This method generally requires compiler tool support for parsing, which has constraints on application scenarios and will inevitably increase the delay in data stream processing. The order-preserving processing method using hardware timestamps has certain limitations on order-preserving performance, the designed bit width of timestamps, and the corresponding timestamp overflow time. Summary of the Invention

[0004] The purpose of this application is to provide a method and device for preserving the order of multi-source data streams, aiming to solve the technical problems of high hardware resource consumption, impact on data stream bandwidth, and delay in the order-preserving scheme of related technologies.

[0005] According to the first aspect of this application, a method for preserving the order of multi-source data streams is provided, including:

[0006] In response to a reception request for a first data packet, determining the first source data stream of the first data packet; the first source data stream corresponds to one of the following three order-preserving types: an irrelevant data stream with no order-preserving correlation requirement, an order-preserving data stream to be order-preserved, and a related data stream that affects the order-preservation of the order-preserving data stream;

[0007] If the order-preserving type corresponding to the first source data stream of the first data packet is an order-preserving data stream to be order-preserved, obtaining the common counter value corresponding to the related data stream that affects the order-preservation of the first data packet;

[0008] Setting the latch counter value corresponding to the first data packet to the common counter value;

[0009] When the latch counter value of the first data packet is not 0, setting the first data packet as not allowed to be sent.

[0010] In an alternative embodiment, after determining the first source data stream of the first data packet, the method further includes:

[0011] If the in-sequence type corresponding to the first source data stream of the first data packet is a related data stream, increment the common counter value corresponding to the first source data stream by 1.

[0012] In an alternative embodiment, the method further includes:

[0013] In response to a transmission request for a second data packet, determine the second source data stream of the second data packet;

[0014] If the in-sequence type corresponding to the second source data stream is a related data stream, decrement the common counter value corresponding to the second source data stream by 1, and decrement the latch counter value corresponding to each in-sequence data packet that has not been sent out and is affected by the second source data stream by 1.

[0015] In an alternative embodiment, after decrementing the latch counter value corresponding to each in-sequence data packet that has not been sent out and is affected by the second source data stream by 1, the method further includes:

[0016] If there is an in-sequence data packet whose latch counter value becomes 0, set the in-sequence data packet with the latch counter value of 0 to be allowed to be sent.

[0017] In an alternative embodiment, after determining the second source data stream of the second data packet, the method further includes:

[0018] If the in-sequence type corresponding to the second source data stream of the second data packet is an in-sequence data stream, determine whether the second data packet is allowed to be sent;

[0019] If the second data packet is allowed to be sent, send the second data packet.

[0020] According to a second aspect of the present application, there is provided a multi-source data stream in-sequence device, including:

[0021] A first determination module, configured to determine the first source data stream of the first data packet in response to a reception request for the first data packet; the first source data stream corresponds to one of the following three in-sequence types: an unrelated data stream without in-sequence correlation requirements, an in-sequence data stream with in-sequence requirements, and a related data stream that affects the in-sequence of the in-sequence data stream;

[0022] An acquisition module, configured to, if the in-sequence type corresponding to the first source data stream of the first data packet is an in-sequence data stream, acquire the common counter value corresponding to the related data stream that affects the in-sequence of the first data packet;

[0023] A first setting module, configured to set the latch counter value corresponding to the first data packet to the common counter value;

[0024] A second setting module, configured to set the first data packet as not allowed to be sent when the latch counter value of the first data packet is not 0.

[0025] In an optional implementation, after the first determination module, the apparatus further includes:

[0026] A first counting module, configured to increase the common counter value corresponding to the first source data stream by 1 if the in-sequence type corresponding to the first source data stream of the first data packet is a related data stream.

[0027] In an optional implementation, the apparatus further includes:

[0028] A second determination module, configured to determine a second source data stream of the second data packet in response to a sending request of the second data packet;

[0029] A second counting module, configured to decrease the common counter value corresponding to the second source data stream by 1 and decrease the latch counter value corresponding to each in-sequence data packet that has not been sent out in the in-sequence data stream affected by the second source data stream by 1 if the in-sequence type corresponding to the second source data stream is a related data stream.

[0030] In an optional implementation, after the second counting module, the apparatus further includes:

[0031] A third setting module, configured to set the in-sequence data packet with the latch counter value becoming 0 as allowed to be sent if there is an in-sequence data packet with the latch counter value becoming 0.

[0032] In an optional implementation, after the second determination module, the apparatus further includes:

[0033] A judgment module, configured to judge whether the second data packet is allowed to be sent if the in-sequence type corresponding to the second source data stream of the second data packet is an in-sequence data stream;

[0034] A sending module, configured to send the second data packet if the second data packet is allowed to be sent.

[0035] Compared with the related art, the technical solution of the present application has at least the following advantages:

[0036] 1. Regarding the hardware resource overhead from the data stream source to the in-sequence processing module in the related art, in the above solution of the present application, since the timestamp in-sequence scheme is not adopted, the hardware resource overhead related to timestamps in the upstream data stream transmission can be reduced. Especially for a system with a long data transmission path, a large amount of hardware resource overhead can be reduced, and it is more friendly to low-power design.

[0037] 2. For the OD data stream related to order preservation, the latency can be reduced. By adopting the above solution of the present application, since the control of the data stream OD to be order-preserved is at the data stream outlet, it does not need to wait for the OA data stream transmission to complete compared with the source order-preservation scheme. Therefore, the latency of the OD data stream can be effectively reduced, which is more friendly to improving the performance related to the OD data stream.

[0038] Other features and advantages of the present application will be described in the following specification, and will be partially obvious from the specification, or will be understood by implementing the present application. The objectives and other advantages of the present application can be achieved and obtained through the structures and processes pointed out in the specification and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are certain embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0040] Figure 1 is a schematic flowchart of a multi-source data stream order-preservation method according to an exemplary embodiment of the present application.

[0041] Figure 2 is a schematic diagram of an order-preservation method for three types of data streams according to an exemplary embodiment of the present application.

[0042] Figure 3 is a schematic flowchart of the event control execution process of the OA data stream according to an exemplary embodiment of the present application.

[0043] Figure 4 is a schematic flowchart of the event control execution process of the OD data stream according to an exemplary embodiment of the present application.

[0044] Figure 5 is a structural block diagram of a multi-source data stream order-preservation device according to an exemplary embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] In order to make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0046] The related art also adopts an in-order preservation scheme for the data stream request source. This scheme supports the in-order preservation requirement for two data stream requests that need to be in order through software or hardware communication methods.

[0047] In the timestamp in-order preservation scheme, the sources of multi-source data streams with in-order relevance carry timestamps during data stream transmission. For multi-source data streams, all data streams that need to maintain in-order relationships need to carry in-order timestamp information. If the out-of-order capacity that needs to be in order is relatively large, it will require a relatively large bit-width hardware overhead for the in-order timestamp. In this in-order preservation scheme, if the in-order data stream is relatively large, there may be congestion and timing convergence in the hardware processing of data path relevance. At the same time, there is a relatively large hardware overhead from the data stream source node to the destination node that needs in-order processing. Therefore, this scheme requires timestamps from the data stream source to the target node for in-order control, which has a certain impact on both hardware overhead and power consumption.

[0048] The data source in-order preservation scheme is generally applied to scenarios with low performance and latency requirements. This scheme adopts block processing of in-order data streams with relevance, and only issues in-order related data streams after waiting for the previous data stream transmission to complete. Therefore, this scheme is very unfriendly to the processing of data streams that need to be in order, and has a greater impact on the data stream bandwidth and the latency of issuing in-order related data streams.

[0049] Therefore, in view of the above problems existing in the related art, the present application proposes a data stream in-order preservation method. In this method, the data source does not need to carry a timestamp, and only processes at the control node that needs in-order preservation. According to the data source type, the data sources are divided into three categories: data streams to be in order (data streams that need to ensure that the currently received data stream OA can be sent out only after it is sent, hereinafter described as OD), data streams related to the data streams to be in order (hereinafter described as OA), and data streams unrelated to the data streams to be in order (hereinafter described as NO).

[0050] For the three types of attributes related to in-order preservation in the data domain, different in-order preservation method control processes are respectively adopted to meet the in-order preservation requirements. For OD data streams, a common count of the number of completed corresponding data stream packets currently received is set; for OA data streams, the number of OD data streams corresponding to the OA data stream is recorded to ensure the relevance between the OA data stream and the OD data stream; for NO data streams, since there is no in-order relevance, no special processing is required. This in-order preservation method does not require separate counting for OD data streams, and the common counting method can effectively reduce the hardware overhead.

[0051] See Figure 1 As shown, the present application exemplarily provides a multi-source data stream in-order preservation method, including:

[0052] In step S101, in response to a reception request of a first data packet, determine a first source data stream of the first data packet; the first source data stream corresponds to one of the following three in - order - preservation types: an unrelated data stream without in - order - preservation correlation requirements, an in - order - preservation - required data stream to be in - order - preserved, and a related data stream that affects the in - order - preservation of the in - order - preservation - required data stream;

[0053] In step S102, if the in - order - preservation type corresponding to the first source data stream of the first data packet is an in - order - preservation - required data stream to be in - order - preserved, obtain a common counter value corresponding to the related data stream that affects the in - order - preservation of the first data packet;

[0054] In step S103, set the latch counter value corresponding to the first data packet to the common counter value;

[0055] In step S104, when the latch counter value of the first data packet is not 0, set the first data packet as not allowed to be sent.

[0056] Exemplarily, in this application, data streams are divided into three types according to in - order - preservation requirements: an unrelated data stream without in - order - preservation correlation requirements, an in - order - preservation - required data stream to be in - order - preserved, and a related data stream that affects the in - order - preservation of the in - order - preservation - required data stream. Among them, the unrelated data stream without in - order - preservation correlation requirements is a data stream that has no in - order - preservation requirements itself and does not affect other data streams that need in - order - preservation either. It is hereinafter referred to as the ON data stream for short. The in - order - preservation - required data stream to be in - order - preserved is a data stream that has in - order - preservation requirements itself. It is hereinafter called the OD data stream, and the data packets to be in - order - preserved in the OD data stream are simply called OD data packets. The related data stream is a data stream that has no in - order - preservation requirements itself but affects the in - order - preservation of the in - order - preservation - required data stream. It is hereinafter called the OA data stream, and the related data packets in the OA data stream are simply called OA data packets. Since the OA data stream will affect the in - order - preservation of the OD data stream, before forwarding an OD data packet from the OD data stream, it is necessary to send out all the OA data packets in all OA data streams received before this data packet is received, and then forward the OD data packet in the OD data stream, so as to ensure the correct forwarding order of the OD data packets in the OD data stream.

[0057] Exemplarily, for this application to achieve in - order - preservation of data streams, a common counter for storing the common counter value cntr_com is set for the OA data stream. The common counter value cntr_com is used to record the number of OA data packets in the currently received and unsent OA data stream; when an OA data packet from the OA data stream is received, the common counter value cntr_com is incremented by 1, and when an OA data packet in the OA data stream is sent out, the common counter value cntr_com is decremented by 1.

[0058] Exemplarily, see Figure 2As shown, after receiving a request for a first data packet, determine the type of data stream from which the first data packet comes, that is, determine the first source data stream of the first data packet. If the first source data stream of the first data packet is an OD data stream, then latch the count value in the common counter value cntr_com of the OA data stream that affects the first source data stream into the latch counter value cntr_latch[i] corresponding to the first data packet (i is used to indicate that the first data packet is the i-th packet in the first source data stream that needs to ensure order received currently). The cntr_latch[i] is used to latch the number of OA data packets in the OA data stream that affects the order preservation of the currently received first data packet. The maximum number of cntr_latch[i] depends on the maximum out-of-order ability of the OD data stream. After an OA data packet in the OA data stream is sent out, if the cntr_latch[i] is greater than 0, it is decremented by 1 until it reaches 0. When the cntr_latch[i] is 0, the OD data packet corresponding to the cntr_latch[i] is set to be allowed to be sent; otherwise, it is not allowed to be sent.

[0059] Exemplarily, the NO data stream is an irrelevant data stream without order-preserving correlation requirements, and its corresponding data stream does not require special processing. That is, when the first source data stream of the first data packet in the received request is the NO data stream, the first data packet can be directly stored.

[0060] It should be noted that different data streams come from different data reception channels. Data packets received from the same data reception channel belong to the same source data stream, and data packets in the same source data stream will be sent out from the corresponding same data transmission channel. Therefore, different data streams in this application refer to data streams from different sources.

[0061] The order-preserving scheme of the common counter value cntr_com in this application can effectively reduce the hardware resource overhead of the upstream data stream, and at the same time can effectively reduce the delay of the OD data stream, thereby improving performance.

[0062] In some alternative implementation manners, after determining the first source data stream of the first data packet, the method further includes:

[0063] If the order-preserving type corresponding to the first source data stream of the first data packet is a relevant data stream, increment the common counter value corresponding to the first source data stream by 1.

[0064] Exemplarily, refer to Figure 3 As shown, the reception process of the OA data stream is as follows:

[0065] Event T1: Receive a packet from the OA data stream, then the corresponding cntr Increment the com counter by 1.

[0066] Event T2: When sending a data packet of the OA data stream, the corresponding cntr Decrement the com counter by 1.

[0067] Event T3: If receiving a data packet of the OA data stream and sending a data packet of the OA data stream simultaneously, the value of the cntr com counter remains unchanged.

[0068] It should be noted that cntr The design of the bit width of the com counter depends on the maximum number of data packets that can be supported, ensuring that the count value of the counter never overflows.

[0069] In some alternative implementation manners, the method further includes:

[0070] In response to a sending request of a second data packet, determine the second source data stream of the second data packet;

[0071] If the in-sequence type corresponding to the second source data stream is a related data stream, decrement the value of the common counter corresponding to the second source data stream by 1, and decrement the value of the latch counter corresponding to each unsent in-sequence data packet in the in-sequence data stream affected by the second source data stream by 1.

[0072] Exemplarily, as described above, when sending an OA data packet in an OA data stream, the value of the common counter corresponding to the OA data stream is decremented by 1. In addition, the change in the value of the common counter also affects the values of the latch counters of the data packets in the OD data stream. See Figure 4 As shown, exemplarily, the specific event description of the OD data stream control is as follows:

[0073] Event T4: When receiving an OD data packet from the OD data stream, the corresponding common counter value (cntr_com) is latched into the latch counter value (cntr_latch[i]) corresponding to the OD data packet of the OD data stream, where cntr_latch[i] represents the number of OA data packets that have in-sequence correlation with the current OD of the current data stream in the current buffer; cntr_com represents the number of all current OA packets; so cntr_latch[i] is less than or equal to cntr_com.

[0074] Event T5: When sending an OA data packet of the OA data stream, the cntr_latch[i] corresponding to all OD data packets in the OD data stream affected by the OA data stream is decremented by 1.

[0075] Event T6: After cntr_latch[i] is decremented by 1, it is also necessary to determine whether cntr_latch[i] is 0. If it is 0, the OD data packet corresponding to cntr_latch[i] that is set to 0 is allowed to be sent.

[0076] It should be noted that the bit width of cntr_latch[i] is the same as the bit width of cntr_com, and the number of cntr_latch depends on the maximum out-of-order ability of the OD data stream channel.

[0077] Exemplarily, as described above, the NO data stream is an irrelevant data stream without requirements for order-preserving correlation. Therefore, if the second source data stream of the second data packet in the send request is the NO data stream, the second data packet can be directly sent.

[0078] In some alternative implementation manners, after decrementing by 1 the latch counter value corresponding to each non-sent order-preserving data packet in the order-preserving data stream affected by the second source data stream, the method further includes:

[0079] If there is an order-preserving data packet whose latch counter value becomes 0, set the order-preserving data packet whose latch counter value becomes 0 to be allowed to be sent.

[0080] Exemplarily, as described above, after cntr_latch[i] is decremented by 1, it is also necessary to determine whether cntr_latch[i] is 0. If it is 0, it means that all OA data packets affecting the OD data packet corresponding to this cntr_latch[i] have been sent out. Therefore, this OD data packet can also be sent out, so this OD data packet is allowed to be sent.

[0081] In some alternative implementation manners, after determining the second source data stream of the second data packet, the method further includes:

[0082] If the order-preserving type corresponding to the second source data stream of the second data packet is an order-preserving data stream, determine whether the second data packet is allowed to be sent;

[0083] If the second data packet is allowed to be sent, send the second data packet.

[0084] Exemplarily, as in the above text, if the second data packet to be sent currently is a data packet in the OA data stream, decrement by 1 the common counter value corresponding to this OA data stream and send this data packet. If the second data packet to be sent currently is a data packet in the OD data stream, it is necessary to first determine whether this second data packet is set to be allowed to be sent. If it is set to be allowed to be sent, send this second data packet; otherwise, do not send this second data packet.

[0085] The above solution of this application can solve the defects and deficiencies of the data flow order preservation solution in the related art, specifically as follows:

[0086] 1. Regarding the hardware resource overhead from the data flow source to the order preservation processing module in the related art, in the above solution of this application, since the timestamp order preservation solution is not adopted, the hardware resource overhead related to timestamps in the upstream data flow transmission can be reduced. Especially for a system with a long data transmission path, a large amount of hardware resource overhead can be reduced, and it is more friendly to low-power design.

[0087] 2. The delay of the OD data flow related to order preservation can be reduced. In the above solution of this application, since the control of the data flow OD to be order-preserved is at the data flow outlet, compared with the source order preservation solution, it does not need to wait for the OA data flow transmission to complete, so the delay of the OD data flow can be effectively reduced, which is more friendly to improving the performance related to the OD data flow.

[0088] Correspondingly, as shown in Figure 5 This application exemplarily proposes a multi-source data flow order preservation device, including:

[0089] A first determination module 501, configured to determine a first source data flow of a first data packet in response to a reception request of the first data packet; the first source data flow corresponds to one of the following three order preservation types: an irrelevant data flow without order preservation correlation requirements, a data flow OD to be order-preserved with order preservation requirements, and a related data flow that affects the order preservation of the data flow OD to be order-preserved;

[0090] An acquisition module 502, configured to, if the order preservation type corresponding to the first source data flow of the first data packet is a data flow OD to be order-preserved, acquire a common counter value corresponding to the related data flow that affects the order preservation of the first data packet;

[0091] A first setting module 503, configured to set the latch counter value corresponding to the first data packet to the common counter value;

[0092] A second setting module 504, configured to set the first data packet as not allowed to be sent when the latch counter value of the first data packet is not 0.

[0093] In some optional implementation manners, after the first determination module, the device further includes:

[0094] A first counting module, configured to, if the order preservation type corresponding to the first source data flow of the first data packet is a related data flow, increment the common counter value corresponding to the first source data flow by 1.

[0095] In some optional implementation manners, the device further includes:

[0096] A second determination module, configured to determine a second source data stream of the second data packet in response to a sending request of the second data packet;

[0097] A second counting module, configured to, if an in-sequence type corresponding to the second source data stream is a related data stream, decrement a common counter value corresponding to the second source data stream by 1, and decrement a latch counter value corresponding to each in-sequence data packet that has not been sent out in the in-sequence data stream affected by the second source data stream by 1.

[0098] In some alternative implementation manners, after the second counting module, the apparatus further includes:

[0099] A third setting module, configured to, if there is an in-sequence data packet whose latch counter value becomes 0, set the in-sequence data packet whose latch counter value becomes 0 to be allowed to be sent.

[0100] In some alternative implementation manners, after the second determination module, the apparatus further includes:

[0101] A judgment module, configured to, if an in-sequence type corresponding to the second source data stream of the second data packet is an in-sequence data stream, judge whether the second data packet is allowed to be sent;

[0102] A sending module, configured to, if the second data packet is allowed to be sent, send the second data packet.

[0103] The above apparatus can be implemented by the multi-source data stream in-sequence method provided in the above embodiments. The specific implementation manners can refer to the description of the multi-source data stream in-sequence method in the above embodiments, and will not be elaborated here.

[0104] It can be understood that the circuit structures, names, and parameters described in the above embodiments are only examples. Those skilled in the art can also perform easily conceivable combinations and adjustments on the structural features of the above multiple embodiments according to the usage needs, and should not limit the concept of the present application to the specific details of the above examples.

[0105] Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A multi-source data stream order preservation method, characterized in that: include: In response to a reception request of a first data message, determining a first source data stream of the first data message; the first source data stream corresponds to one of the following three order preservation types: an irrelevant data stream without order preservation correlation requirements, a data stream to be preserved with order preservation requirements, and a relevant data stream that affects the order preservation of the data stream to be preserved; If the order preservation type corresponding to the first source data flow of the first data message is a data flow to be order preserved, obtaining a common counter value corresponding to a related data flow affecting the order preservation of the first data message; Setting the latch counter value corresponding to the first data message to the common counter value; When the latch counter value of the first data message is not 0, the first data message is set to be not allowed to be sent.

2. The multi-source data stream order preservation method according to claim 1, characterized in that: After determining the first source data flow of the first data message, the method further includes: If the order preservation type corresponding to the first source data flow of the first data message is a related data flow, the common counter value corresponding to the first source data flow is increased by 1.

3. The multi-source data stream order preservation method according to claim 1 or 2, characterized in that: The method further comprises: In response to a request to send a second data message, determining a second source data stream of the second data message; If the order preservation type corresponding to the second source data stream is a related data stream, the common counter value corresponding to the second source data stream is reduced by 1, and the latch counter value corresponding to each unsent data message to be preserved in the order preservation data stream affected by the second source data stream is reduced by 1.

4. The multi-source data stream order preservation method according to claim 3, characterized in that: After decrementing by 1 the latch counter value corresponding to each unsent data message to be kept in the data stream to be kept in sequence that is affected by the second source data stream, the method further comprises: If a data message to be preserved whose latch counter value becomes 0 appears, the data message to be preserved whose latch counter value becomes 0 is set to be allowed to be sent.

5. The multi-source data stream order preservation method according to claim 3, characterized in that: After determining the second source data flow of the second data message, the method further includes: If the order preservation type corresponding to the second source data flow of the second data message is a data flow to be order preserved, determining whether the second data message is allowed to be sent; If the second data packet is allowed to be sent, the second data packet is sent.

6. A multi-source data stream sequence preservation device, characterized in that: include: A first determination module is used to determine a first source data stream of the first data message in response to a reception request of the first data message; the first source data stream corresponds to one of the following three types of order preservation: an irrelevant data stream without order preservation correlation requirements, a data stream to be preserved with order preservation requirements, and a relevant data stream that affects the order preservation of the data stream to be preserved; an acquisition module, configured to acquire a common counter value corresponding to a related data flow affecting the order preservation of the first data message if the order preservation type corresponding to the first source data flow of the first data message is a data flow to be order preserved; A first setting module, used for setting the latch counter value corresponding to the first data message to the common counter value; The second setting module is used to set the first data message to not be allowed to be sent when the latch counter value of the first data message is not 0.

7. The multi-source data stream sequence preservation device according to claim 6, characterized in that: After the first determining module, the device further includes: The first counting module is configured to increase the common counter value corresponding to the first source data flow of the first data message by 1 if the order preservation type corresponding to the first source data flow is a related data flow.

8. The multi-source data stream sequence preservation device according to claim 6 or 7, characterized in that: The device also includes: A second determining module, configured to determine a second source data flow of the second data message in response to a request to send the second data message; The second counting module is used to reduce the common counter value corresponding to the second source data stream by 1 if the order preservation type corresponding to the second source data stream is a related data stream, and to reduce the latch counter value corresponding to each unsent data message to be preserved in the order preservation data stream affected by the second source data stream by 1.

9. The multi-source data stream sequence preservation device according to claim 8, characterized in that: After the second counting module, the device further includes: The third setting module is used for setting the data message to be preserved with the latch counter value becoming 0 as allowed to be sent if the data message to be preserved with the latch counter value becoming 0 appears.

10. The multi-source data stream sequence preservation device according to claim 8, characterized in that: After the second determining module, the device further includes: A judgment module, configured to judge whether the second data message is allowed to be sent if the order preservation type corresponding to the second source data flow of the second data message is a data flow to be preserved; A sending module is used to send the second data message if the second data message is allowed to be sent.

Images