Message processing method and device, electronic equipment, medium and program product

Abstract

The invention discloses a message processing method and device, electronic equipment, a medium and a program product, and relates to the technical field of computers, and the method comprises the steps: obtaining a to-be-sent initial request message at a current moment; distributing a first request identifier for the initial request message according to a first message type of the initial request message; establishing a mapping relation between the first message type and the first request identifier, and storing the mapping relation to a preset storage area; processing the initial request message according to the first request identifier to obtain a first request message; and sending the first request message to the second peripheral component interconnection high-speed interface equipment, so that the second peripheral component interconnection high-speed interface equipment indicates a message type corresponding to the first response message based on the first request identifier when returning the first response message corresponding to the first request message. Through the application, the message type corresponding to the response message can be determined based on the request identifier, the response processing complexity is reduced, and the processing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a message processing method, apparatus, electronic device, medium, and program product. Background Technology

[0002] In the Peripheral Component Interconnect Express (PCIe) communication protocol, Transaction Layer Packets (TLPs) are divided into various message types according to different application scenarios. These message types are distinguished by the Format of TLP (FMT) and Type of TLP (TYPE) identifiers in the TLP header. In the PCIe protocol, the response messages for memory read requests (MRDs) and configuration read requests (CFGs) are assigned the same encoding. This encoding design means that when a PCIe device receives and initially processes TLP layer data, it cannot directly distinguish whether the response message is a reply to a memory read request or a configuration read request based solely on the header encoding. However, the processing logic (such as data parsing path, error handling strategy, and interaction methods with internal modules) for PCIe devices often differs significantly from those for memory read request response messages and configuration read request response messages. The current PCIe protocol lacks a dedicated identification field or association mechanism to record the original request type corresponding to the response message. This makes it impossible for the device to quickly locate the original request type after receiving the response message, affecting the subsequent processing flow of the response message. Summary of the Invention

[0003] This application provides a message processing method, apparatus, electronic device, medium, and program product to at least solve the problem of how to quickly identify the original request type corresponding to a response message.

[0004] This application provides a message processing method applied to a high-speed interface device for interconnecting first peripheral components, including: Get the initial request message to be sent at the current time; Assign a first request identifier to the initial request message based on the first message type of the initial request message; Establish a mapping relationship between the first message type and the first request identifier, and store the mapping relationship in a preset storage area; The initial request message is processed according to the first request identifier to obtain the first request message; The first request message is sent to the second peripheral component interconnect high-speed interface device, so that when the second peripheral component interconnect high-speed interface device returns the first response message corresponding to the first request message, it indicates the message type corresponding to the first response message based on the first request identifier.

[0005] This application also provides a message processing apparatus, including: The first acquisition module is used to acquire the initial request message to be sent at the current time; The allocation module is used to allocate a first request identifier to the initial request message according to the first message type of the initial request message; The module is used to establish a mapping relationship between the first message type and the first request identifier, and to store the mapping relationship in a preset storage area; The second acquisition module is used to process the initial request message according to the first request identifier and acquire the first request message; The sending module is used to send the first request message to the second peripheral component interconnect high-speed interface device, so that when the second peripheral component interconnect high-speed interface device returns the first response message corresponding to the first request message, it carries the first request identifier to indicate the message type corresponding to the first response message.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described message processing methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described message processing methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described message processing methods.

[0009] This application assigns a unique request identifier to request messages of different message types and stores the mapping relationship between message types and request identifiers in a preset storage area. When a response message is received, the message type of the original request message can be quickly determined by querying the mapping relationship in the preset storage area based on the request identifier carried in the response message. This avoids errors in the response message processing flow caused by the inability to distinguish between response messages of different message types, ensuring the normal operation of device functions. Simultaneously, PCIe devices can distinguish the message type without parsing the response message content upon receiving it, reducing data processing latency, avoiding the problem of mismatch between response messages and request messages when multiple requests are concurrent, and improving overall communication efficiency. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0011] Figure 1 This is a schematic diagram illustrating the processing of response messages provided in an embodiment of this application; Figure 2 A flowchart illustrating a message processing method provided in this application embodiment; Figure 3 A schematic diagram illustrating message processing in the message processing system provided in the embodiments of this application; Figure 4 A schematic diagram illustrating the allocation of a request identifier to the transaction identifier request algorithm module provided in this embodiment of the application; Figure 5 This is a schematic diagram illustrating the determination of the message type corresponding to the response message provided in an embodiment of this application. Figure 6 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] First, the application scenarios of the embodiments of this application will be introduced by way of example.

[0016] In the actual operation of Peripheral Component Interconnect Express (PCIe) devices, when the device needs to parse and process response messages (also known as Completion with Data (CPLD) packets) from different types of request messages (such as memory read request messages and configuration read request messages), the PCIe protocol does not provide a clear and effective differentiation mechanism. This prevents the device from directly determining whether a response message originates from a memory read request message or a configuration read request message. Furthermore, the subsequent processing flows for response messages from memory read request messages and configuration read request messages differ significantly, for example, in the data parsing module, error checking rules, and interaction paths with other components within the device. This places a clear requirement on the device: it must accurately identify the original request type corresponding to the response message before initiating the response message processing flow in order to select the correct processing logic. Currently, due to the lack of a dedicated mechanism in the PCIe protocol to identify the original request type corresponding to a response message, PCIe devices often cannot directly determine the source of a response message when receiving and preparing to process it, which may lead to abnormal data processing due to the selection of an incorrect processing procedure.

[0017] Figure 1 This is a schematic diagram illustrating the processing of response messages in related technologies. Figure 1 In this scenario, a PCIe device sends two request messages: Message 1 requesting data A and Message 2 requesting data B. The PCIe device uses a Transaction Layer Packet (TLP) assembly module to assemble these two request messages into packets, and then sends the assembled packets (Message 1 and Message 2) to the peer device. When the PCIe device receives the two messages returned by the peer device, it parses them. If the messages are determined to be response messages, it receives the data, thus obtaining data A and data B. If the messages are not response messages, they are processed according to other procedures. During this process, the PCIe device cannot determine the message type of each response message and needs to determine the message type based on the data within the messages, resulting in low data processing efficiency.

[0018] In view of this, embodiments of this application provide a message processing method to quickly distinguish different types of response messages.

[0019] According to an embodiment of the present invention, a message processing method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] Figure 2 This is a flowchart of a message processing method according to an embodiment of the present invention, applied to a high-speed interface device for interconnecting first peripheral components, such as... Figure 2 As shown, the process includes: S101, obtain the initial request message to be sent at the current time.

[0021] Specifically, the initial request message refers to the raw request data generated when the first PCIe device initiates communication. For example, the initial request message includes instructions, data, or operation requests (such as read data requests, write data requests, status query requests, etc.) that need to be processed by the peer device (such as the second CIe device).

[0022] S102, assign a first request identifier to the initial request message according to the first message type of the initial request message.

[0023] Specifically, the first message type refers to the functional classification of the initial request message, which is used to identify the specific operation type of the request, such as read operation, write operation, configuration request, interrupt request, etc.

[0024] The first request identifier refers to the unique identifier assigned to the initial request identifier, which is used to uniquely mark the request during communication to facilitate subsequent matching of response messages.

[0025] S103, establish a mapping relationship between the first message type and the first request identifier, and store the mapping relationship in a preset storage area.

[0026] Specifically, the preset storage area is an internal storage area in the first PCIe device, such as a region in Static Random-Access Memory (SRAM), which is specifically used to store a mapping table between request identifiers and message types.

[0027] S104, process the initial request message according to the first request identifier, and obtain the first request message.

[0028] Specifically, the first request message is a message that adds a first request identifier to the initial request message. For example, the first request identifier is combined with the initial request message to obtain the first request message.

[0029] S105, the first request message is sent to the second peripheral component interconnect high-speed interface device, so that the second peripheral component interconnect high-speed interface device carries the first request identifier to indicate the message type corresponding to the first response message when returning the first response message corresponding to the first request message.

[0030] Specifically, the second PCIe device is the device that receives and processes the first request message. After processing the first request message, the second PCIe device returns a first response message (i.e., the result message of the first request message) to the first PCIe device. For example, the first response message contains processing results, status information, etc.

[0031] In this embodiment, a unique request identifier is assigned to request messages of different message types, and the mapping relationship between message types and request identifiers is stored in a preset storage area. When a response message is received, the message type of the original request message can be quickly determined by querying the mapping relationship in the preset storage area based on the request identifier carried in the response message. This avoids errors in the response message processing flow caused by the inability to distinguish response messages of different message types, ensuring the normal operation of the device. Simultaneously, when a PCIe device receives a response message, it can distinguish the message type without parsing the response message content, reducing data processing latency, avoiding the problem of mismatch between response messages and request messages when multiple requests are concurrent, and improving overall communication efficiency.

[0032] In some embodiments, a first request identifier is assigned to the initial request message according to the first message type of the initial request message, specifically including the following steps: a1, based on the first message type, determines the first target identifier pool corresponding to the first message type from at least one pre-configured request identifier pool.

[0033] Specifically, the request identifier pool is a collection that stores a preset number of request identifiers. For example, when the request identifier is an identifier (TAG), the request identifier pool can be a preset range of TAGs.

[0034] In one possible implementation, at least one request identifier pool includes a shared identifier pool and non-shared identifier pools corresponding to at least one message type.

[0035] Specifically, the shared identifier pool is a set of identifiers in the pre-configured request identifier pool that is not bound to a specific message type and can be used by multiple message types that do not have their own dedicated non-shared identifier pools. It is a general-purpose identifier resource used to cover low-frequency or low-priority message type requests.

[0036] A non-shared identifier pool is a dedicated identifier pool bound to a specific message type and used only for message requests of that specific message type. Non-shared identifier pools are typically configured for high-frequency, high-priority message types to ensure efficient allocation of request identifiers for that message type. For example, memory read request messages and configuration read request messages can be configured with separate non-shared identifier pools, while other request messages share the shared identifier pool.

[0037] In a1 above, based on the first message type, a first target identifier pool corresponding to the first message type is determined from at least one pre-configured request identifier pool, specifically including the following: When there is a non-shared identifier pool corresponding to the first message type in all non-shared identifier pools, the non-shared identifier pool corresponding to the first message type will be used as the first target identifier pool.

[0038] or, When there is no corresponding non-shared identifier pool for the first message type among all non-shared identifier pools, the shared identifier pool will be used as the first target identifier pool.

[0039] Optionally, if a non-shared identifier pool corresponding to the first message type is found, then that non-shared identifier pool is directly designated as the first target identifier pool, and an unoccupied identifier is selected from the pool as the first requested identifier. If no corresponding non-shared identifier pool is found, then a shared identifier pool is used as the first target identifier pool, and an unoccupied identifier is selected from the pool as the first requested identifier.

[0040] Optionally, after allocating a request identifier, the request identifier is marked as occupied in the request identifier occupancy table of the corresponding pool. When the request is processed and a response message is received, the request identifier is released and updated to unoccupied, so that it can be reused by subsequent request messages.

[0041] In another possible implementation, a non-shared identifier pool can be configured for each message type.

[0042] In this way, each message type's identifier comes from a dedicated non-shared pool and corresponds to an independent storage sub-region, optimizing the "identifier-type" matching efficiency during the response processing phase. For example, when receiving a response message of type memory read (MRD), it is only necessary to locate the "MRD dedicated storage sub-region" through the "MRD dedicated non-shared pool" to which the second request identifier belongs, without needing to determine whether the identifier comes from a shared pool or other type pools. This is suitable for scenarios with high concurrency and low latency requirements. Furthermore, the identifier pools and storage sub-regions for different message types are completely independent, achieving complete isolation of message type data, avoiding response processing errors caused by cross-type interference, and ensuring data transmission reliability. In addition, different message types have different request frequencies, priorities, and identifier requirements. By configuring a dedicated non-shared identifier pool for each message type, the identifier pool configuration can be optimized accordingly. For example, a large-capacity non-shared identifier pool can be configured for high-frequency request types, while a small-capacity non-shared pool can be configured for low-frequency request types, avoiding resource waste.

[0043] a2, obtain the first request identifier from the first target identifier pool.

[0044] For example, the first request identifier is determined from the request identifiers in the first target identifier pool that have not established a mapping relationship.

[0045] Specifically, a request identifier without an established mapping relationship refers to a request identifier that has not established a request identifier-message type mapping relationship with any initial request message type and is in an idle / available state. For example, a corresponding identifier status table is created for each request identifier pool to record the status of each request identifier in the pool (e.g., no mapping relationship / idle state, established mapping relationship / occupied state). Thus, by calling the identifier status table corresponding to the identifier pool, identifiers in an idle state can be filtered out. From the filtered request identifiers without an established mapping relationship, the first request identifier that meets the condition is selected as the first request identifier. If multiple request identifiers are in an idle state, one can be selected as the first request identifier according to a preset order. Simultaneously, the status of this identifier in the identifier status table is updated to "established mapping relationship / occupied state" to avoid subsequent duplicate allocation and ensure the uniqueness of the mapping relationship.

[0046] In this embodiment, multiple independent identifier pools are pre-configured to classify and manage identifiers for different types of requests. A non-shared identifier pool is configured for specific message types, ensuring a stable supply of request identifiers for those specific message types. This eliminates the need to compete for identifier resources with other message types, thus optimizing identifier resource utilization. Furthermore, obtaining identifiers from the non-shared identifier pool for specific message types can improve request processing efficiency and reduce processing latency.

[0047] In some embodiments, based on any of the foregoing embodiments, the preset storage area corresponds to at least one storage sub-area, and each storage sub-area corresponds one-to-one with each request identifier pool. Storing the mapping relationship in the preset storage area specifically includes the following: The mapping relationship is stored in the storage sub-area corresponding to the first target identifier pool.

[0048] Specifically, a storage sub-region is an independent storage unit within a predefined storage region, divided according to the request identifier pool dimension. Each storage sub-region corresponds one-to-one with a request identifier pool and is used solely to store the mapping relationship between request identifiers and message types allocated by that identifier pool, thus achieving categorized storage of mapping data. In this embodiment, the request identifier pool and the storage sub-region form a one-to-one binding relationship. One request identifier pool corresponds to only one storage sub-region, and one storage sub-region serves only one request identifier pool, ensuring that the storage of the mapping relationship is completely synchronized with the identifier pool.

[0049] For example, the first PCIe device has a default storage area of ​​1KB SRAM, which is internally divided into 3 storage sub-regions: sub-region A (0x000-0x3FF address range) corresponds to non-shared identifier pool 1 (used to allocate request identifiers for memory read request messages), sub-region B (0x400-0x7FF address range) corresponds to non-shared identifier pool 2 (used to allocate request identifiers for configuration read request messages), and sub-region C (0x800-0xFFF address range) corresponds to shared identifier pool (used to allocate request identifiers for request messages other than memory read request messages and configuration read request messages). Each sub-region only stores the mapping relationship of the corresponding pool.

[0050] For example, a one-dimensional structure array is created in each storage sub-region, with the request identifier (such as TAG ID) as the index and the message type as the corresponding array element, thereby storing the mapping relationship between the request identifier and the message type.

[0051] In this embodiment, the corresponding storage sub-region is directly located based on the identifier pool of the request identifier, without traversing the entire preset storage region. This accelerates the query efficiency within the preset storage region and reduces response processing latency. Furthermore, when a request identifier pool needs to be expanded, shrunk, or reset, only the corresponding storage sub-region needs to be operated on, without affecting the data in other sub-regions. This simplifies the management and maintenance of mapping relationships and enhances the flexibility of multi-identifier pool expansion.

[0052] In some embodiments, based on any of the foregoing embodiments, the method provided in this application further includes the following: b1 receives the second response message returned by the high-speed interface device for the third peripheral component interconnection.

[0053] Specifically, the third PCIe device acts as both the receiver of requests sent by the first PCIe device and the initiator of responses. For example, the first PCIe device sends a configuration parameter read request to the third PCIe device, and the third PCIe device returns a second response message containing the configuration parameters.

[0054] b2 parses the second response message to determine the second request identifier corresponding to the second response message.

[0055] Specifically, the second request identifier is a unique identifier carried in the second response message that corresponds to the original request message sent by the first PCIe device.

[0056] b3, determine the second message type corresponding to the second request identifier based on the mapping relationship in the preset storage area.

[0057] In one possible implementation, before determining the second message type corresponding to the second request identifier based on the mapping relationship in the preset storage area, the method provided in this application embodiment further includes the following: From at least one request identifier pool, determine the second target identifier pool corresponding to the second request identifier.

[0058] When the second target identifier pool is a shared identifier pool, in b3 above, the second message type corresponding to the second request identifier is determined according to the mapping relationship in the preset storage area, specifically including the following: First, determine the target storage sub-region corresponding to the shared identifier pool from multiple storage sub-regions of the preset storage region.

[0059] Then, the second message type is determined from the mapping relationship of the target storage sub-region.

[0060] Specifically, the mapping relationship of the target storage sub-region is the association data between the request identifier and the message type stored in the target storage sub-region corresponding to the shared identifier pool. It covers the mapping relationship between the request identifier and the corresponding message type allocated by the shared identifier pool for various message types without dedicated non-shared pools.

[0061] In this way, when the second target identifier pool is a shared identifier pool, the query scope is locked to the shared identifier pool's exclusive storage sub-region by querying the mapping relationship in the corresponding target storage sub-region, without having to traverse all sub-regions of the preset storage region, thus reducing the amount of data queried.

[0062] Of course, when the second target identifier pool is a non-shared identifier pool, the message type of the non-shared identifier pool corresponding to the second target request identifier will be determined as the second message type.

[0063] Considering that there is a one-to-one preset binding relationship between the non-shared identifier pool and the message type, when it is determined that the second target identifier pool to which the second request identifier belongs is a non-shared identifier pool, the step of querying the mapping relationship of the storage sub-region can be skipped, and the second message type can be determined directly through the preset binding relationship, which shortens the time required to determine the message type and simplifies the response processing flow.

[0064] b4. Process the second response message according to the second message type.

[0065] In this embodiment, the type of the second message is determined by reverse lookup using the second request identifier, thus accurately identifying the source of the response message and avoiding processing confusion. Furthermore, the mapping relationship between identifiers and message types in the predictive storage area allows for rapid determination of the request message type corresponding to the response message without needing to parse the specific content of the response message, thereby shortening processing time and improving response processing efficiency.

[0066] In some embodiments, based on any of the foregoing embodiments, the method provided in this application further includes the following: First, obtain the status information of the response messages corresponding to all request identifiers in the preset storage area.

[0067] Specifically, the status information describes the processing progress or result of the response message. For example, the status information of the response message can be waiting for a response (i.e., the request message has been sent to the other end but a response message has not yet been received), response completed (i.e., the request message has been sent to the other end, and a response message has been received and parsed), or response timeout (i.e., the request message has been sent to the other end, but a response message has not been received within a preset time). In this embodiment, the status information is used as the basis for determining whether the mapping relationship needs to be unmapped and the request identifier released.

[0068] Then, when the status information of the third response message meets the preset status conditions, the mapping relationship between the message type corresponding to the third response message and the corresponding request identifier is removed in the preset storage area, and the request identifier corresponding to the third response message is released.

[0069] The third response message is one of the response messages corresponding to all request identifiers in the preset storage area.

[0070] Specifically, the preset status conditions are used as the basis for determining whether the mapping relationship between the message type and the corresponding request identifier of the third response message needs to be terminated. For example, the preset status conditions can be a status message indicating response completion, or a status message indicating response timeout, etc.

[0071] Releasing the request identifier corresponding to the third response message can reset the status of that identifier in the identifier status table corresponding to the request identifier pool from the occupied state to the idle state.

[0072] In this way, by releasing request identifiers that meet the preset state conditions in a timely manner, the long-term occupation of request identifiers is avoided, thereby realizing the cyclical reuse of request identifiers and improving the utilization rate of identifier resources.

[0073] In some embodiments, based on any of the foregoing embodiments, the method provided in this application further includes the following: c1 receives the second request message sent by the high-speed interface device for the third peripheral component interconnection.

[0074] c2 parses the second request message and obtains the third request identifier corresponding to the second request message.

[0075] c3 generates an initial response message corresponding to the second request message based on the second request message.

[0076] c4, based on the third request identifier, processes the initial response message corresponding to the second request message and generates a response message corresponding to the second request message.

[0077] For example, the third request identifier is combined with the initial response message corresponding to the second request message to obtain the response message corresponding to the second request message.

[0078] c5 sends the response message corresponding to the second request message to the third peripheral component interconnect high-speed interface device.

[0079] In some embodiments, based on any of the foregoing embodiments, the method provided in this application further includes the following: First, obtain the message types corresponding to the multiple historical request messages sent by the high-speed interface device of the first peripheral component interconnection within the first preset historical time period based on the current time.

[0080] Specifically, historical request messages refer to all request messages sent by the first PCIe device to other PCIe devices within the first preset historical time period, including memory write request messages, configuration read request messages, etc.

[0081] Then, count the number of historical request messages corresponding to each message type.

[0082] Specifically, the number of historical request messages corresponding to each message type refers to the total number of requests in each category obtained after classifying and counting historical request messages within the first preset historical time period according to message type, reflecting the business frequency (high frequency / low frequency) of different types of requests. For example, the number of memory read request messages is 500, the number of configuration read request messages is 200, and the number of message request messages is 100.

[0083] Finally, based on the number of historical request messages corresponding to each message type, a corresponding request identifier pool is allocated to each message type.

[0084] In one possible implementation, a corresponding non-shared identifier pool is allocated to each message type whose quantity is greater than or equal to a preset threshold. A shared identifier pool is allocated to all message types whose quantity is less than the preset threshold.

[0085] The preset quantity threshold can be set according to the actual situation, and there is no limitation here.

[0086] Considering that if the same size identifier pool is allocated to all message types, requests of high-frequency message types may be blocked due to insufficient identifiers, while requests of low-frequency message types will be wasted due to idle identifiers, in this embodiment of the application, by counting the number of historical request messages corresponding to different message types, requests of high-frequency message types can obtain more identifiers, thereby meeting the concurrency requirements of requests of high-frequency message types, while requests of low-frequency message types are allocated a small number of identifiers to avoid idle identifier resources and maximize the utilization of limited identifier resources.

[0087] In some embodiments, the method provided in this application further includes the following: d1, obtain the message type corresponding to each of the multiple historical request messages sent by the high-speed interface device of the first peripheral component interconnection within the second preset historical time period based on the current time, the sending time corresponding to each historical request message, and the return time of the response message corresponding to each historical request message.

[0088] d2. Based on the sending time of the first historical request message and the return time of the response message corresponding to the first historical request message, determine the duration occupied by the request identifier of the first historical request message.

[0089] The first historical request message is one of multiple historical request messages sent by the high-speed interface device for interconnecting the first peripheral components within the second preset historical time period.

[0090] Specifically, the request identifier holding time is the time interval from the allocation (i.e., the request sending time) to the release (i.e., the response return time) of the request identifier in a historical request message, reflecting the length of time the identifier is occupied. For example, the request identifier holding time is equal to the difference between the return time and the sending time.

[0091] d3. After determining the duration of request identifiers corresponding to all historical request messages, based on the message type and duration of request identifiers corresponding to all historical request messages, predict the number of request identifiers corresponding to each message type within a future preset time period based on the current time, and obtain the predicted number of request identifiers corresponding to each message type.

[0092] In one possible implementation, after determining the duration of request identifiers corresponding to all historical request messages, the number of request identifiers corresponding to each message type is predicted within a preset future time period based on the current time, according to the message type and the duration of request identifiers corresponding to all historical request messages. The predicted number of request identifiers corresponding to each message type is obtained by the following steps: e1 counts the number of historical request messages corresponding to each message type.

[0093] e2. Based on the request identifier duration of each historical request message corresponding to the third message type, determine the average request identifier duration corresponding to the third message type.

[0094] The third message type is one of the message types corresponding to the multiple historical request messages sent by the high-speed interface device for interconnecting the first peripheral components within the second preset historical time period.

[0095] e3. After determining the average request identifier duration for each message type, based on the number of historical request messages for each message type and the average request identifier duration for each message type, predict the number of request identifiers for each message type within a preset future time period based on the current time, and obtain the predicted number of request identifiers for each message type.

[0096] Optionally, in e3 above, the number of preset request identifiers corresponding to each message type is obtained in the following way: First, based on the number of historical request messages corresponding to the fourth message type, the first duration corresponding to the second preset historical time period, and the second duration corresponding to the future preset time period, the total number of requests corresponding to the fourth message type within the future preset time period is determined.

[0097] The fourth message type is one of the message types corresponding to the multiple historical request messages sent by the high-speed interface device for interconnecting the first peripheral components within the second preset historical time period.

[0098] For example, the formula for determining the total number of requests corresponding to the fourth message type within a preset future time period is as follows:

[0099] Where S represents the total number of requests corresponding to the fourth message type within a preset future time period, and A represents the number of historical request messages corresponding to the fourth message type. For the first duration, The second duration is denoted by m, which is a preset frequency coefficient. For example, for a stable scenario, the frequency coefficient can be set to 1, and for a growing scenario, the frequency coefficient can be set to 1.1~1.3.

[0100] Then, based on the total number of requests, the average request identifier duration corresponding to the fourth message type, and the second duration corresponding to the future preset time period, the predicted number of request identifiers corresponding to the fourth message type is determined.

[0101] For example, the formula for determining the number of predicted request identifiers corresponding to the fourth message type is as follows:

[0102] Where P is the predicted number of request identifiers corresponding to the fourth message type, S is the total number of requests corresponding to the fourth message type within a preset time period, and t is the average duration of request identifiers corresponding to the fourth message type. This is the second duration.

[0103] d4 retrieves the remaining number of identifiers in the request identifier pool for each message type at the current time.

[0104] d5. When it is determined that the third target identifier pool in at least one request identifier pool does not meet the preset identifier quantity condition based on the predicted request identifier quantity corresponding to each message type and the remaining identifier quantity in the request identifier pool corresponding to each message type, the capacity of the third target identifier pool is adjusted.

[0105] In one possible implementation, when the third target identifier pool is a non-shared identifier pool and the number of predicted request identifiers for the message type corresponding to the third target identifier pool is greater than the number of remaining identifiers in the third target identifier pool, it is determined that the third target identifier pool does not meet the preset identifier quantity condition.

[0106] In the above d5, the capacity of the third target identifier pool is adjusted, specifically including the following: The third target identifier pool is expanded based on the difference between the preset number of request identifiers for the message type corresponding to the third target identifier pool and the remaining number of identifiers in the third target identifier pool.

[0107] In another possible implementation, when the third target identifier pool is a shared identifier pool, the method provided in this application embodiment further includes the following: First, based on the number of predicted request identifiers corresponding to each message type in the shared identifier pool, determine the total number of predicted request identifiers corresponding to the shared identifier pool.

[0108] Then, when the predicted total number of requested identifiers is greater than the remaining number of identifiers in the shared identifier pool, it is determined that the shared identifier pool does not meet the preset identifier quantity condition.

[0109] Similarly, the third target identifier pool is expanded based on the difference between the predicted total number of requested identifiers and the remaining number of identifiers in the shared identifier pool.

[0110] In addition, to cope with future sudden requests, an expansion redundancy can be added on the basis of the difference. For example, the difference can be used as the expansion redundancy according to a preset ratio (such as 10%), and the sum of the difference and the expansion redundancy can be used as the number of request identifiers that need to be added to the third target identifier pool.

[0111] In this way, based on the difference between the predicted total number of requested identifiers and the remaining number of identifiers in the shared identifier pool, the third target identifier pool is expanded, realizing on-demand expansion of the identifier pool, avoiding excessive resource allocation, ensuring the continuity of the business corresponding to the identifier pool, avoiding request blocking, and improving business continuity.

[0112] In one possible implementation, when the third target identifier pool is a non-shared identifier pool, and the number of predicted request identifiers corresponding to the non-shared identifier pool (i.e., the third target identifier pool) is less than the remaining capacity corresponding to the non-shared identifier pool, the non-shared identifier pool is scaled down according to the number of predicted request identifiers corresponding to the third target identifier pool and the remaining capacity.

[0113] Optionally, the number of identifiers to be reduced in the third target identifier pool is determined based on the difference between the remaining capacity of the third target identifier pool and the predicted number of request identifiers, as well as a preset scaling-down coefficient. For example, the difference is multiplied by the preset scaling-down coefficient to obtain the number of request identifiers to be reduced in the third target identifier pool, and the third target identifier pool is scaled down according to the reduction number. The preset scaling-down coefficient can be limited according to the actual situation; for example, the preset ratio coefficient is set to 0.7.

[0114] Similarly, when the third target identifier pool is a shared identifier pool, and the sum of the predicted request identifiers for all message types corresponding to the shared identifier pool is less than the remaining capacity of the shared identifier pool, the shared identifier pool is reduced in size based on the sum of the predicted request identifiers for all message types corresponding to the shared identifier pool and the remaining capacity of the shared identifier pool.

[0115] If an identifier pool is in a state where "remaining capacity far exceeds predicted demand" for an extended period (e.g., the MRD pool has 59 remaining identifiers but only needs 30), a large number of identifier resources will be idle (29 identifiers will remain unused for a long time), while other types of identifier pools (e.g., those facing a surge in future CFG requests) may face resource shortages. By scaling down and reclaiming redundant resources (returning the 29 identifiers to the global standby pool), idle resources can be reintegrated into the global scheduler for use by other identifier pools with demand (e.g., direct access during subsequent CFG pool expansion), avoiding the imbalance of "some pools having excess resources and others having insufficient resources," and improving the overall utilization rate of identifier resources for PCIe devices.

[0116] The above mainly describes the solution provided by the embodiments of this application from a methodological perspective.

[0117] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0118] This application also provides a message processing system. The system includes a transaction identifier algorithm application module, a request type identifier module, a request type storage module, a response type query module, a response type parsing module, an identifier pool, and an identifier recycling module.

[0119] The Transaction Identifier (TLP) algorithm application module is one of the core modules of the system. Its function is to dynamically allocate an appropriate TAG ID range based on the TLP type. Each type of request message (also known as a request packet, such as a read request message, write request message, etc.) is assigned to a different TAG ID range, thereby ensuring that each type of request packet obtains a suitable identifier. Through this dynamic allocation method, the system can effectively avoid TAG conflicts between different request types while maintaining the efficiency and accuracy of data processing.

[0120] The request type identification module is responsible for identifying and managing the TAG ID of each request, ensuring that each TAG ID is clearly associated with its corresponding request packet type. During data transmission, the system can quickly track and identify the status of each request packet and determine its type through this identification module. For example, some request packets may be read requests, while others may be write requests. By accurately identifying the TAG ID, the system can respond quickly and perform necessary processing, thereby improving the overall efficiency and accuracy of data transmission.

[0121] The request type storage module stores the mapping relationship between all identified TAG IDs and their corresponding message types. This module persistently stores the TAG IDs and message types identified by the request type identification module for later retrieval. During system operation, message types can be quickly retrieved, avoiding duplicate queries and redundant calculations, further accelerating the request packet processing. Furthermore, this module's optimized data storage structure ensures high query efficiency even in high-frequency request scenarios.

[0122] The response type query module is responsible for querying the TAG information in the TLP header when the system needs to identify a specific request packet. This module uses the TAG ID as an index to quickly retrieve the corresponding request type information from the request type storage module. Through this query mechanism, the system can quickly identify the type of the request packet being processed. For example, the system can quickly determine whether a request packet is a read request or a write request, thereby speeding up response time, reducing processing latency, and improving overall system performance.

[0123] The response type parsing module further parses the detailed type of the request packet. When the system receives a CPLD packet, this module uses the TAG ID as an index and combines it with the TAG algorithm to parse the request packet, determining whether it is an MRD (Memory Read) type reply packet or another type of CPLD packet. In this way, the response type parsing module helps the system quickly and accurately identify the message type corresponding to the CPLD packet, thereby achieving rapid allocation and efficient processing of request packets, reducing unnecessary resource consumption, and improving the system's response speed.

[0124] The tag pool manages the allocation and release of all tags in the system, ensuring the uniqueness of each tag and preventing duplicate requests and conflicts. By tracking the usage of each tag in real time, the tag pool can effectively update the tag's status information, ensuring that each tag is allocated only once and that each request packet is effectively tagged. The tag pool design ensures that the system maintains stable and efficient operation when handling a large number of concurrent requests, and minimizes resource waste.

[0125] During CPLD packet processing, the tag recycling module is responsible for releasing the carried tags back to the tag pool for use in the next round of requests. This mechanism ensures efficient utilization of tag resources and avoids system performance degradation due to excessive resource consumption. By releasing tag resources in real time, the tag recycling module not only improves resource utilization but also accelerates the tag reallocation process, ensuring stable and efficient performance even under high throughput and large number of requests. Especially under conditions of high request volume and high system load, the tag recycling module's operation is crucial for the continuous and stable operation of the system.

[0126] When a request identifier is released, the identifier recycling module changes the status of that request identifier in the request identifier pool to an unoccupied / unallocated state, making it available for subsequent requests. Simultaneously, the request type storage module updates the message type corresponding to that request identifier to "unknown type," effectively removing the mapping between message type and request identifier.

[0127] Figure 3 This diagram illustrates how each module in the message processing system implements message processing. Figure 3 In the PCIe device, when the transaction identifier application algorithm module obtains a request message to be sent (such as a memory read request, configuration read request, or other types of requests), it allocates a request identifier for the request message from the identifier pool according to the message type of the request message. The request type identifier module establishes a mapping relationship between the request identifier and the message type and stores the mapping relationship in the request type storage module. Then, the request identifier and the request message are packaged together and the packaged request message is sent to the peer device.

[0128] The specific implementation process of the transaction identifier request algorithm module for allocating request identifiers is as follows: Figure 4 As shown, in Figure 4 In this process, when the transaction identifier request algorithm module receives a request message, it first determines whether the message type corresponding to the request message has been allocated an independent identifier pool, i.e., whether the message type belongs to type 1 or type 2. If it has been allocated, it retrieves the identifier pool corresponding to the message type and checks whether there are any unused request identifiers in the corresponding identifier pool. If they exist, a request identifier is allocated to the request message; otherwise, the allocation fails. If the message type has not been allocated an independent identifier pool, an unused request identifier will be allocated from the shared identifier pool. If there are no available request identifiers in the shared pool, the allocation fails; otherwise, an allocation is performed.

[0129] exist Figure 3In this process, when a PCIe device receives a message and determines that it is a response message, it uses the response type parsing model and response type query module to determine the message type corresponding to the response message. After determining the message type, the identifier release module releases the request identifier corresponding to the response message. Furthermore, as... Figure 3 As shown, when it is determined that the message is not a response message, other processes are initiated to handle it.

[0130] The specific process for determining the message type corresponding to the response message is as follows: Figure 5 As shown, after obtaining the request identifier corresponding to the response message, it is first determined whether the request identifier corresponding to the response message is within the request identifier range corresponding to message type 1 (such as a memory read request). If the request identifier corresponding to the response message is not within the request identifier range corresponding to message type 1, it is determined whether the request identifier corresponding to the response message is within the request identifier range corresponding to message type 2 (such as a configuration read request). If it is within the request identifier range corresponding to message type 1 or message type 2, the message type of the response message is directly determined based on the request identifier range it falls within. If the request identifier corresponding to the response message is not within the request identifier range corresponding to either of these two requests, the message type corresponding to the response message is further determined by the response type query module based on the mapping relationship between the request identifier and the message type stored in the request type storage module.

[0131] In this embodiment, a mechanism based on the TLP header TAG field for identification and management, combined with a TAG algorithm, request type identification and storage, CPLD type query and parsing module, and an identifier pool and identifier recycling module, enables rapid identification, allocation, and parsing of request packets. This system significantly improves data transmission efficiency and system processing speed, making it particularly suitable for high-throughput, large-scale request system environments.

[0132] This application also provides a message processing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0133] This embodiment provides a message processing device applied to a high-speed interface device for interconnecting first peripheral components, such as... Figure 6 As shown, it includes: The first acquisition module 601 is used to acquire the initial request message to be sent at the current time; The allocation module 602 is used to allocate a first request identifier to the initial request message according to the first message type of the initial request message; Module 603 is used to establish a mapping relationship between the first message type and the first request identifier, and to store the mapping relationship in a preset storage area; The second acquisition module 604 is used to process the initial request message according to the first request identifier and acquire the first request message; The sending module 605 is used to send the first request message to the second peripheral component interconnect high-speed interface device, so that when the second peripheral component interconnect high-speed interface device returns the first response message corresponding to the first request message, it carries the first request identifier to indicate the message type corresponding to the first response message.

[0134] The apparatus provided in this application assigns a unique request identifier to request messages of different request message types and stores the mapping relationship between message types and request identifiers in a preset storage area. When a response message is received, the message type of the original request message can be quickly determined by querying the mapping relationship in the preset storage area based on the request identifier carried in the response message. This avoids errors in the response message processing flow caused by the inability to distinguish response messages of different types, ensuring the normal operation of the device. Simultaneously, when a PCIe device receives a response message, it can distinguish the message type without parsing the response message content, reducing data processing latency and avoiding the problem of mismatch between response messages and request messages when multiple requests are concurrent, thus improving overall communication efficiency.

[0135] For a description of the features in the embodiment corresponding to the message processing device, please refer to the relevant description in the embodiment corresponding to the message processing method, which will not be repeated here.

[0136] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above-described message processing method embodiments.

[0137] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described message processing method embodiments when it is run.

[0138] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0139] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described message processing method embodiments.

[0140] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described message processing method embodiments.

[0141] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0142] The foregoing has provided a detailed description of a message processing method, apparatus, electronic device, medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A message processing method, characterized in that, The method, applied to a high-speed interface device for interconnecting first peripheral components, includes: Get the initial request message to be sent at the current time; Assign a first request identifier to the initial request message according to the first message type of the initial request message; Establish a mapping relationship between the first message type and the first request identifier, and store the mapping relationship in a preset storage area; The initial request message is processed according to the first request identifier to obtain the first request message; The first request message is sent to the second peripheral component interconnect high-speed interface device, so that when the second peripheral component interconnect high-speed interface device returns the first response message corresponding to the first request message, it carries the first request identifier to indicate the message type corresponding to the first response message.

2. The method according to claim 1, characterized in that, The method further includes: Receive the second response message returned by the high-speed interface device for the third peripheral component interconnection; The second response message is parsed to determine the second request identifier corresponding to the second response message; Based on the mapping relationship in the preset storage area, determine the second message type corresponding to the second request identifier; The second response message is processed according to the second message type.

3. The method according to claim 2, characterized in that, Assigning a first request identifier to the initial request message according to the first message type of the initial request message includes: Based on the first message type, determine the first target identifier pool corresponding to the first message type from at least one pre-configured request identifier pool; Obtain the first request identifier from the first target identifier pool.

4. The method according to claim 3, characterized in that, At least one of the request identifier pools includes a shared identifier pool and non-shared identifier pools corresponding to at least one message type. The step of determining a first target identifier pool corresponding to the first message type from the pre-configured at least one request identifier pool, based on the first message type, includes: When there is a non-shared identifier pool corresponding to the first message type in all the non-shared identifier pools, the non-shared identifier pool corresponding to the first message type will be used as the first target identifier pool. or, When there is no corresponding non-shared identifier pool for the first message type among all the non-shared identifier pools, the shared identifier pool is used as the first target identifier pool.

5. The method according to claim 4, characterized in that, The preset storage area corresponds to at least one storage sub-area, and each storage sub-area corresponds one-to-one with each request identifier pool; Storing the mapping relationship to a preset storage area includes: The mapping relationship is stored in the storage sub-area corresponding to the first target identifier pool.

6. The method according to claim 5, characterized in that, Before determining the second message type corresponding to the second request identifier based on the mapping relationship in the preset storage area, the method further includes: From at least one of the request identifier pools, determine the second target identifier pool corresponding to the second request identifier; When the second target identifier pool is a shared identifier pool, the step of determining the second message type corresponding to the second request identifier based on the mapping relationship in the preset storage area includes: From multiple storage sub-regions of the preset storage area, determine the target storage sub-region corresponding to the shared identifier pool; The second message type is determined from the mapping relationship of the target storage sub-region.

7. The method according to claim 6, characterized in that, The method further includes: When the second target identifier pool is a non-shared identifier pool, the message type of the non-shared identifier pool corresponding to the second request identifier is determined as the second message type.

8. The method according to any one of claims 3-7, characterized in that, Obtaining the first request identifier from the first target identifier pool includes: The first request identifier is determined from the request identifiers in the first target identifier pool that have not established a mapping relationship.

9. The method according to any one of claims 1-7, characterized in that, The method further includes: Obtain the status information of the response messages corresponding to all request identifiers in the preset storage area; When the status information of the third response message meets the preset status conditions, the mapping relationship between the message type and the corresponding request identifier of the third response message is removed in the preset storage area, and the request identifier corresponding to the third response message is released. The third response message is one of the response messages corresponding to all request identifiers in the preset storage area.

10. The method according to any one of claims 1-7, characterized in that, The method further includes: Receive the second request message sent by the third peripheral component interconnect high-speed interface device; The second request message is parsed to obtain the third request identifier corresponding to the second request message; Based on the second request message, generate an initial response message corresponding to the second request message; Based on the third request identifier, the initial response message corresponding to the second request message is processed to generate a response message corresponding to the second request message; The response message corresponding to the second request message is sent to the third peripheral component interconnect high-speed interface device.

11. The method according to any one of claims 4-7, characterized in that, The method further includes: Get the message types corresponding to multiple historical request messages sent by the first peripheral component interconnection high-speed interface device within a first preset historical time period based on the current time. Count the number of historical request messages corresponding to each message type; Based on the number of historical request messages corresponding to each message type, a corresponding request identifier pool is allocated for each message type.

12. The method according to claim 11, characterized in that, The step of allocating a corresponding request identifier pool for each message type based on the number of historical request messages corresponding to each message type includes: Assign a corresponding non-shared identifier pool to each message type whose quantity is greater than or equal to a preset quantity threshold; The shared identifier pool is allocated to all message types whose quantity is less than the preset threshold.

13. The method according to any one of claims 4-7, characterized in that, The method further includes: Get the message type corresponding to each of the multiple historical request messages sent by the first peripheral component interconnection high-speed interface device within the second preset historical time period based on the current time, the sending time corresponding to each of the historical request messages, and the return time of the response message corresponding to each of the historical request messages; Based on the sending time of the first historical request message and the return time of the response message corresponding to the first historical request message, the duration of the request identifier corresponding to the first historical request message is determined, wherein the first historical request message is one of a plurality of historical request messages sent by the first peripheral component interconnection high-speed interface device within the second preset historical time period; Once the duration of request identifiers corresponding to all the historical request messages is determined, the number of request identifiers corresponding to each message type is predicted within a future preset time period based on the message type and the duration of request identifiers corresponding to all the historical request messages, and the predicted number of request identifiers corresponding to each message type is obtained. Obtain the remaining number of identifiers in the request identifier pool corresponding to each of the aforementioned message types at the current time; When it is determined, based on the predicted number of request identifiers corresponding to each of the message types and the remaining number of identifiers in the request identifier pool corresponding to each of the message types, that at least one third target identifier pool in the request identifier pool does not meet the preset identifier quantity condition, the capacity of the third target identifier pool is adjusted.

14. The method according to claim 13, characterized in that, After determining the duration of request identifiers corresponding to all the historical request messages, the process involves predicting the number of request identifiers corresponding to each message type within a preset future time period, based on the message type and duration of request identifiers corresponding to all the historical request messages, and obtaining the predicted number of request identifiers corresponding to each message type, including: Count the number of historical request messages corresponding to each message type; Based on the request identifier occupancy duration of each historical request message corresponding to the third message type, the average request identifier occupancy duration corresponding to the third message type is determined, wherein the third message type is one of the message types corresponding to multiple historical request messages sent by the first peripheral component interconnection high-speed interface device within the second preset historical time period; Once the average request identifier occupancy time corresponding to each of the message types is determined, the number of request identifiers corresponding to each of the message types is predicted within a future preset time period based on the current time, according to the number of historical request messages corresponding to each of the message types and the average request identifier occupancy time corresponding to each of the message types, and the predicted number of request identifiers corresponding to each of the message types is obtained.

15. The method according to claim 13, characterized in that, The method further includes: When the third target identifier pool is the non-shared identifier pool, and the number of predicted request identifiers for the message type corresponding to the third target identifier pool is greater than the number of remaining identifiers in the third target identifier pool, it is determined that the third target identifier pool does not meet the preset identifier number condition. The adjustment of the capacity of the third target identifier pool includes: The third target identifier pool is expanded based on the difference between the preset number of request identifiers for the message type corresponding to the third target identifier pool and the remaining number of identifiers in the third target identifier pool.

16. The method according to claim 13, characterized in that, When the third target identifier pool is a shared identifier pool, the method further includes: Based on the number of predicted request identifiers corresponding to each message type in the shared identifier pool, determine the total number of predicted request identifiers corresponding to the shared identifier pool; When the total number of predicted request identifiers is greater than the remaining number of identifiers in the shared identifier pool, it is determined that the shared identifier pool does not meet the preset identifier quantity condition.

17. A message processing apparatus, characterized in that, The device is applied to a high-speed interface device for interconnecting first peripheral components, the device comprising: The first acquisition module is used to acquire the initial request message to be sent at the current time; The allocation module is used to allocate a first request identifier to the initial request message according to the first message type of the initial request message; A module is established to establish a mapping relationship between the first message type and the first request identifier, and to store the mapping relationship in a preset storage area; The second acquisition module is used to process the initial request message according to the first request identifier to acquire the first request message; The sending module is configured to send the first request message to the second peripheral component interconnect high-speed interface device, so that the second peripheral component interconnect high-speed interface device carries the first request identifier to indicate the message type corresponding to the first response message when returning the first response message corresponding to the first request message.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the message processing method as described in any one of claims 1-16 when executing the computer program.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the message processing method as described in any one of claims 1-16.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the message processing method as described in any one of claims 1-16.

Images