Cross-domain communication method, electronic equipment and medium

Abstract

The invention discloses a cross-domain communication method, electronic equipment and a medium, and relates to the technical field of computers, the method comprises the following steps: receiving memory access information of first equipment; identifying whether the first equipment is cross-domain equipment or not according to first identification information of the first equipment in the memory access information; when the first equipment is not cross-domain equipment, performing cross-domain address mapping on the memory access information to generate a source end request message; sending the source end request message to a second non-transparent bridge in the target domain through the transmission bridge; receiving an initial response message forwarded by the second non-transparent bridge; and generating a final response message according to the initial response message, the first identification information and second identification information corresponding to the second equipment, and returning the final response message to the first equipment. According to the application, the non-transparent bridges located in different domains are connected through the transmission bridge, and the problems of cross-domain access expansibility and wiring are solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a cross-domain communication method, an electronic device, and a medium. Background Art

[0002] With the rise of applications such as heterogeneous computing and data center resource integration, the demand for cross-domain access between different high-speed serial computer expansion bus standards (such as the peripheral component interconnect express (PCIe) domain) has been increasing. In related technologies, cross-domain access is achieved by respectively setting up interconnected Non-Transparent Bridges (NTBs) within each domain. The connection between each non-transparent bridge usually depends on a direct physical link, and the expansion of non-transparent bridges within each domain needs to follow a specific topology, resulting in severely limited scalability. In addition, the interconnection of non-transparent bridges in different domains also causes excessive layout and wiring that is difficult to converge. Summary of the Invention

[0003] This application provides a cross-domain communication method, an electronic device, and a medium to at least solve the problems of poor scalability and excessive layout and wiring in a cross-domain access architecture.

[0004] This application provides a cross-domain communication method, which is applied to a cross-domain communication system. The system includes multiple non-transparent bridges, and each non-transparent bridge is located in a different high-speed serial computer expansion bus standard domain. Each non-transparent bridge is connected through a transmission bridge. The method is executed by a first non-transparent bridge, and the first non-transparent bridge is any transparent bridge among the multiple non-transparent bridges. The method includes: Receiving memory access information sent by a first device; Identifying whether the first device is a device across high-speed serial computer expansion bus standards domains according to the first identification information corresponding to the first device included in the memory access information; When the first device is not a device across high-speed serial computer expansion bus standards domains, performing cross-domain address mapping on the memory access information to generate a source-end request message; Sending the source-end request message through the transmission bridge to a second non-transparent bridge within the target high-speed serial computer expansion bus standard domain corresponding to the memory access information, for the second non-transparent bridge to feed back the memory access information to a second device; Receiving, through the transmission bridge, an initial response message forwarded by the second non-transparent bridge and fed back by the second device according to the memory access information; Generating a final response message according to the initial response message, the first identification information, and the second identification information corresponding to the second device, and returning the final response message to the first device.

[0005] The present application also provides a cross-domain communication device, including: A first receiving module, configured to receive memory access information sent by a first device; An identification module, configured to identify whether the first device is a device across the Peripheral Component Interconnect Express (PCIe) domain according to first identification information corresponding to the first device included in the memory access information; An address mapping module, configured to perform cross-domain address mapping on the memory access information to generate a source-side request message when the first device is not a device across the PCIe domain; A sending module, configured to send the source-side request message to a second non-transparent bridge within a target PCIe domain corresponding to the memory access information through a transmission bridge, so that the second non-transparent bridge feeds back the memory access information to a second device; A second receiving module, configured to receive, through the transmission bridge, an initial response message fed back by the second device according to the memory access information forwarded by the second non-transparent bridge; A generating module, configured to generate a final response message according to the initial response message, the first identification information, and second identification information corresponding to the second device, and return the final response message to the first device.

[0006] The present application also provides an electronic device, including: a memory, configured to store a computer program; and a processor, configured to implement the steps of any one of the above cross-domain communication methods when executing the computer program.

[0007] The present application also provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any one of the above cross-domain communication methods.

[0008] The present application also provides a computer program product, including a computer program, and the computer program, when executed by a processor, implements the steps of any one of the above cross-domain communication methods.

[0009] Through this application, non-transparent bridges located in different domains are connected through a transmission bridge. The transmission bridge overcomes the physical and logical limitations between PCIe domains in the related art, enabling the newly added non-transparent bridges and in-domain devices to be conveniently connected to each PCIe domain when a new PCIe domain is added, without the need for large-scale transformation of the original architecture, thus meeting the scalability requirements. In addition, in terms of wiring, the introduction of the transmission bridge simplifies the complex physical connections, reduces the quantity and complexity of the direct wiring between non-transparent bridges, saves hardware space and wiring costs, making the overall architecture of multiple PCIe domains more concise and clear, and enhancing the practicality of cross-domain access. In this application, the non-transparent bridges in each domain are used to perform cross-domain address mapping on the memory access information, effectively solving the problem of address space isolation for cross-domain memory access, ensuring the accuracy and reliability of data transmission, enabling devices in different PCIe domains to access each other and work together, and giving full play to the advantages of heterogeneous computing. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0011] Figure 1 Schematic diagram of an architecture for realizing cross-domain access based on a back-to-back NTB according to an embodiment of the present application; Figure 2 Schematic diagram of a cross-domain communication system according to an embodiment of the present application; Figure 3 Flowchart of a cross-domain communication method according to an embodiment of the present application; Figure 4 Schematic diagram of a host in a source domain accessing a host in a target domain according to an embodiment of the present application; Figure 5 Schematic diagram of an endpoint device in a source domain accessing a host in a target domain according to an embodiment of the present application; Figure 6 Schematic diagram of an endpoint device in a source domain accessing an endpoint device in a target domain according to an embodiment of the present application; Figure 7 Schematic diagram of four data paths in a non-transparent bridge according to an embodiment of the present application; Figure 8 Schematic diagram of the structure of a cross-domain communication device according to an embodiment of the present application; Figure 9 Schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0012] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0013] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present 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 of the present technology to better understand the solution of the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] First, an exemplary introduction to the application scenario of the embodiments of the present application will be given.

[0016] With the continuous development of heterogeneous computing and data center resource integration, etc., the cross-domain access requirements between different high-speed serial computer expansion bus standards (peripheral component interconnect express, PCIe) domains have also increased rapidly. However, in the related art, cross-domain access is mainly achieved by setting up interconnected Non-Transparent Bridges (NTBs) within each domain. However, in this way, the non-transparent bridges rely on direct physical link connections, and the expansion of the non-transparent bridges within the domain is limited by a specific topology. Once new devices need to be added or the architecture needs to be adjusted, the overall layout often needs to be greatly changed, and the scalability is seriously insufficient. At the same time, the interconnection of a large number of non-transparent bridges in different domains makes the physical wiring intricate and difficult to effectively plan and manage. It not only occupies too much hardware space but also increases the risk of signal interference, resulting in difficulty in converging the layout and wiring, and seriously affecting the stability and maintenance efficiency of the system.

[0017] Figure 1 is a schematic diagram of an architecture for realizing cross-domain access based on a back-to-back NTB of the PCIe protocol. In Figure 1Among them, host A and host B are used as the root nodes within their respective PCIe domains to manage PCIe transactions within the domains. The upstream switch port (USP) and downstream switch port (DSP) are switch ports in the PCIe switching fabric, which are used to connect devices (such as non-transparent bridges, endpoint devices, etc.) within the PCIe domain to the host. In Figure 1 In the left PCIe domain, endpoint device (EP) 0, endpoint device 1, and non-transparent bridge 0 are respectively connected to host A through the downstream switch port and upstream switch port A. In Figure 1 In the right PCIe domain, endpoint device 2 and non-transparent bridge 1 are connected to host B through the downstream switch port and upstream switch port B. From Figure 1 It can be seen from the implementation method of the back-to-back non-transparent bridge based on the PCIe protocol in [above content] that when it is necessary to add a new PCIe domain to connect with the existing PCIe domain, there are problems such as difficult expansion and layout and wiring.

[0018] In view of this, the embodiments of the present application provide a cross-domain communication method to solve the problems of poor scalability and excessive layout and wiring in the above cross-domain access architecture.

[0019] It should be noted that the execution subject of the cross-domain communication method provided by the embodiments of the present invention can be a device for the cross-domain communication method. The device for the cross-domain communication method can be implemented as part or all of an electronic device through software, hardware, or a combination of software and hardware. Among them, the electronic device can be a server or a terminal. Among them, the server in the embodiments of the present application can be a single server or a server cluster composed of multiple servers. The terminal in the embodiments of the present application can be other intelligent hardware devices such as a smart phone, a personal computer, a tablet computer, a wearable device, and a smart robot. In the following method embodiments, the execution subject is taken as an electronic device for illustration.

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

[0021] An embodiment of the present application provides a cross - domain communication system. In this system, there are multiple non - transparent bridges, each non - transparent bridge is located in a different Peripheral Component Interconnect Express (PCIe) domain, and each non - transparent bridge is connected through a transmission bridge. In each PCIe domain, in addition to non - transparent bridges, there are also a host, a routing module, an upstream switching port, a downstream switching port, and an endpoint device. Among them, the routing module is used to receive and send packets and determine the packet flow direction.

[0022] In the cross - domain communication system, data transmission and communication between different Peripheral Component Interconnect Express (PCIe) domains (such as PCIe domains) can be realized. Through non - transparent bridges and transmission bridges, problems such as address space isolation and protocol conversion between different bus domains can be solved. The present application does not limit the version of the PCIe protocol. For example, PCIe 3.0 and PCIe 4.0, etc., can be selected according to the actual situation.

[0023] A non - transparent bridge is a type of PCI - Express bridging chip, which is used to connect different PCIe domains, break the intra - domain communication limit of the transparent bridge (TB), support cross - domain memory access and device communication, and connect the independent memory systems of two or more computers to the same PCI - Express structure.

[0024] The transmission bridge is a communication bridge connecting different non - transparent bridges, which is used to transmit cross - domain request packets, response packets, etc. in the cross - domain communication system. Exemplarily, the transmission bridge can be implemented through a PCIe link or other high - speed serial buses. For example, a cascaded link is built using a Peripheral Component Interconnect Express (PCIe) Switch, or the construction of the transmission bridge is realized by technologies such as Peripheral Component Interconnect Express over Fiber (PCIe over Fiber).

[0025] Figure 2 It is a cross - domain communication system. In Figure 2 In the left - hand PCIe domain, endpoint device 0 and endpoint device 1 are respectively connected to the transmission bridge through their respective downstream switching ports and routing modules. Non - transparent bridge 0 is connected to host A through the routing module and upstream switching port A. In Figure 2 In the right - hand PCIe domain, endpoint device 2 is connected to the transmission bridge through the downstream switching port and routing module. Non - transparent bridge 1 is connected to host B through the routing module and upstream switching port B.

[0026] Figure 3 It is a flowchart of a cross - domain communication method provided according to an embodiment of the present invention. This method is executed by the first non - transparent bridge in the cross - domain communication system, and the first non - transparent bridge is any transparent bridge among multiple non - transparent bridges. As Figure 3 shown, this process includes: S101: Receive the memory access information sent by the first device.

[0027] Specifically, the memory access information includes key parameters for the device to read and write to the memory, such as the operation type (read / write), the target memory address, the length of the data read, the device identifier, and other information. For example, if device 1 in PCIe domain A initiates a read operation request to device 2 in PCIe domain B, the memory access information includes the device identifier (such as the device ID) of the source device (i.e., device 1), the source address requested for access, and the size of the data read is 64 bytes, etc.

[0028] S102: Identify whether the first device is a device across the Peripheral Component Interconnect Express (PCIe) domain based on the first identification information corresponding to the first device included in the memory access information.

[0029] Specifically, the first identification information is the device information used to represent the first device that initiates the memory access, which can be the device ID, device name, etc. This application does not make specific limitations on the first identification information.

[0030] A device across the PCIe domain refers to a device that does not belong to the PCIe domain where the first non-transparent bridge is located. For example, if device 1 in PCIe domain A initiates memory access information to the first non-transparent bridge of device 2 in PCIe domain B, the PCIe domain where device 1 is located is different from the PCIe domain where the first non-transparent bridge is located, that is, device 1 is a cross-PCIe domain device.

[0031] S103: When the first device is not a device across the PCIe domain, perform cross-domain address mapping on the memory access information to generate a source request message.

[0032] Specifically, cross-domain address mapping refers to converting the memory address in the original PCIe domain into an address that can be recognized by the target PCIe domain to solve the problem of discontinuous address spaces in different domains. For example, the source address is included in the memory access information sent by the first device. At this time, the first non-transparent bridge will perform cross-domain address mapping on the source address, such as mapping the source address 0x200000 to the destination address 0x8000000.

[0033] The source request message refers to the message generated by the first non-transparent bridge after performing cross-domain address mapping on the memory access information. Exemplarily, the source request message includes, but is not limited to, the destination address, the identification information of the source device (i.e., the first device), the identification information of the target device (i.e., the device requested for access by the source device), the length of the requested data, and other information.

[0034] S104: Send the source request message through the transmission bridge to the second non-transparent bridge within the target PCIe domain corresponding to the memory access information.

[0035] In this way, after receiving the source-end request message, the second non-transparent bridge feeds back the memory access information to the second device.

[0036] S105: Receive, through the transmission bridge, the initial response message forwarded by the second non-transparent bridge and fed back by the second device according to the memory access information.

[0037] Specifically, the initial response message is the result message returned by the target device, that is, the second device, after performing operations in response to the source-end request message. Exemplarily, the initial response message includes an operation status (such as success / failure) and response data (such as the result of a read operation).

[0038] S106: Generate a final response message based on the initial response message, the first identification information, and the second identification information corresponding to the second device, and return the final response message to the first device.

[0039] Specifically, the final response message is the final message generated after the first non-transparent bridge processes the received initial response message (such as data reorganization, integrity verification, removing cross-domain transmission additional fields, etc.). For example, when the read request data volume is large, the response message may be transmitted in fragments, and the non-transparent bridge integrates the fragmented data into complete data and returns it to the first device. Another example is that the first non-transparent bridge verifies the data CRC (Cyclic Redundancy Check) to ensure correctness.

[0040] Exemplarily, the initial response message, the first identification information, and the second identification information corresponding to the second device are integrated to obtain the final response message.

[0041] Of course, the initial response message may also include the identification information of the source-end device (i.e., the first device) and the identification information of the target device (i.e., the device requested by the source-end device for access, that is, the second device). In this case, the first non-transparent bridge takes the initial response message as the final response message and directly sends the initial response message to the first device.

[0042] In the embodiments of the present application, non-transparent bridges located in different domains are connected through a transmission bridge. The transmission bridge overcomes the physical and logical limitations between PCIe domains in the related art, enabling new non-transparent bridges and in-domain devices to be conveniently connected to each PCIe domain when a new PCIe domain is added, without the need for large-scale transformation of the original architecture, thus meeting the scalability requirements. In addition, in terms of wiring, the introduction of the transmission bridge simplifies complex physical connections, reduces the quantity and complexity of direct wiring between non-transparent bridges, saves hardware space and wiring costs, and makes the overall architecture of multiple PCIe domains more concise and clear, enhancing the practicality of cross-domain access. In the present application, non-transparent bridges in each domain are used to perform cross-domain address mapping on memory access information, effectively solving the problem of address space isolation for cross-domain memory access, ensuring the accuracy and reliability of data transmission, enabling devices in different PCIe domains to access each other and work together, and giving full play to the advantages of heterogeneous computing.

[0043] In some embodiments, in S103 above, the source-end request message is generated in the following manner: a1: According to the source-end address in the memory access information and at least one preset cross-domain address mapping rule, determine the third identification information corresponding to the target Peripheral Component Interconnect Express (PCIe) domain.

[0044] Specifically, the source-end address refers to the memory address within the PCIe domain where the first device is located when the first device initiates a memory access, and is used to represent the starting position of data reading and writing. For example, when host A wants to access the data at memory address 0x10000000, 0x10000000 is the source-end address.

[0045] The source-end address is included in the memory access information sent by the first device and follows the PCIe layer protocol format. The first non-transparent bridge can directly parse it from the memory access information sent by the first device.

[0046] The cross-domain address mapping rule refers to a pre-set rule for address conversion between different PCIe domains. In the cross-domain address mapping rule, it is defined how the source-end address is mapped to the destination-end address to solve the problem of address space isolation between different domains. For example, in the cross-domain address mapping rule, it is set that "the source-end address range 0x10000000 - 0x20000000 corresponds to the base address 0x80000000 of target domain B". When the source-end address is 0x10001234, it is mapped to the destination-end address according to this rule.

[0047] The third identification information is used to represent information of the target domain PCIe domain, and can be the ID of the target domain, the number of non-transparent bridges included in the target domain, and so on. The first non-transparent bridge determines which domain to send the memory access information to through the third identification information. For example, assume that there are 3 PCIe domains, namely domain 1, domain 2, and domain 3, and the IDs of the non-transparent bridges in each domain are 0x01, 0x02, and 0x03 respectively. When the source address matches the rule for forwarding to domain 1, the third identification information is 0x01 (the ID of the non-transparent bridge in domain 1).

[0048] In a possible implementation manner, the cross-domain address mapping rule includes a source address range and identification information corresponding to the PCIe domain of the Peripheral Component Interconnect Express standard domain.

[0049] The source address range in the cross-domain address mapping rule refers to which source addresses can use this rule to implement cross-domain address conversion. For example, 0x20000000 - 0x30000000.

[0050] The identification information corresponding to the PCIe domain refers to which PCIe domain the source addresses belonging to this source address range are to be forwarded to. The identification information corresponding to the PCIe domain can be the name, ID, etc. of the PCIe domain, and this application does not make specific limitations in this regard. For example, in cross-domain address mapping rule 1, the source address range is 0x10000000 - 0x20000000, and the target domain identifier is 0x01 (corresponding to domain A). In cross-domain address mapping rule 2, the source address range is 0x20000000 - 0x30000000, and the target domain identifier is 0x02 (corresponding to domain B).

[0051] In addition, in the cross-domain address mapping rule, in addition to including the above source address range and identification information corresponding to the PCIe domain of the Peripheral Component Interconnect Express standard domain, it can also include the base address (the starting address in the target domain) corresponding to the PCIe domain. For example, cross-domain address mapping rule 1 includes: source address range: 0x20000000 ~ 0x30000000, identification information of the PCIe domain: 0x02, target domain base address: 0x80000000.

[0052] In the above a1, the third identification information corresponding to the target PCIe domain is determined in the following manner: First, according to the source address range included in each cross-domain address mapping rule, determine the source address range where the source address is located, and use the cross-domain address mapping rule corresponding to the source address range where the source address is located as the target cross-domain address mapping rule.

[0053] Specifically, the first non-transparent bridge finds the target cross-domain address mapping rule corresponding to the source address by traversing multiple cross-domain address mapping rules.

[0054] Optionally, the cross-domain address mapping rules can be traversed in the order of the starting addresses in the source address ranges of the respective cross-domain address mapping rules, thereby improving the search efficiency and enhancing the response speed of the non-transparent bridge.

[0055] For example, if the source address 0x25001234 is within the source address range 0x20000000 - 0x30000000 of the cross-domain address mapping rule 2, then the cross-domain address mapping rule 2 is the target cross-domain address mapping rule.

[0056] Then, the identification information corresponding to the PCIe domain is extracted from the target cross-domain address mapping rule as the third identification information corresponding to the target PCIe domain.

[0057] In this way, the first non-transparent bridge accurately determines the third identification information of the target domain through the source address range where the source address is located, and then forwards the memory access information through the transmission bridge.

[0058] a2: Determine the source address offset corresponding to the memory access information according to the source address and the cross-domain address mapping rule corresponding to the third identification information.

[0059] Specifically, the source address offset refers to the offset value of the source address relative to the source domain base address in the cross-domain address mapping rule, which is used to calculate the "relative position" of the destination address. For example, if the cross-domain address mapping rule sets that "the source address range 0x10000000 - 0x20000000 corresponds to the base address 0x80000000 of the target domain B", then the source domain base address in the cross-domain address mapping rule is 0x10000000.

[0060] In a possible implementation, the source address offset = source address - source domain base address in the cross-domain address mapping rule. For example, if the source domain base address in the cross-domain mapping rule is 0x10000000 and the source address is 0x10001234, then the source address offset = 0x10001234 - 0x10000000 = 0x1234.

[0061] a3: Generate a source request message according to the source address offset and the memory access information.

[0062] Specifically, the source request message refers to the cross-domain memory access request message generated after the first non-transparent bridge completes the address mapping, which contains an address recognizable by the target domain (i.e., the destination address), an operation type, a cross-domain identifier (such as the third identification information of the target PCIe domain), etc., and is used for the transmission bridge to forward the memory access information to the second non-transparent bridge in the target domain.

[0063] In the embodiments of the present application, by parsing the source address in the memory access information to match the cross-domain mapping rule, the third identification information of the target PCIe domain and the address offset are determined, so as to generate a source-side request message for cross-domain access, solving the problem of address isolation between PCIe domains. When using the preset cross-domain mapping rule to implement the conversion of inter-domain addresses, enabling devices in different PCIe domains to achieve cross-domain access, the identification information of the PCI domain is used to ensure the accuracy of cross-domain requests.

[0064] In some embodiments, the method provided by the embodiments of the present application further includes: When the request correlation identifier in the initial response message is consistent with the request correlation identifier corresponding to the memory access information, a status code corresponding to the initial response message is generated.

[0065] Specifically, the request correlation identifier is used to mark a memory access request and its corresponding response. During the cross-domain communication process, it remains unchanged throughout the entire process from the first device initiating a request to receiving a response, ensuring a one-to-one correspondence between the request and the response and avoiding the occurrence of response confusion. For example, when the first device initiates a request to read data from the second device, the request will be assigned a unique identifier, and during subsequent transmissions, this identifier will follow the messages throughout the entire process of the request and the response.

[0066] In a possible implementation manner, when the first non-transparent bridge receives the memory access information of the first device, a unique request correlation identifier will be assigned to this request. For example, the first non-transparent bridge generates the request correlation identifier corresponding to the memory access information by means of a counter, randomly generating a unique number, etc.

[0067] Specifically, the status code is a code for the execution result of the memory access operation corresponding to the initial response message, such as statuses of success, failure, timeout, etc., so that the first device can quickly understand the execution situation of the operation.

[0068] In a possible implementation manner, when the request correlation identifier in the initial response message forwarded by the second non-transparent bridge is consistent with the request correlation identifier corresponding to the memory access information, the first non-transparent bridge generates a status code according to the operation result information carried in the initial response message (for example, whether data is returned, whether an error is reported, etc.) according to the preset status code generation rule. Exemplarily, if the second device successfully executes the read data request of the first device, the status code is 1, indicating that the request is successful; if the request times out and is not completed, the status code is 0.

[0069] In a possible implementation manner, the final response message can also be obtained through the following method: Based on the response data in the initial response message, the request correlation identifier in the initial response message, and the status code, as well as the first identifier information corresponding to the first device and the second identifier information corresponding to the second device, the final response message is obtained.

[0070] Exemplarily, the response data in the initial response message, the request correlation identifier in the initial response message, the status code, the first identifier information corresponding to the first device, and the second identifier information corresponding to the second device are integrated to generate the final response message.

[0071] Specifically, the response data is the data returned by the second device after performing corresponding operations according to the memory access information, such as the data content returned by a read operation, the write confirmation information within the write operation range, etc.

[0072] In a possible implementation manner, the first non-transparent bridge fills the response data, the request correlation identifier, the status code, the first identifier information, and the second identifier information into the corresponding fields in sequence according to the preset message format specification, and combines them to generate the final response message. For example, it is encapsulated according to the format of the header information (including the request correlation identifier, the status code, the device identifier, etc.) and the data body (response data).

[0073] In the embodiments of the present application, by means of the request correlation identifier, it is ensured that the request matches the response, effectively avoiding problems such as message out-of-order and loss that may occur during the cross-domain transmission process, and ensuring the accuracy and reliability of data interaction. In addition, by introducing the status code, the first device can quickly and intuitively understand the execution result of the memory access operation without complex parsing of the response data, improving the response efficiency and the convenience of interaction. In the embodiments of the present application, various key information is integrated into the final response message in the same format, standardizing the data transmission format and reducing the complexity of the first device in processing the response.

[0074] In some embodiments, when the first device is a device across the Peripheral Component Interconnect Express (PCIe) domain, the cross-domain communication method provided by the embodiments of the present application further includes the following: b1: Perform cross-domain address mapping on the memory access information to generate a destination-end request message.

[0075] Specifically, the destination-end request message is a request message generated by the first non-transparent bridge after performing cross-domain address conversion on the memory access information according to the source-end address offset and the target domain base address, and includes information such as the converted destination address, the operation type, the data length, and the device identifier of the source-end device. The destination-end request message is used to be transmitted within the domain where the first non-transparent bridge is located to the third device.

[0076] In a possible implementation manner, the above b1 generates the destination-end request message through the following c1 - c2: c1: Extract the source - side address offset in the memory access information.

[0077] Specifically, the source - side address offset in the memory access information is obtained by the non - transparent bridge within the PCIe domain where the first device is located based on the cross - domain address mapping rule. The source - side address offset in the memory access information can be obtained with reference to the above a1 - a2, and this is not elaborated in this embodiment of the present application.

[0078] c2: Generate a destination - side request message based on the source - side address offset in the memory access information and the base address of the first non - transparent bridge in the Peripheral Component Interconnect Express (PCIe) domain.

[0079] Optionally, the above c2 generates the destination - side request message in the following manner: First, determine the destination - side address corresponding to the memory access information based on the source - side address offset in the memory access information and the base address of the first non - transparent bridge in the PCIe domain.

[0080] Specifically, the destination - side address is the target address corresponding to the memory access request within the PCIe domain where the first non - transparent bridge is located, and is used to locate the memory location of the third device within this PCIe domain.

[0081] Exemplarily, the destination - side address corresponding to the memory access information = base address+source - side address offset. For example, assume that the base address of the PCIe domain where the first non - transparent bridge is located is 0x80000000, and the source - side address offset is 0x1234, then the destination - side address is 0x80000000 + 0x1234 = 0x80001234.

[0082] Then, generate a destination - side request message based on the destination - side address and the memory access information.

[0083] Exemplarily, the destination - side request message includes information such as the destination - side address, operation type (read / write), data length, request association identifier, device identifier of the source - side device, device identifier of the target - side device, etc., and is used to be transmitted to the third device within the domain where the first non - transparent bridge is located.

[0084] b2: Send the destination - side request message to the third device in the Peripheral Component Interconnect Express (PCIe) domain where the first non - transparent bridge is located.

[0085] Specifically, the third device refers to the target device corresponding to the memory access information, that is, the first device sends a memory access request to the third device. Here, the third device can be the first device or a device within the PCIe domain where the first non - transparent bridge is located.

[0086] In the embodiments of the present application, the first non-transparent bridge determines the destination address corresponding to the memory access information based on the source address offset in the memory access information and the base address of the domain where it is located, realizing the accurate conversion of cross-domain device addresses between different PCIe domains, avoiding address conflicts and incorrect accesses, and ensuring the accuracy and reliability of data transmission.

[0087] In a possible case, the cross-domain communication method provided by the embodiments of the present application further includes the following: First, receive a response message fed back by the third device.

[0088] Specifically, the response message fed back by the third device is the message returned by the third device to the first non-transparent bridge after receiving the destination request message and completing corresponding operations (such as reading data, writing data, etc.). Exemplarily, the response message fed back by the third device includes, but is not limited to, operation results (such as the data read, write status), request correlation identifiers, and other information.

[0089] Then, when the request correlation identifier in the response message fed back by the third device is consistent with the request correlation identifier corresponding to the memory access information, send the response message fed back by the third device to the third non-transparent bridge within the cross-high-speed serial computer extension bus standard domain through the transmission bridge.

[0090] Specifically, as described above, the request correlation identifier is an identifier that runs through the entire process of memory access requests and responses, used to match requests with corresponding responses, and avoid message confusion during cross-domain communication.

[0091] Exemplarily, when the first device initiates a request, the third non-transparent bridge in the PCIe domain where the first device is located assigns a request correlation identifier to it. This request correlation identifier is sent to the first non-transparent bridge along with the memory access information. After the third device responds to the destination request message, it carries the same request correlation identifier in the response message so that the first non-transparent bridge can determine the memory access information corresponding to the response message.

[0092] For example, the first device is located in domain A, the third device is located in domain B. After the first non-transparent bridge receives the response from the third device in domain B, it sends the message to the third non-transparent bridge in domain A through the transmission bridge, and the third non-transparent bridge in domain A forwards the response message to the first device.

[0093] In the embodiments of the present application, the response message is matched with the memory access information through the request correlation identifier, avoiding incorrect distribution of responses caused by problems such as network latency and message out-of-order, ensuring that cross-domain devices can accurately receive corresponding operation results, and improving the reliability of data interaction.

[0094] In some embodiments, when the first non-transparent bridge receives memory access information sent by multiple devices and generates source-side request messages respectively corresponding to each device, in step S104 above, the source-side request messages are sent to the second non-transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to the memory access information through the following method via the transmission bridge: d1: Route each source-side request message to the transmission bridge through arbitration.

[0095] Specifically, in a cross-domain communication system, if two or more devices simultaneously send memory access information to the first non-transparent bridge, that is, two or more devices initiate memory access requests. Each memory access information includes its respective operation type (read / write), source address, data length, device identifier, and other information.

[0096] The arbitration method refers to when multiple source-side request messages need to be transmitted through the same transmission bridge, determining the transmission order of each source-side request message through a preset algorithm to avoid resource conflicts and ensure the orderly sending of each message.

[0097] In a possible implementation manner, in step d1 above, each source-side request message is routed to the transmission bridge through the following method: First, based on the identifier information of the devices in each memory access information, determine the access priority of each device.

[0098] Specifically, the access priority refers to the transmission priority of each device that sends memory access information, which determines the order of sending each source-side request message to the transmission bridge.

[0099] The device identifier of a device can be the device type, the function corresponding to the device, etc. The first non-transparent bridge determines the access priority of each device based on the device identifiers of each device. For example, for a device of a critical device type, the memory access information it sends has a higher access priority.

[0100] Then, according to the access priority of each device, sequentially send the source-side request messages corresponding to each device to the transmission bridge.

[0101] Optionally, send the generated source-side request messages to the transmission bridge one by one in descending order of the access priority of the devices, ensuring that high-priority requests occupy the transmission resources first.

[0102] Exemplarily, first, the first non-transparent bridge sorts each source-side request message according to each access priority to generate a transmission queue. Then, the first non-transparent bridge takes out the source-side request message with the highest access priority from the head of the queue and sends the source-side request message with the highest access priority to the transmission bridge. Then repeat the above operations until the queue is empty, and complete the sending of each source-side request message.

[0103] In the implementation provided by this application, the access priorities of each device are utilized to determine the transmission order of each source-end request message, ensuring that source-end request messages with high priorities are preferentially transmitted to the transmission bridge, scheduling the source-end request messages in an orderly manner, avoiding request disorder or congestion caused by resource competition, and enhancing system stability.

[0104] In another possible implementation, in the above d1, each source-end request message is routed to the transmission bridge in the following manner: First, based on the load data of non-transparent bridges within the target domain corresponding to each source-end request message, the routing order of each source-end request message is determined.

[0105] Specifically, the load data of non-transparent bridges is used to characterize the workload status of non-transparent bridges, including but not limited to the number of requests to be processed, the occupancy rate of data transmission bandwidth, processing latency, etc. The load data of non-transparent bridges can be used to measure the ability of a non-transparent bridge to process requests. For example, if there are 50 unprocessed memory access messages and the bandwidth occupancy rate is 80% for a non-transparent bridge currently, it indicates that the non-transparent bridge is in a high-load state. If there are 5 unprocessed memory access messages and the bandwidth occupancy rate is 30% for a non-transparent bridge currently, it is determined that the second transparent bridge is in a low-load state.

[0106] Optionally, the load data includes the total number of requests to be processed. Each source-end request message is sorted according to the total number of requests to be processed by each non-transparent bridge to generate the routing order of each source-end message request.

[0107] Specifically, the larger the total number of requests to be processed, the higher the load of the non-transparent bridge. Suppose there are 80 unprocessed requests for non-transparent bridge 1 and 20 unprocessed requests for non-transparent bridge 2, then the load of non-transparent bridge 1 is higher than that of non-transparent bridge 2.

[0108] Exemplarily, the first non-transparent bridge sorts each source-end request message in ascending order according to the total number of requests to be processed by the non-transparent bridge corresponding to each source-end request message to generate a routing order queue. Then, each source-end request message is sent according to its position in the routing order queue. For example, if the obtained routing order queue after sorting is message 1 → message 2 → message 3, the first non-transparent bridge first sends message 1 to the transmission bridge, and then sequentially sends message 2 and message 3.

[0109] Similarly, when the load data includes the occupancy rate of data transmission bandwidth, processing latency, etc., similar to the total number of requests to be processed, each source-end request message is sorted to generate the routing order of each source-end message request.

[0110] Then, each source-end request message is sent to the transmission bridge according to its routing order.

[0111] In the embodiments of the present application, the routing order is dynamically adjusted according to the load data of each non-transparent bridge, and requests corresponding to non-transparent bridges in a low-load state are preferentially sent, that is, requests sent to low-load non-transparent bridges are preferentially processed, so as to avoid the situation that requests are concentrated and sent to non-transparent bridges in a high-load state, resulting in overload of the non-transparent bridges.

[0112] d2: Use the transmission bridge to transmit each source-end request message to the non-transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to each source-end request message.

[0113] In some embodiments, within the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located, in addition to the first non-transparent bridge, there are at least one non-transparent bridge.

[0114] In the case where the first non-transparent bridge receives memory access information sent by multiple devices, the cross-domain communication method provided by the embodiments of the present application further includes the following content: First, obtain the load data of each non-transparent bridge.

[0115] Then, according to the load data of each non-transparent bridge, send each memory access information to each non-transparent bridge, so that each non-transparent bridge can perform cross-domain address mapping on the memory access information respectively to generate a source-end request message corresponding to the memory access information.

[0116] In a possible implementation manner, a two-way heartbeat link is established between each non-transparent bridge and the first non-transparent bridge, and heartbeat packets are sent to each other regularly. If the first non-transparent bridge does not receive the heartbeat response from the non-transparent bridge within a preset time period, the non-transparent bridge that does not receive the heartbeat response is marked as a faulty non-transparent bridge. At the same time, the first non-transparent bridge distributes the requests not processed by the faulty non-transparent bridge to other non-transparent bridges.

[0117] In this way, through the two-way heartbeat link, the first non-transparent bridge can monitor the running status of each non-transparent bridge in real time. Once a faulty non-transparent bridge is detected, the first non-transparent bridge can immediately distribute its unprocessed requests to other non-transparent bridges, realizing the rapid transfer of faulty loads, effectively avoiding the interruption of cross-domain communication caused by non-transparent bridge failures, and enhancing the reliability of cross-domain communication.

[0118] In an embodiment of the present application, compared to deploying a single non-transparent bridge, by deploying multiple non-transparent bridges within a PCIe domain, multiple memory access information can be processed in parallel, thereby improving the cross-domain communication throughput. At the same time, based on the load data of each non-transparent bridge in the PCIe domain, each memory access information is distributed, which can avoid congestion caused by traffic concentration on a single non-transparent bridge and achieve load balancing of each non-transparent bridge in the PCIe domain. In addition, within a PCIe domain, deploying multiple non-transparent bridges can enhance the fault tolerance of cross-domain communication. Even if a non-transparent bridge fails and cannot respond to a request, the first non-transparent bridge, which serves as the management node of each non-transparent bridge, can distribute the request to other non-transparent bridges.

[0119] The above mainly introduces the solution provided in the embodiment of the present application from the perspective of method.

[0120] Next, continue with Figure 2 Taking the cross-domain communication system in the example, the communication between the devices in the system is illustrated. Figure 4 This is a schematic diagram of a host in the source domain accessing a host in the target domain. Figure 4 In the source domain, Figure 4 The target domain is the PCIe domain on the left side of the middle. Figure 4 In the right PCIe domain, a host in the source domain accesses non-transparent Bridge 0 in the source domain through upstream switch port A and the routing module. Non-transparent Bridge 0 in the source domain accesses non-transparent Bridge 1 in the target domain through the routing module, the transport bridge, and the routing module in the target domain. Non-transparent Bridge 1 in the target domain accesses host B through the routing module and upstream switch port B.

[0121] Figure 5 A diagram showing how an endpoint device in the source domain accesses a host in the target domain. Figure 5 In the source domain, Figure 5 The target domain is the PCIe domain on the left side of the middle. Figure 5 In the right PCIe domain, endpoint device 0 in the source domain accesses non-transparent bridge 0 in the source domain via the downstream switch port and two routing modules. Non-transparent bridge 0 in the source domain accesses non-transparent bridge 1 in the target domain via the routing module within the domain, the transport bridge, and the routing module in the target domain. Non-transparent bridge 1 in the target domain accesses host B via the routing module and upstream switch port B.

[0122] Figure 6 Diagram showing how endpoint devices in the source domain access endpoint devices in the target domain. Figure 6 In the source domain, Figure 6 The target domain is the PCIe domain on the left side of the middle. Figure 6The right PCIe domain in the middle. The endpoint device 0 in the source domain accesses the non-transparent bridge 0 in the source domain through the downstream switching port and two routing modules in sequence. The non-transparent bridge 0 in the source domain accesses the non-transparent bridge 1 in the target domain through the routing module, transmission bridge, and routing module in the target domain within the domain. The non-transparent bridge 1 in the target domain accesses the endpoint device 2 through two routing modules and the downstream switching port in sequence.

[0123] Figure 7 It is a schematic diagram of four data paths in a non-transparent bridge. In Figure 7 it, the non-transparent bridge includes a configuration management module, a request message unpacking module, a response message unpacking module, a distribution module, an arbitration module, a source-end request management module, a source-end address calculation module, a source-end request packet assembly module, a target-end request management module, a target address calculation module, a target-end request packet assembly module, a source-end response management module, a source-end response packet assembly module, a target-end response management module, and a target-end response packet assembly module.

[0124] Among them, the configuration management module, the request message unpacking module, the response message unpacking module, the distribution module, and the arbitration module belong to general public modules. Configuration management module: This module is mainly responsible for the configuration of the relationship between the source domain and the target domain by the central processing unit (CPU) through the configuration interface, including the identity identifiers of the source domain and the target domain, as well as the mapping relationship between the source-end address and the destination-end address. Each message unpacking module: This part includes request message unpacking and response message unpacking, and obtains various necessary information of the message by parsing the data header of the PCIe message. Distribution module: This module is mainly responsible for determining whether the message belongs to the source domain or the target domain, and then making a distribution for the subsequent data flow and processing. Arbitration module: This module is mainly responsible for arbitrating multiple output data and selecting one path to output the source-end message and the target-end message.

[0125] In Figure 7 it contains four data paths, namely the source-end request message path, the target-end request message path, the source-end response message path, and the target-end response message path. The following will introduce each data path in combination with the modules corresponding to each data path.

[0126] The source-end request message path is mainly responsible for processing source-end request message data and includes the following modules.

[0127] 1) Source-end request management module: This module is mainly responsible for managing information such as the identity and sequence number of source-end data (such as memory access information), and determining the identity of the target end according to the mapping rule from the source-end address to the destination-end address.

[0128] 2) Source address calculation module: This module is mainly responsible for preprocessing and calculating the source address, and calculating the source address offset according to the mapping rule from the source address to the destination address.

[0129] 3) Source request packet assembly module: This module is mainly responsible for integrating all the previous processing procedures at the source end and carrying the transmission information required from the source end to the destination end.

[0130] Destination request message path: It is mainly responsible for processing the destination request message data and includes the following modules.

[0131] 1) Destination request management module: This module is mainly responsible for managing information such as the identity and sequence number of the destination data (such as the received source request message).

[0132] 2) Destination address calculation module: This module is mainly responsible for performing final processing and calculation on the destination address, and calculating the destination address according to the mapping rule from the source address to the destination address through the base address of the destination domain and the source address offset.

[0133] 3) Destination request packet assembly module: This module is mainly responsible for integrating all the previous processing procedures at the destination end.

[0134] Source response message path: It is mainly responsible for processing the source response message data and includes the following modules.

[0135] 1) Source response management module: This module is mainly responsible for verifying and inverse mapping information such as the identity and sequence number of the source data (the received response message returned by the cross-domain non-transparent bridge).

[0136] 2) Source response packet assembly module: This module is mainly responsible for integrating the previous processing procedures at the source end.

[0137] Destination response message path: It is mainly responsible for processing the destination response message data and includes the following modules.

[0138] 1) Destination response management module: This module is mainly responsible for verifying and inverse mapping information such as the identity and sequence number of the destination data (such as the response message returned by the device in the domain).

[0139] 2) Destination response packet assembly module: This module is mainly responsible for integrating the previous processing procedures at the destination end and carrying the transmission information required from the destination end to the source end.

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

[0141] In an embodiment of the present application, a cross-domain communication device is further provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0142] This embodiment provides a cross-domain communication device, as Figure 8 shown, including: A first receiving module 801, configured to receive memory access information sent by a first device; An identification module 802, configured to identify whether the first device is a device across the Peripheral Component Interconnect Express (PCIe) domain according to first identification information corresponding to the first device included in the memory access information; An address mapping module 803, configured to perform cross-domain address mapping on the memory access information to generate a source-end request message when the first device is not a device across the PCIe domain; A sending module 804, configured to send the source-end request message to a second non-transparent bridge within the target PCIe domain corresponding to the memory access information through a transmission bridge, so that the second non-transparent bridge feeds back the memory access information to a second device; A second receiving module 805, configured to receive, through the transmission bridge, an initial response message fed back by the second device according to the memory access information forwarded by the second non-transparent bridge; A generating module 806, configured to generate a final response message according to the initial response message, the first identification information, and second identification information corresponding to the second device, and return the final response message to the first device.

[0143] In a possible implementation manner, the address mapping module 803 is specifically configured to determine third identification information corresponding to the target PCIe domain according to a source-end address in the memory access information and at least one preset cross-domain address mapping rule; Determine a source-end address offset corresponding to the memory access information according to the source-end address and a cross-domain address mapping rule corresponding to the third identification information; Generate a source-end request message according to the source-end address offset and the memory access information.

[0144] In a possible implementation, the cross-domain address mapping rule includes a source address range and identification information corresponding to the Peripheral Component Interconnect Express (PCIe) domain; specifically, the address mapping module 803 is configured to determine the source address range where the source address is located according to the source address range included in each cross-domain address mapping rule, and use the cross-domain address mapping rule corresponding to the source address range where the source address is located as the target cross-domain address mapping rule; Extract the identification information corresponding to the Peripheral Component Interconnect Express (PCIe) domain from the target cross-domain address mapping rule as the third identification information corresponding to the target Peripheral Component Interconnect Express (PCIe) domain.

[0145] In a possible implementation, the generating module 806 is further configured to generate a status code corresponding to the initial response message when the request correlation identifier in the initial response message is consistent with the request correlation identifier corresponding to the memory access information, so as to subsequently generate a final response message according to the response data in the initial response message, the request correlation identifier of the initial response message, the status code, the first identification information, and the second identification information.

[0146] In a possible implementation, when the first device is a device across Peripheral Component Interconnect Express (PCIe) domains, the address mapping module 803 is further configured to perform cross-domain address mapping on the memory access information to generate a destination request message; the sending module 804 is further configured to send the destination request message to a third device in the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located.

[0147] In a possible implementation, the address mapping module 803 is specifically configured to extract the source address offset in the memory access information; Generate a destination request message based on the source address offset in the memory access information and the base address of the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located.

[0148] In a possible implementation, the address mapping module 803 is specifically configured to determine the destination address corresponding to the memory access information based on the source address offset in the memory access information and the base address of the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located; Generate a destination request message based on the destination address and the memory access information.

[0149] In a possible implementation, the first receiving module 801 is further configured to receive a response message fed back by the third device; the sending module 804 is further configured to send the response message fed back by the third device to a third non-transparent bridge within the Peripheral Component Interconnect Express (PCIe) domain through a transmission bridge when the request correlation identifier in the response message fed back by the third device is consistent with the request correlation identifier corresponding to the memory access information.

[0150] In a possible implementation, when the first non-transparent bridge receives memory access information sent by multiple devices and generates source-side request messages respectively corresponding to each device, the sending module 804 is specifically configured to route each source-side request message to the transmission bridge through an arbitration method; Use the transmission bridge to transmit each source-side request message to the non-transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to each source-side request message.

[0151] In a possible implementation, the sending module 804 is specifically configured to determine the access priority of each device based on the identification information of the devices in each memory access information; According to the access priority of each device, sequentially send the source-side request messages corresponding to each device to the transmission bridge.

[0152] In a possible implementation, the sending module 804 is specifically configured to determine the routing order of each source-side request message based on the load data of the non-transparent bridge within the target domain corresponding to each source-side request message; According to the routing order of each source-side request message, send each source-side request message to the transmission bridge.

[0153] In a possible implementation, within the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located, in addition to the first non-transparent bridge, there is at least one non-transparent bridge. When the first non-transparent bridge receives memory access information sent by multiple devices, the device further includes: An acquisition module, configured to acquire the load data of each non-transparent bridge; The sending module 804 is further configured to send each memory access information to each non-transparent bridge according to the load data of each non-transparent bridge, so that each non-transparent bridge performs cross-domain address mapping on the memory access information to generate a source-side request message corresponding to the memory access information.

[0154] With the device provided by the embodiments of the present application, non-transparent bridges located in different domains are connected through a transmission bridge. The transmission bridge overcomes the physical and logical limitations between PCIe domains in the related art, enabling newly added non-transparent bridges and in-domain devices to be conveniently connected to each PCIe domain when a new PCIe domain is added, without the need for large-scale modification of the original architecture, thus meeting the scalability requirements. In addition, in terms of wiring, the introduction of the transmission bridge simplifies complex physical connections, reduces the quantity and complexity of direct wiring between non-transparent bridges, saves hardware space and wiring costs, making the overall architecture of multiple PCIe domains more concise and clear, and enhancing the practicality of cross-domain access. In the present application, non-transparent bridges in each domain are used to perform cross-domain address mapping on memory access information, effectively solving the problem of address space isolation for cross-domain memory access, ensuring the accuracy and reliability of data transmission, enabling devices in different PCIe domains to access each other and cooperate, and giving full play to the advantages of heterogeneous computing.

[0155] For the description of the features in the corresponding embodiments of the cross-domain communication device, reference can be made to the relevant description in the corresponding embodiments of the cross-domain communication method, which will not be elaborated here one by one.

[0156] Embodiments of the present application also provide an electronic device, as Figure 9 shown, including a memory 10 and a processor 20. A computer program is stored in the memory 10, and the processor 20 is configured to run the computer program to execute the steps in any of the above cross-domain communication method embodiments.

[0157] Embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above cross-domain communication method embodiments when running.

[0158] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disks, magnetic disks, or optical discs and other media that can store computer programs.

[0159] Embodiments of the present application also provide a computer program product. The above computer program product includes a computer program, and the computer program realizes the steps in any of the above cross-domain communication method embodiments when executed by a processor.

[0160] Embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and the computer program realizes the steps in any of the above cross-domain communication method embodiments when executed by a processor.

[0161] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner 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 to exceed the scope of this application.

[0162] The above has introduced in detail a cross-domain communication method, an electronic device, and a medium provided by this application. Specific examples are used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can also be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A cross-domain communication method, characterized in that, Applied to a cross - domain communication system, the system includes a plurality of non - transparent bridges, each of the non - transparent bridges is located in a different Peripheral Component Interconnect Express (PCIe) domain, and each of the non - transparent bridges is connected through a transmission bridge. The method is executed by a first non - transparent bridge, and the first non - transparent bridge is any one of the plurality of non - transparent bridges. The method includes: Receiving memory access information sent by a first device; Identifying whether the first device is a device across Peripheral Component Interconnect Express (PCIe) domains according to first identification information corresponding to the first device included in the memory access information; When the first device is not a device across Peripheral Component Interconnect Express (PCIe) domains, performing cross - domain address mapping on the memory access information to generate a source - side request message; Sending the source - side request message through the transmission bridge to a second non - transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to the memory access information, so that the second non - transparent bridge feeds back the memory access information to a second device; Receiving, through the transmission bridge, an initial response message forwarded by the second non - transparent bridge and fed back by the second device according to the memory access information; Generating a final response message according to the initial response message, the first identification information, and second identification information corresponding to the second device, and returning the final response message to the first device.

2. The method according to claim 1, characterized in that The step of, when the first device is not a device across Peripheral Component Interconnect Express (PCIe) domains, performing cross - domain address mapping on the memory access information to generate a source - side request message specifically includes: Determining third identification information corresponding to the target Peripheral Component Interconnect Express (PCIe) domain according to the source - side address in the memory access information and at least one preset cross - domain address mapping rule; Determining a source - side address offset corresponding to the memory access information according to the source - side address and the cross - domain address mapping rule corresponding to the third identification information; Generating the source - side request message according to the source - side address offset and the memory access information.

3. The method according to claim 2, wherein The cross - domain address mapping rule includes a source - side address range and identification information corresponding to a Peripheral Component Interconnect Express (PCIe) domain. The step of determining third identification information corresponding to the target Peripheral Component Interconnect Express (PCIe) domain according to the source - side address in the memory access information and at least one preset cross - domain address mapping rule includes: Determining the source - side address range where the source - side address is located according to the source - side address range included in each cross - domain address mapping rule, and using the cross - domain address mapping rule corresponding to the source - side address range where the source - side address is located as the target cross - domain address mapping rule; Extracting the identification information corresponding to the Peripheral Component Interconnect Express (PCIe) domain from the target cross - domain address mapping rule as the third identification information corresponding to the target Peripheral Component Interconnect Express (PCIe) domain.

4. The method according to claim 1, wherein Before generating the final response message according to the initial response message, the first identification information, and second identification information corresponding to the second device, and returning the final response message to the first device, the method further includes: When the request correlation identifier in the initial response message is consistent with the request correlation identifier corresponding to the memory access information, generate a status code corresponding to the initial response message, so as to subsequently generate a final response message based on the response data in the initial response message, the request correlation identifier of the initial response message, the status code, the first identifier information, and the second identifier information.

5. The method according to claim 1, wherein When the first device is a device in the Peripheral Component Interconnect Express (PCIe) domain, the method further includes: Perform cross-domain address mapping on the memory access information to generate a destination request message; Send the destination request message to a third device in the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located.

6. The method according to claim 5, wherein The performing cross-domain address mapping on the memory access information to generate a destination request message specifically includes: Extract the source address offset in the memory access information; Generate the destination request message based on the source address offset in the memory access information and the base address of the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located.

7. The method according to claim 6, characterized in that, The generating the destination request message based on the source address offset in the memory access information and the base address of the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located specifically includes: Determine the destination address corresponding to the memory access information based on the source address offset in the memory access information and the base address of the Peripheral Component Interconnect Express (PCIe) domain where the first non-transparent bridge is located; Generate the destination request message based on the destination address and the memory access information.

8. The method according to any one of claims 5 to 7, characterized in that, The method further includes: Receive a response message fed back by the third device; When the request correlation identifier in the response message fed back by the third device is consistent with the request correlation identifier corresponding to the memory access information, send the response message fed back by the third device to a third non-transparent bridge within the Peripheral Component Interconnect Express (PCIe) domain through the transmission bridge.

9. The method according to any one of claims 1-4, characterized in that, When the first non-transparent bridge receives memory access information sent by multiple devices and respectively generates source request messages corresponding to each device, the sending the source request messages to a second non-transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to the memory access information through the transmission bridge specifically includes: Route each source request message to the transmission bridge through an arbitration method; Use the transmission bridge to respectively transmit each source request message to a non-transparent bridge within the target Peripheral Component Interconnect Express (PCIe) domain corresponding to each source request message.

10. The method according to claim 9, wherein The routing each source request message to the transmission bridge through an arbitration method specifically includes: Determine the access priority of each device based on the identifier information of the devices in each memory access information; According to the access priority of each device, sequentially send the source request messages corresponding to each device to the transmission bridge.

11. The method according to claim 9, wherein The routing each source request message to the transmission bridge through an arbitration method specifically includes: Determine the routing order of each of the source - side request messages based on the load data of the non - transparent bridges within the target domain corresponding to each of the source - side request messages; Send each of the source - side request messages to the transmission bridge according to the routing order of each of the source - side request messages.

12. The method according to any one of claims 1-4, characterized in that, Within the Peripheral Component Interconnect Express (PCIe) domain where the first non - transparent bridge is located, in addition to the first non - transparent bridge, there are at least one non - transparent bridge. When the first non - transparent bridge receives memory access information sent by multiple devices, the method further includes: Obtain the load data of each of the non - transparent bridges; Send each of the memory access information to each of the non - transparent bridges according to the load data of each of the non - transparent bridges, so that each of the non - transparent bridges respectively performs cross - domain address mapping on the memory access information to generate a source - side request message corresponding to the memory access information.

13. An electronic device, characterized in that, Comprising: A memory for storing a computer program; A processor for implementing the steps of the cross - domain communication method according to any one of claims 1 - 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that, A computer program is stored in the computer - readable storage medium, wherein the computer program, when executed by a processor, implements the steps of the cross - domain communication method according to any one of claims 1 - 12.

15. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the cross - domain communication method according to any one of claims 1 - 12.

Images