Core 2 Core data transmission method and system based on transmission protocol

Abstract

The embodiment of the invention discloses a Core 2 Core data transmission method and system based on a transmission protocol. The method comprises the following steps: when the current flow of shared storage equipment is greater than a preset flow threshold value and a function switch parameter of the shared storage equipment is set as a first numerical value, temporarily suspending receiving a read request newly sent by a node core, and determining the received read request; determining a target storage bank identifier corresponding to the received read request from the shared storage device, and obtaining a source node core identifier and a target node core identifier of the received read request; and when the source node core identifier is inconsistent with the target memory bank identifier, and the target memory bank identifier is also inconsistent with the target node core identifier, sending the request data in the target node core to the source node core by using a delay optimization protocol. The method can flexibly use the delay optimization protocol to process the read request by sharing the setting of the current traffic and the function switch parameters of the storage device, so that the efficient and flexible data transmission is realized, and the data processing process is optimized.

Description

Technical Field

[0001] This disclosure relates to the field of data transmission technology, and in particular to a Core 2 Core data transmission method and system based on a transmission protocol. Background Technology

[0002] As the demand for multi-core processors increases, the number of CPU cores that the LLC (Last Level Cache) needs to serve also increases. LLCs typically employ a multi-bank design and distributed directory management. In distributed directory management, the LLC processes the directory protocol and data before returning a response to the initiator. However, as the number of shared CPU cores increases, the data transfer latency between cores further increases, making core-to-core (C2C) performance particularly important.

[0003] Existing LLC designs experience further latency increases with increasing core count, routing distance, and LLC capacity, impacting bandwidth and increasing hardware overhead. If a traditional approach is adopted, where data and consistency state are transferred core-to-core simultaneously (i.e., when a read request originates from one kernel, and the data is in another kernel's private cache, requiring data transfer and consistency maintenance via LLC), then due to routing latency overhead, overall latency increases with the number of cores. To ensure equal bandwidth, more request buffers need to be allocated, further increasing hardware overhead and power consumption. Summary of the Invention

[0004] In view of this, the present disclosure provides a Core 2 Core data transmission method and system based on a transmission protocol, which can flexibly use a latency optimization protocol to process read requests by comparing the current traffic of the shared storage device with a preset traffic threshold and setting the function switch parameters, thereby achieving efficient and flexible data transmission and optimizing the data processing process.

[0005] In a first aspect, embodiments of this disclosure provide a Core 2 Core data transmission method based on a transmission protocol, employing the following technical solution: Configure the function switch parameters of the shared storage device. When the current traffic of the shared storage device is greater than the preset traffic threshold and the function switch parameters are set to the first value, the shared storage device temporarily suspends receiving new read requests sent by the node core and determines the read requests that have been received. Determine the target storage entity identifier corresponding to the read request received from the shared storage device, and obtain the source node core identifier and target node core identifier that have received the read request; When the source node core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node core identifier, the request data in the target node core is sent to the source node core using a delay optimization protocol.

[0006] Optionally, the Core 2 Core data transmission method based on the transport protocol further includes: When the shared storage device has finished processing all the received read requests, the function switch parameter is modified to the second value; When the function switch parameters are modified, the shared storage device receives new read requests and processes the read requests already received by the shared storage device using the original protocol.

[0007] Optionally, the function switch parameters for configuring the shared storage device include: In the chip, a software interface register is allocated to each shared memory device; Configure the function switch parameters of the shared storage device in the software interface register.

[0008] Optionally, the function switch parameters for configuring the shared storage device include: In a multi-threaded chip environment, independent registers are allocated for each thread; Configure the function switch parameters of the shared storage device that the thread is responsible for in the independent register.

[0009] Optionally, when the current traffic of the shared storage device is greater than a preset traffic threshold and the function switch parameter is a second value, the original protocol is used to process the read request received by the shared storage device. When the current traffic of the shared storage device is less than or equal to the preset traffic threshold, and the function switch parameter is the second value, the function switch parameter is modified to the first value.

[0010] Optionally, when the source node core identifier is the same as the target storage identifier, or when the target storage identifier is the same as the target node core identifier, the original protocol is used to process the read request received by the shared storage device.

[0011] Optionally, sending the requested data from the target node core to the source node core using a latency optimization protocol includes: The snooping mechanism sends the request data and status information from the target node core to the source node core along different paths, and obtains the response from the source node core.

[0012] Optionally, the step of sending the request data and request status information from the target node core to the source node core along different paths through the eavesdropping mechanism, and obtaining the response from the source node core, includes: Send a listening request from the target storage that has received the read request to the core of the target node that has received the read request; After receiving the probe request, the target node core determines the nearest storage, sends the request data and delay status to the nearest storage, and simultaneously sends the probe status to the target storage. The routing path of the nearest storage unit sends the received request data and delay status to the source node core; After receiving the delayed status, the source node core waits to receive the read response status. After receiving the probe status, the target storage device sends the read response status to the source node core. After receiving the request data and the read response status, the source node core sends a read response handshake to the target storage.

[0013] Optionally, processing read requests received by the shared storage device using the original protocol includes: Send a listening request from the target storage that has received the read request to the core of the target node that has received the read request; After receiving the eavesdropping request, the target node core will send the request data to the target storage. The target storage unit sends the received request data and read response status to the source node core; After receiving the request data and the read response status, the source node core sends a read response handshake to the target storage.

[0014] Secondly, embodiments of this disclosure also provide a Core 2 Core data transmission system based on a transmission protocol, the system including registers and a shared storage device; The register is used to configure the function switch parameters of the shared storage device; The shared storage device is used to temporarily suspend receiving new read requests sent by the node core and determine the already received read requests when the current traffic exceeds a preset traffic threshold and the function switch parameter is set to a first value. Determine the target storage identifier corresponding to the received read request, and obtain the source node core identifier and target node core identifier of the received read request; Determine the target storage identifier corresponding to the received read request, and obtain the source node core identifier and target node core identifier of the received read request; When the source node core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node core identifier, the request data in the target node core is sent to the source node core using a delay optimization protocol.

[0015] Optionally, the register is further configured to modify the function switch parameter to a second value when the shared storage device has completed processing all received read requests; The shared storage device is also configured to receive new read requests and process the read requests received by the shared storage device using the original protocol when the function switch parameters are modified.

[0016] Optionally, the register is a software interface register; The software interface register is used to configure the function switch parameters of the dedicated shared storage device.

[0017] Optionally, the register is an independent register; The independent register is used to configure the function switch parameters of the shared storage device that is managed by a dedicated thread.

[0018] Optionally, the shared storage device is further configured to process read requests received by the shared storage device using the original protocol when the current traffic of the shared storage device is greater than a preset traffic threshold and the function switch parameter is a second value. The register is also used to modify the function switch parameter to the first value when the current traffic of the shared storage device is less than or equal to a preset traffic threshold and the function switch parameter is a second value.

[0019] Optionally, the shared storage device is further configured to process read requests received by the shared storage device using the original protocol when the source node core identifier is consistent with the target storage identifier, or the target storage identifier is consistent with the target node core identifier.

[0020] Optionally, by using a snooping mechanism, the request data and request status information in the target node core are sent to the source node core along different paths, and the response from the source node core is obtained.

[0021] Optionally, the target storage is used to send a listening request to the target node core that has received the read request; The target node core is used to determine the nearest storage after receiving the probe request, send the request data and delay status to the nearest storage, and at the same time send the probe status to the target storage. The most recent storage is used to send the received request data and delay status to the source node core through the routing path; The source node core is used to wait for the read response status after receiving the delayed status; The target storage is also used to send a read response status to the source node core after receiving the probe status; The source node core is also used to send a read response handshake to the target storage after receiving the request data and the read response status.

[0022] Optionally, the target storage is used to send a listening request to the target node core that has received the read request; The target node core is used to send the request data to the target storage after receiving the eavesdropping request; The target storage is used to send the received request data and read response status to the source node core; The source node core is used to send a read response handshake to the target storage after receiving the request data and the read response status.

[0023] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of any of the methods described above.

[0024] The Core 2 Core data transmission method based on a transmission protocol provided in this disclosure has intelligent traffic management capabilities. By configuring the function switch parameters of the shared storage device and combining them with a preset traffic threshold, when the current traffic of the shared storage device exceeds the preset traffic threshold and the function switch parameter is at a first value, the receiving node core temporarily suspends new read requests. This measure can effectively avoid overload of the shared storage device due to excessive traffic, prevent the system from experiencing performance degradation or even crashing due to processing too many requests, and ensure the stable operation of the shared storage device. The method also achieves precise optimization in data transmission. After determining the target storage identifier, source node core identifier, and target node core identifier corresponding to the received read request, when the source node core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node core identifier, a latency optimization protocol is used to send the request data in the target node core to the source node core. This precise judgment and targeted protocol use can reduce unnecessary data transmission paths, improve data transmission efficiency, reduce data transmission latency, and thus improve the data processing speed of the entire system.

[0025] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0027] Figure 1 A schematic flowchart illustrating the Core 2 Core data transmission method based on a transport protocol provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating the function switch parameter configuration method provided in this embodiment of the disclosure; Figure 3 This is another schematic flowchart illustrating the method for configuring function switch parameters provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating the implementation method of the delay optimization protocol provided in this embodiment of the disclosure; Figure 5 A flowchart illustrating the original protocol implementation method provided in this embodiment of the disclosure; Figure 6 A comparison diagram of the original protocol and the delay-optimized protocol provided for embodiments of this disclosure; Figure 7 A schematic diagram of the structure of a Core 2 Core data transmission system with a multi-core shared LLC provided in an embodiment of this disclosure; Figure 8 A schematic diagram of the structure of a Core 2 Core data transmission system based on a transmission protocol provided in an embodiment of this disclosure. Detailed Implementation

[0028] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0029] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0030] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0031] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0032] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0033] Reference Figure 1 This disclosure provides a Core 2 Core data transmission method based on a transport protocol, including the following steps: S1: Configure the function switch parameters of the shared storage device. When the current traffic of the shared storage device is greater than the preset traffic threshold and the function switch parameter is set to the first value, the shared storage device temporarily suspends receiving new read requests sent by the node core and confirms the read requests that have been received. S2: Determine the target storage identifier corresponding to the received read request from the shared storage device, and obtain the source node core identifier and target node core identifier of the received read request; S3: When the source node core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node core identifier, the delay optimization protocol is used to send the requested data in the target node core to the source node core. S4: When the current traffic of the shared storage device is less than or equal to the preset traffic threshold, the function switch parameter is modified to the second value, the shared storage device receives new read requests, and uses the original protocol to process the read requests already received by the shared storage device.

[0034] Among them, the function switch parameters can be in Boolean form, so the first value can be 0 and the second value can be 1; the storage can be a specific storage unit or storage space.

[0035] Chip systems typically have multiple nodes, usually CPUs. Each node has its own core. These cores need to share data. During data sharing, reading data consumes a lot of time and hardware resources, and may also face problems such as high write latency and difficulty in maintaining data consistency. If traditional solutions are used, the overall latency will increase with the number of cores due to routing latency overhead. To ensure equal bandwidth, more request buffers will be allocated, which will further increase hardware overhead and power consumption.

[0036] Therefore, the Core 2 Core data transmission method based on the transmission protocol provided in this disclosure has intelligent traffic management capabilities. By configuring the function switch parameters of the shared storage device and combining them with a preset traffic threshold, when the current traffic of the shared storage device exceeds the preset traffic threshold and the function switch parameter is at the first value, the receiving node core suspends new read requests. This measure can effectively avoid the shared storage device from becoming overloaded due to excessive traffic, prevent the system from experiencing performance degradation or even crashing due to handling too many requests, and ensure the stable operation of the shared storage device.

[0037] This method also achieves precise optimization in data transmission. After determining the target memory identifier, source node core identifier, and target node core identifier corresponding to the received read request, when the source node core identifier is inconsistent with the target memory identifier, and the target memory identifier is also inconsistent with the target node core identifier, a latency optimization protocol is used to send the requested data in the target node core to the source node core. This precise judgment and targeted protocol use can reduce unnecessary data transmission paths, improve data transmission efficiency, reduce data transmission latency, and thus improve the overall system's data processing speed.

[0038] This method also exhibits strong adaptability. When the shared storage device has processed all received read requests, the function switch parameter is modified to its second value. Once the function switch parameter is modified, the delay optimization protocol is disabled, and the shared storage device receives new read requests while processing the previously received requests using the original protocol. This allows the system to flexibly adjust its operating strategy based on actual traffic conditions, fully utilizing system resources to handle more requests. This achieves rational allocation and efficient utilization of system resources, further improving the overall performance and stability of the system.

[0039] In S1, due to differences in the internal design of the chips, the function switch parameters need to be configured according to the appropriate chip design. In the first configuration scheme, refer to... Figure 2 The flowchart illustrating the function switch parameter configuration method shows that "Configuring the function switch parameters of the shared storage device" includes the following steps: S11: In the chip, a software interface register is allocated for each shared memory device; S12: Configure the function switch parameters of the shared storage device in the software interface register.

[0040] In chip systems, to achieve flexible control over the functions of shared storage devices, a scheme is adopted where a software interface register is allocated to each shared storage device, and function switch parameters are configured within it. The configuration of these function switch parameters can be achieved through software settings on the software interface register corresponding to each shared storage device. The software writes specific parameter values ​​into the register based on system operational requirements and management strategies, thereby controlling the operating state of the shared storage device. This function switch parameter configuration scheme is suitable for chips with high requirements for real-time performance and flexibility.

[0041] There are three approaches to dynamically modifying function switch parameters. The first is for the shared storage device to read the function switch parameters from its registers in real time. The control circuitry inside the shared storage device reads the corresponding registers at regular clock cycles. This approach offers strong autonomy, simple logic, and timely response to parameter changes. The second approach uses threads to send signals. The system creates a dedicated monitoring thread that periodically checks the software interface registers of all shared storage devices. When a change in the function switch parameter of a register is detected, the thread sends a signal to the corresponding shared storage device. This approach is suitable for multi-device, multi-tasking chip systems, enabling centralized management and complex logic processing. The third approach involves direct signal transmission between the two devices. During chip design, a dedicated signal transmission line is established between the software interface register of each shared storage device and the device itself. When the software modifies the register parameters, the register immediately sends a signal to the device through the line. The device receives the signal and adjusts its state. This approach offers fast response speed, high hardware integration, and meets the needs of applications with high real-time requirements.

[0042] In the second configuration scheme, refer to Figure 3 Another flowchart illustrating the function switch parameter configuration method shows that "Configuring the function switch parameters of a shared storage device" includes the following steps: S13: In a multi-threaded chip environment, an independent register is allocated for each thread; S14: Configure the function switch parameters of the shared memory device that the thread is responsible for in a separate register.

[0043] The above-described function switch parameter configuration scheme allocates an independent register to each thread, and configures the function switch parameters of the shared memory device that each thread is responsible for in these independent registers. The software sets the parameter values ​​according to system operating requirements and management strategies. This function switch parameter configuration scheme is suitable for chips with multi-threaded parallel processing requirements.

[0044] There are three schemes to achieve dynamic modification of function switch parameters. Considering that a thread is responsible for more than one shared storage device and there are multiple corresponding function switch parameters configured in the independent registers, the first scheme is to read the function switch parameters of the registers of the shared storage device in real time. The control module of the shared storage device will read the independent registers of the associated thread according to a fixed time period (e.g., every clock cycle). Since the independent registers contain the function switch parameters of multiple shared storage devices that the thread is responsible for, the control module will read the parameters corresponding to each device in turn. When a change is detected in the function switch parameter corresponding to a certain shared storage device, the shared storage device can be notified in time. This scheme is highly autonomous and has simple logic. It is suitable for scenarios with high response speed requirements and relatively simple logic, because the device can autonomously obtain parameters in real time and respond quickly without complex intermediate links. Option two involves threads directly responding to and controlling shared storage devices. When a thread receives a read request to be sent to the shared storage device it is responsible for, it shares the current traffic of the storage device and modifies the function switch parameters in the independent registers. Since the independent registers contain the function switch parameters of multiple shared storage devices that the thread is responsible for, after the function switch parameters are changed, the thread will send a notification of the parameter change to the corresponding shared storage device through specific communication mechanisms, such as internal message queues or hardware interrupt signals. Upon receiving the notification, the shared storage device will immediately read the latest function switch parameters in the independent registers and adjust its own working state according to the parameter values. This option allows threads to flexibly control shared storage devices according to the actual situation, achieving more granular resource management and task scheduling, and is suitable for chip designs that need to handle complex logic and dynamically changing scenarios. Option three involves signal transmission between the two to determine changes in function switch parameters. During the chip design phase, dedicated hardware signal transmission lines are designed for each thread's independent register and the multiple shared memory devices it is responsible for. When the software modifies the function switch parameters of one or more shared memory devices in the independent register, the register will immediately send a signal indicating the parameter change to the relevant shared memory device through the corresponding hardware signal line. After receiving the signal, each shared memory device will adjust its state accordingly based on the signal content. This option has a fast response speed and high hardware integration, making it suitable for applications with extremely high real-time requirements, because the hardware signal lines can ensure that the information on parameter changes is quickly and accurately transmitted to the device.

[0045] When the chip system is powered on, the function switch parameters of the shared storage device are initialized. The function switch parameters are initially set to the first value. The traffic monitoring module (such as a dedicated monitoring thread, central controller, etc.) monitors the current traffic of the shared storage device in real time. The current traffic = (current read / write operation volume - previous read / write operation volume) / sampling time interval. The traffic monitoring module can be configured inside the shared storage device or externally connected to the shared storage device.

[0046] When the current traffic of the shared storage device is less than or equal to the preset traffic threshold, the register maintains the current value of the function switch parameter as the first value or modifies the function switch parameter, which is the second value, to the first value. When the current traffic of the shared storage device is greater than the preset traffic threshold, it is determined whether the function switch parameter is the second value. If it is the second value, the original protocol is used to process the read requests already received by the shared storage device, and the current traffic of the shared storage device continues to be monitored. If it is the first value, the shared storage device temporarily suspends receiving new read requests sent by the node core and determines the read requests already received. This is the operation of configuring the shared storage device to Stall, requiring the shared storage device to stop read requests that have not yet entered the pipeline and only process all currently in-flight read requests.

[0047] In S2, during distributed management, the shared storage device comprises multiple banks. A node core needing to access shared data sends a read request to the nearest bank, which is the target bank. The process of "determining the target bank identifier corresponding to the received read request from the shared storage device" can be achieved as follows: The bank identifier is compared with the source node core identifier. A search is conducted for banks whose identifiers are completely identical to the source node core identifier (i.e., the node sending the read request), or whose identifiers partially match at a preset location (e.g., certain bits are identical). The identifier corresponding to the bank meeting this condition is determined as the target bank identifier, where "identifier" refers to an ID. This method ensures efficient and accurate location of the target bank in complex distributed systems, meeting the node's need to access shared data.

[0048] The source node core identifier is obtained from the read request data packet. The read request is issued by the source node core, and its data packet format predefines the source node core identifier field. Upon receiving a read request, the data packet is parsed, and the source node core identifier is extracted from the corresponding field. This identifier is usually a unique number used to identify different core nodes in the system.

[0049] In distributed systems, the method for determining the target node core identifier is closely related to the system's strategy. This solution presents two different scenarios. First, when the read request explicitly specifies the target node core, the operation is relatively straightforward. Only data packet parsing is needed to obtain the target node core identifier, as the read request already contains complete target information. Parsing the data packet accurately identifies the target node core, allowing the system to quickly direct the request to that core for processing. Second, when the read request only specifies the data requirement, the system needs to further determine which node core possesses this data. This requires the system to query and match among numerous node cores. This can be achieved by maintaining a data distribution mapping table, recording the data range and identifier stored by each node core. When a read request is received, the system searches the mapping table for a matching node core based on the data requirement in the request. Furthermore, techniques such as distributed hash tables can be used to optimize the search process and improve the efficiency of determining the target node core. Once the node core possessing the required data is identified, its identifier becomes the target node core identifier, and the system forwards the read request to that core to complete the data reading operation. By flexibly utilizing these two methods for determining the core identifier of the target node, the system can efficiently and accurately direct requests to the appropriate node core based on the characteristics of different read requests, thereby improving the data reading performance and response speed of the entire distributed system.

[0050] In S3, the shared storage device determines whether the source node core identifier and the target storage identifier are consistent, and whether the target storage identifier and the target node core identifier are consistent. Based on the principle of shortest distance transmission, if the source node core identifier and the target storage identifier are completely identical or have the same content at a preset position, then the source node core identifier and the target storage identifier are considered to be consistent; otherwise, they are considered to be inconsistent.

[0051] When a shared storage device determines that the source node core identifier and the target storage identifier are inconsistent, and the target storage identifier and the target node core identifier are also inconsistent, it uses a latency optimization protocol to send the requested data from the target node core to the source node core. This latency optimization protocol uses a snooping mechanism to send the requested data and request status information from the target node core to the source node core along different paths, and obtains the response from the source node core. (See reference...) Figure 4 The flowchart illustrating the implementation method of the latency optimization protocol shows that "sending the request data from the target node core to the source node core using the latency optimization protocol" includes the following steps: S31: Send a probe request to the core of the target node that has received the read request through the target storage that has received the read request; S32: After receiving the probe request, the target node core sends the request data and delay status to the source node core. At the same time, it determines the nearest storage and sends the probe status to the nearest storage. S33: After receiving the delayed status, the source node core waits to receive the read response status; S34: After receiving the probe status, the most recent memory cell sends the read response status to the source node core; S35: After receiving the request data and read response status, the source node core sends a read response handshake to the target storage.

[0052] In the above steps, the target storage system will send a listening request to the target node core. In actual implementation, network communication protocols, such as TCP / IP, can be used to encapsulate the listening request into a data packet for transmission. The data packet should contain relevant information about the read request, such as the requested data identifier and the identifier of the source node core, so that the target node core can accurately identify the request content.

[0053] Upon receiving a probe request, the target node core begins processing it. It retrieves the requested data from local storage or other pre-defined storage locations and generates a deferred state. The deferred state is a simple identifier, which can be numerically represented, indicating that the current state is inaccurate and awaits the true state. It informs the source node core that data consistency processing will take some time. The target node core queries the nearest storage unit (i.e., the storage unit with the same identifier as the target node core or containing the same content at a pre-defined location). The target node core sends the requested data and deferred state to the nearest storage unit via network communication. The nearest storage unit then forwards the requested data and deferred state to the source node core via its routing path. Simultaneously, the target node core sends a probe state to the target storage unit. The probe state is a set of information that the target node core sends back to the target storage unit after receiving the probe request and completing a series of operations. It includes the target node core's processing status of the requested data, the current data status, and the progress of related operations. Upon receiving the probe state, the target storage unit uses this information to process the data consistency status. Data consistency status refers to the degree of consistency between the same data replicas stored across different storage nodes in a distributed environment. Because data may exist in multiple replicas distributed across different storage nodes, inconsistencies may arise during data read and write operations. For example, one replica might update data while others fail to do so. By analyzing the monitoring status, the target storage unit can determine whether the current data replicas are consistent and then take appropriate measures to ensure data consistency, such as performing data synchronization or updating outdated replicas, thereby ensuring the accuracy and reliability of data throughout the system.

[0054] Upon receiving a delayed status, the source node core enters a waiting state. During this waiting period, the source node core can set a timer to avoid indefinite waiting. The timer duration can be set based on system performance and empirical values. The source node core continuously listens to the network port, waiting for the arrival of a read response status.

[0055] After receiving the probe status sent by the target node core, the target storage unit parses it. Based on the information in the probe status, the target storage unit determines whether it can provide a read response. If it can, the target storage unit encapsulates the read response status into a data packet and sends it to the source node core via the network. The read response status may contain information such as data availability and data status.

[0056] Once the source node core receives the requested data and read response status, it indicates that the data reading process is essentially complete. The source node core will verify the requested data and read response status to ensure the integrity and correctness of the data. If the verification passes, the source node core will send a read response handshake message to the target storage. The read response handshake message can be a simple acknowledgment signal used to inform the target storage that the data has been successfully received. After receiving the read response handshake, the target storage can perform subsequent cleanup tasks, such as releasing related resources.

[0057] By implementing the above steps, the entire read request processing process can be completed, ensuring that data can be accurately and efficiently transferred from the storage to the source node core. By quickly locating the target storage and the nearest storage to the target node core, and through a reasonable information transmission path, unnecessary waiting and data transmission latency are reduced. The target node core can efficiently transmit the requested data to the source node core via the nearest storage, reducing the source node core's waiting time for the requested data. Furthermore, by handling the snooping state and data consistency state, the consistency of data replicas in a distributed environment is guaranteed, avoiding erroneous reads or system failures caused by data inconsistency, further improving the system's stability and reliability, and providing stable and accurate data support to the source node core to meet its business needs.

[0058] In S4, when the shared storage device determines that the source node core identifier matches the target storage identifier, or the target storage identifier matches the target node core identifier, it uses the original protocol to process the read request received by the shared storage device. (Refer to...) Figure 5 The flowchart illustrating the original protocol implementation method shows that "processing read requests received by a shared storage device using the original protocol" includes the following steps: S41: Send a probe request to the core of the target node that has received the read request through the target storage that has received the read request; S42: After receiving the probe request, the target node core will send the request data to the target storage. S43: The target storage unit sends the received request data and read response status to the source node core; S44: After receiving the request data and read response status, the source node core sends a read response handshake to the target storage.

[0059] In the above scheme, when the target storage receives a read request, it sends a listener request to the target node core. Upon receiving the listener request, the target node core parses the request, extracts the data identifier, and then searches for the corresponding requested data based on that identifier. During the search, data cache checks are involved. If the data exists in the cache, it is retrieved directly from the cache to improve data retrieval speed; if it is not in the cache, it is read from a storage device such as a disk. After finding the requested data, the target node core sends it to the target storage via network communication, also using network communication protocols to encapsulate the data into data packets for transmission.

[0060] After receiving the request data from the target node core, the target storage device performs an integrity check to ensure the data is not corrupted during transmission. Simultaneously, it generates a read response status, which may include information such as whether the data was successfully acquired and the data version. The target storage device then encapsulates the request data and read response status together into a new data packet and sends it to the source node core over the network. Upon receiving the request data and read response status from the target storage device, the source node core verifies them. If verification is successful, the data read process is considered complete, and the source node core sends a read response handshake to the target storage device. Through these steps, the entire read request processing flow is completed, ensuring accurate and efficient data transmission from the storage device to the source node core.

[0061] Reference Figure 6 The comparison diagram of the original protocol and the latency optimization protocol shows that the original protocol applies with different logical considerations in two specific situations. When the current traffic of the shared storage device exceeds the preset traffic threshold and the function switch parameter is at the second value, it means that the device is operating under high load and the specific optimization function is not enabled. The original protocol, with its mature request processing flow, can orderly schedule and process read requests, avoiding chaos and congestion under high traffic, and ensuring the stability and accuracy of data transmission. However, when the current traffic of the shared storage device is less than or equal to the preset traffic threshold, and the source node core identifier is the same as the target storage identifier, or the target storage identifier is the same as the target node core identifier, this latency optimization is not enabled. In this case, the shared storage device is in a non-busy state or the data transmission path is relatively simple and direct, and the latency benefits are not enough to offset the overhead brought by the protocol. Using the standardized process of the original protocol, the data interaction rules and order between each node can be clearly defined, ensuring effective data transmission in this complex topology.

[0062] The latency optimization protocol is applicable when the current traffic of a shared storage device exceeds a preset traffic threshold, the function switch parameter is set to its first value, and the source node's core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node's core identifier. In this scenario, high traffic puts significant pressure on the device, but the function switch parameter being set to its first value indicates the need for specific optimization features. The inconsistency in node identifiers implies a relatively complex data transmission path. The latency optimization protocol can specifically optimize such complex paths, reducing unnecessary intermediate steps and processing steps, thereby effectively reducing data transmission latency and ensuring fast data retrieval even in high-traffic environments.

[0063] Figure 7 The left and right sides of the diagram represent the protocol processing before and after optimization, respectively. As shown in the diagram, the final point in time for obtaining the consistent state has not changed. However, in the optimized protocol processing, the node core can obtain valid data in advance and update the data storage unit of the kernel private cache, which shortens the time for obtaining data and improves the overall data flow.

[0064] For the selective enabling of protocol optimization strategies, dynamic configuration via configuration registers can be used depending on the specific scenario. Even if the latency gain at the transport layer decreases, the latency gains in this solution come from two parts: transport layer latency gains and protocol layer latency gains (i.e., the latency of consistency maintenance and directory updates). Therefore, the benefits of protocol layer latency can still be enjoyed. Users can configure registers to automatically select whether to enable the selective C2C latency optimization strategy based on current scenario requirements. Furthermore, since real-world application scenarios change with business needs—sometimes latency-sensitive, sometimes bandwidth-sensitive—this solution proposes introducing a combination of hardware and software optimization methods based on this C2C latency optimization scheme to address this requirement.

[0065] Shared storage devices can be LLC (Last-Level Cache, typically used for multi-core shared cache, with large capacity to reduce memory access latency), network-on-chip (NoC) buffer storage devices, or other storage devices. This solution is applicable to most types of on-chip memory. For example, using LLC and CPU Core: [Refer to...] Figure 7The diagram illustrates the structure of a Core 2 Core data transfer system for a multi-core shared LLC. In this architecture, the chip system contains multiple CPU cores, each with its own high-speed cache, such as L1 Cache and L2 Cache. When CPU0 initiates a read operation, due to the distributed management mechanism of the LLC, the address of the read request will fall within LLC.Bank2. At this point, the system queries Snoop directory 2 of LLC.Bank2 and then initiates a snoop operation to CPUn+1. For the original protocol, because the LLC requires consistency management, the data and status returned by CPUn+1 need to be transmitted back to LLC.Bank2 via the interconnection network. After Snoop directory 2 is updated, the data and consistency status are then returned to CPU0. As shown in the structure diagram, CPUn+1 is closest to LLC.Bank0. Returning data through the Minifabric architecture within LLC.Bank0 minimizes latency. Therefore, for this situation, a latency optimization protocol, illustrated by paths ①, ②, and ③, is adopted. This protocol, also known as the response def (deferred) protocol, proposes that CPUn+1 return response data and status via two separate paths. Path ① returns the acquired consistent status to LLC.Bank2 to ensure that LLC.Bank2 completes consistency management and directory updates. Path ② forwards the data directly to CPU0, using the RespDef status to indicate that a consistent system status has not yet been acquired. Finally, path ③ returns the consistent status to CPU0.

[0066] As illustrated by this example, this solution adds a new `responsedef` protocol to optimize Core 2 Core latency. By using physical IDs, Core 2 Core latency can be selectively enabled or disabled for requests with CPU IDs adjacent to LLC.Bank IDs. This increases hardware implementation flexibility while requiring almost no new hardware overhead, allowing for the reuse of existing channels. Furthermore, the combined hardware and software configuration approach enhances the solution's flexibility in real-world products, strengthens product competitiveness, and enables flexible adaptation to various applications. On the other hand, this patent has a wide range of applications and flexible configuration methods. The matching method between CPU ID and LLC.Bank ID is not limited to the two identification comparison methods mentioned in the text, and may also be determined by hash mapping or other methods. The storage structure is not limited to SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), eDRAM (Embedded Dynamic Random Access Memory), Disk, Flush, etc. are all possible. In the hardware and software combination strategy, the configuration method of registers is flexible. They can be configured by users, configured through firmware, or automatically configured by hardware, such as by patching. They can be used as open interfaces or the hardware can control the registers to achieve adaptive adjustment.

[0067] Reference Figure 8 This disclosure provides a Core 2 Core data transmission system based on a transmission protocol, the system including a register 101 and a shared storage device 102; Register 101 is used to configure the function switch parameters of shared storage device 102; Shared storage device 102 is used to temporarily suspend receiving new read requests sent by the node core and determine the read requests that have been received when the current traffic exceeds a preset traffic threshold and the function switch parameter is set to a first value. Determine the target storage identifier corresponding to the received read request, and obtain the source node core identifier and target node core identifier of the received read request; Determine the target storage identifier corresponding to the received read request, and obtain the source node core identifier and target node core identifier of the received read request; When the source node core identifier is inconsistent with the target storage identifier, and the target storage identifier is also inconsistent with the target node core identifier, the delay optimization protocol is used to send the request data in the target node core 103 to the source node core 104.

[0068] Furthermore, register 101 is also used to modify the function switch parameter to a second value when the shared storage device 102 has finished processing all the received read requests; The shared storage device 102 is also used to receive new read requests when the function switch parameters are modified, and to process the read requests received by the shared storage device 102 using the original protocol.

[0069] Furthermore, the register is a software interface register; The software interface register is used to configure the function switch parameters of the dedicated shared storage device 102.

[0070] Furthermore, the register is an independent register; An independent register is used to configure the function switch parameters of the shared storage device 102, which is managed by a dedicated thread.

[0071] Furthermore, the shared storage device 102 is also used to process the read request received by the shared storage device 102 using the original protocol when the current traffic of the shared storage device 102 is greater than a preset traffic threshold and the function switch parameter is a second value. Register 101 is also used to modify the function switch parameter to the first value when the current traffic of the shared storage device is less than or equal to a preset traffic threshold and the function switch parameter is a second value.

[0072] Furthermore, the shared storage device 102 is also used to process the read request received by the shared storage device 102 using the original protocol when the source node core identifier is consistent with the target storage identifier, or the target storage identifier is consistent with the target node core identifier.

[0073] Furthermore, the target storage 105 is used to send a listening request to the target node core 103 that has received the read request; The target node core 103 is used to determine the nearest storage 106 after receiving a probe request, send the requested data and delay status to the nearest storage 106, and at the same time send the probe status to the target storage 105. The most recent storage unit 106 is used to send the received request data and delay status to the source node core 104 via the routing path; The source node core 104 is used to wait for the read response status after receiving the delayed status; The target storage unit 105 is also used to send a read response status to the source node core 104 after receiving the snoop status; The source node core 104 is also used to send a read response handshake to the target storage 105 after receiving the request data and read response status.

[0074] Furthermore, the target storage 105 is used to send a listening request to the target node core 103 that has received the read request; The target node core 103 is used to send the request data to the target storage 105 after receiving the probe request; The target storage unit 105 is used to send the received request data and read response status to the source node core 104; The source node core 104 is used to send a read response handshake to the target storage 105 after receiving the request data and read response status.

[0075] The various variations and specific examples of the Core 2 Core data transmission method based on the transport protocol provided above are also applicable to the Core 2 Core data transmission system based on the transport protocol provided in this disclosure. Through the foregoing detailed description of the Core 2 Core data transmission method based on the transport protocol, those skilled in the art can clearly understand the implementation method of the Core 2 Core data transmission system based on the transport protocol. For the sake of brevity, it will not be described in detail here.

[0076] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0077] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0078] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0079] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0080] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0081] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0082] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A Core 2 Core data transfer method based on a transport protocol, characterized by, The method comprises the following steps: configuring a function switch parameter of the shared storage device, when the current traffic of the shared storage device is greater than a preset traffic threshold, and the function switch parameter is set to a first value, the shared storage device temporarily suspends receiving a read request newly sent by a node core, and determines the received read request; determining a target storage body identifier corresponding to the received read request from the shared storage device, and obtaining a source node core identifier and a target node core identifier of the received read request; when the source node core identifier is inconsistent with the target storage body identifier, and the target storage body identifier is inconsistent with the target node core identifier, using a delay optimization protocol to send request data in the target node core to the source node core.

2. The Core 2 Core data transfer method based on a transfer protocol according to claim 1, characterized in that, The method comprises the following steps: when the shared storage device has completely processed the received read request, modifying the function switch parameter to a second value; when the function switch parameter is modified, the shared storage device receives a new read request, and processes the received read request of the shared storage device using an original protocol.

3. The Core 2 Core data transfer method based on a transfer protocol according to claim 1, characterized in that, The method comprises the following steps: allocating a software interface register for each shared storage device in a chip; configuring the function switch parameter of the shared storage device in the software interface register.

4. The Core 2 Core data transfer method based on a transfer protocol according to claim 1, characterized in that, The method comprises the following steps: allocating an independent register for each thread in a multi-thread chip environment; configuring the function switch parameter of the shared storage device responsible by the thread in the independent register.

5. The Core 2 Core data transmission method based on a transmission protocol according to claim 1, wherein when the current traffic of the shared storage device is greater than the preset traffic threshold, and the function switch parameter is the second value, the read request received by the shared storage device is processed using the original protocol; when the current traffic of the shared storage device is less than or equal to the preset traffic threshold, and the function switch parameter is the second value, the function switch parameter is modified to the first value.

6. The Core 2 Core data transmission method based on a transmission protocol according to claim 1, wherein when the source node core identifier is consistent with the target storage body identifier, or the target storage body identifier is consistent with the target node core identifier, the read request received by the shared storage device is processed using the original protocol.

7. The Core 2 Core data transfer method based on a transfer protocol according to claim 1, characterized by, The method comprises the following steps: sending the request data and the state information of the request in the target node core to the source node core along different paths through a snoop mechanism, and obtaining the response of the source node core.

8. The Core 2 Core data transfer method based on a transfer protocol according to claim 7, characterized in that, The method comprises the following steps: sending a snoop request to the target node core having received the read request through the target storage body having received the read request; after receiving the snoop request, the target node core determines a nearest storage body, sends the request data and the delay state to the nearest storage body, and sends a snoop state to the target storage body; The routing path of the recently stored body sends the received request data and the delay state to the source node core; The source node core waits to receive a read response state after receiving the delay state; The target storage body sends a read response state to the source node core after receiving the snoop state; The source node core sends a read response handshake to the target storage body after receiving the request data and the read response state.

9. The Core 2 Core data transfer method based on a transfer protocol according to any one of claims 1, 4 or 5, characterized in that, The read request received by the shared storage device is processed using the original protocol, comprising: sending a snoop request to the target node core that has received the read request by the target storage body that has received the read request; The target node core sends request data to the target storage body after receiving the snoop request; The target storage body sends the received request data and the read response state to the source node core; The source node core sends a read response handshake to the target storage body after receiving the request data and the read response state.

10. A Core 2 Core data transfer system based on a transport protocol, characterized in that, The system comprises a register and a shared storage device; The register is configured to configure a function switch parameter of the shared storage device; The shared storage device is configured to temporarily suspend a read request newly sent by a receiving node core when the current traffic is greater than a preset traffic threshold and the function switch parameter is set to a first value, and determine a received read request; Determine the target storage body identifier corresponding to the received read request, and obtain the source node core identifier and the target node core identifier of the received read request; Determine the target storage body identifier corresponding to the received read request, and obtain the source node core identifier and the target node core identifier of the received read request; When the source node core identifier and the target storage body identifier are inconsistent, and the target storage body identifier and the target node core identifier are also inconsistent, use the delay optimization protocol to send the request data in the target node core to the source node core.

11. The Core 2 Core data transmission system based on a transmission protocol according to claim 10, wherein The register is further configured to modify the function switch parameter to a second value when the shared storage device has completed processing of all received read requests; The shared storage device is further configured to receive new read requests and process the read requests received by the shared storage device using the original protocol when the function switch parameter is modified.

12. The transport protocol based Core 2 Core data transfer system of claim 10, wherein, The register is a software interface register; The software interface register is configured to configure a function switch parameter of a dedicated shared storage device.

13. The transport protocol based Core 2 Core data transfer system of claim 10, wherein, The register is an independent register; The independent register is configured to configure a function switch parameter of a shared storage device responsible for a dedicated thread.

14. The Core 2 Core data transmission system based on a transmission protocol according to claim 10, wherein The shared storage device is further configured to process the read requests received by the shared storage device using the original protocol when the current traffic of the shared storage device is greater than a preset traffic threshold and the function switch parameter is the second value; The register is further configured to modify the function switch parameter to the first value when the current traffic of the shared storage device is less than or equal to a preset traffic threshold and the function switch parameter is the second value.

15. The Core 2 Core data transmission system based on a transmission protocol according to claim 10, wherein, The shared storage device is further configured to use an original protocol to process a read request received by the shared storage device when the source node core identifier is consistent with the target storage bank identifier or the target storage bank identifier is consistent with the target node core identifier.

16. The Core 2 Core data transmission system based on a transmission protocol according to claim 15, wherein, The request data and the state information of the request in the target node core are sent to the source node core along different paths through a snoop mechanism, and a response of the source node core is obtained.

17. The Core 2 Core data transmission system based on a transmission protocol according to claim 15, wherein, The target storage bank is configured to send a snoop request to the target node core that has received the read request. The target node core is configured to determine a nearest storage bank after receiving the snoop request, send the request data and the delayed state to the nearest storage bank, and send a snoop state to the target storage bank. The nearest storage bank is configured to send the received request data and the delayed state to the source node core through a routing path. The source node core is configured to wait for a read response state after receiving the delayed state. The target storage bank is further configured to send the read response state to the source node core after receiving the snoop state. The source node core is further configured to send a read response handshake to the target storage bank after receiving the request data and the read response state.

18. The Core 2 Core data transmission system based on a transmission protocol according to any one of claims 10, 13 or 14, wherein, The target storage bank is configured to send a snoop request to the target node core that has received the read request. The target node core is configured to send the request data to the target storage bank after receiving the snoop request. The target storage bank is configured to send the received request data and a read response state to the source node core. The source node core is configured to send a read response handshake to the target storage bank after receiving the request data and the read response state.

Images