A method for computing resource migration of a fast link and an electronic device

Abstract

The application discloses a resource migration method of a computing fast link and electronic equipment, relates to the technical field of computing fast links, and comprises the following steps: collecting message round-trip delay and link bandwidth occupation data of the computing fast link, calculating a link saturation factor that can represent the congestion degree of the link, and triggering resource migration by taking a hardware preset threshold as a judgment basis, so that accurate and instant migration triggering based on real-time working conditions of the link is realized, and the defects of inaccurate migration decision, response lag, easy mis-triggering or missed triggering are solved; in the resource migration process, a source end device physical address is dynamically redirected by relying on a hardware-level shadow address conversion table, double-end addressability of the source end and target end devices is realized for a business access request, a business write request is cached and processed by cooperating with a hardware double-write cache, and write data is synchronously written into the source end device and the target end device, so that double-end consistency of data in the whole migration process is realized on the basis of guaranteeing continuous operation of the business without awareness.

Description

Technical Field

[0001] This application relates to the field of fast computing link technology, and in particular to a resource migration method and electronic device for fast computing links. Background Technology

[0002] With the rapid development of composable data center technology, Compute Express Link (CXL) technology, with its high-speed and low-latency interconnect characteristics, has become a core supporting technology for composable data centers to achieve pooled sharing and flexible scheduling of heterogeneous hardware resources such as memory and accelerators. Currently, CXL resource migration solutions generally use software load statistics or manual configuration triggering methods to carry out resource migration operations. This results in poor accuracy of migration decisions, delayed response, and a tendency for accidental or untimely migration triggers, making it unsuitable for dynamically changing link operating scenarios. Furthermore, the lack of hardware-level migration adaptation and data protection mechanisms easily leads to problems such as data inconsistency between the source and target ends and abnormal business access, seriously affecting the stability of business operations and data reliability during the CXL resource migration process. Summary of the Invention

[0003] This application provides a method and electronic device for resource migration of computationally fast links (CXLs), which at least solves the problems in related technologies where CXL resource migration relies solely on software load statistics or manual configuration to trigger migration, resulting in inaccurate migration decisions and delayed responses.

[0004] This application provides a resource migration method for computing fast links, including: obtaining packet round-trip time and link bandwidth usage data of the computing fast link; calculating a link saturation factor based on the packet round-trip time and link bandwidth usage data; the link saturation factor is used to characterize the congestion level of the computing fast link; when the link saturation factor exceeds a hardware preset threshold, resource migration is initiated; during the resource migration process, the physical address of the source device is dynamically redirected through a shadow address translation table, so that service access requests can simultaneously address both the source and target devices; and, service write requests are hardware-cached through a dual-write cache and synchronously written to both the source and target devices.

[0005] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the resource migration method of the above-described fast computing link when executing the computer program.

[0006] This application also provides a resource migration apparatus for computing fast links, including: The acquisition module is used to acquire data on the round-trip time of packets and the bandwidth usage of the fast link. The calculation module is used to calculate the link saturation factor based on the packet round-trip time delay and link bandwidth usage data; the link saturation factor is used to characterize the congestion level of fast links. The startup module is used to initiate resource migration when the link saturation factor exceeds the hardware preset threshold. The resource migration module is used to dynamically redirect the physical address of the source device through a shadow address translation table during the resource migration process, so that business access requests can address both the source and target devices simultaneously; and to perform hardware caching of business write requests through dual write caching and synchronously write them to both the source and target devices.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the resource migration method of the above-described fast computing link.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the resource migration method for the above-described fast computation link.

[0009] This application provides a resource migration method for computing fast links. This method abandons the traditional delayed migration triggering logic of software statistics and manual configuration. By collecting and computing the packet round-trip latency and link bandwidth usage data of fast links in real time, it calculates the link saturation factor that can characterize the link congestion level, and uses a hardware preset threshold as the judgment basis to trigger resource migration. This achieves accurate and timely migration triggering based on the real-time operating conditions of the link, completely solving the defects of inaccurate migration decisions, delayed response, easy false triggering or missed triggering. At the same time, during the resource migration process, the physical address of the source device is dynamically redirected by relying on the hardware-level shadow address translation table. This enables the service access request to be addressable on both the source and target devices. With the help of hardware dual write cache, the service write request is cached and the write data is synchronously written to the source and target devices. While ensuring the continuous operation of the service without being aware of it, the method achieves data consistency between the two ends throughout the migration process, effectively avoiding the problem of inconsistent data between the source and target ends caused by the lack of hardware protection mechanism in traditional solutions. Attached Figure Description

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

[0011] Figure 1A schematic diagram illustrating the specific hardware architecture upon which the execution of a resource migration method for a fast computing link provided in this application depends; Figure 2 A flowchart illustrating a resource migration method for computing fast links provided in this application embodiment; Figure 3 A flowchart illustrating another resource migration method for computing fast links provided in this application embodiment; Figure 4 A schematic diagram of a resource migration device for computing fast links provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

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

[0014] ComputeExpressLink (CXL) is an open industry standard cache coherency interconnect protocol released by the CXL Alliance. It reuses the physical layer and electrical interface of the high-speed serial computer extension bus standard (peripheral component interconnect express, PCIe), and defines three sub-protocols: CXL.io, CXL.cache, and CXL.mem. It enables high-bandwidth, low-latency communication between host processors and accelerators and memory expansion devices, maintains cache coherency between host memory space and external device memory, and supports data center application scenarios such as heterogeneous computing and memory decoupling pooling.

[0015] The Address Translation Unit (ATU) is the hardware address translation engine in the CXL architecture. It includes inbound and outbound address translation windows and is used to implement address mapping and address translation between the device address space and the host system physical address space, completing the cross-address space translation of access request addresses.

[0016] The Modified Exclusive Shared Invalid (MESI) cache coherency protocol, based on Invalidate, is a classic bus-sniffing cache coherency protocol. The CXL.cache protocol directly reuses this protocol specification. MESI consists of four marked states for cache lines, used to maintain cache copy consistency across multiple cores / multiple CXL devices. Each cache line occupies 2 bits of hardware status bits for encoding.

[0017] Flow control unit A Control Unit (Flit) is a fixed-size transmission unit defined by the CXL link layer. Various message packets such as CXL.io, CXL.cache, and CXL.mem output by the CXL transaction layer are split into one or more Flits before being sent to the physical link for transmission. Each Flit carries a header control field, payload, and verification information, and undertakes link layer flow control, error checking, and hardware pipeline forwarding functions.

[0018] CXL Fabric is a scalable cache-coherent interconnect network consisting of one or more CXL switches, a switching architecture management unit, CXL hosts, and CXL end devices (accelerators, memory expansion devices).

[0019] The CXL switch is the core hardware forwarding device of CXL Fabric. This device is compatible with PCIe physical electrical interfaces and can forward Flit messages of CXL.io, CXL.cache, and CXL.mem protocols, enabling interconnection between multiple CXL terminal devices.

[0020] With the rapid development of composable data center technology, CXL interconnect technology, with its high-speed and low-latency interconnect characteristics, has become a core supporting technology for composable data centers to achieve pooled sharing and flexible scheduling of heterogeneous hardware resources such as memory and accelerators. In scenarios such as high-performance computing and long-cycle business workload operation, businesses place extremely high demands on the real-time performance, continuity, and stability of data center resource scheduling. There is an urgent need to achieve seamless migration of hardware resources such as CXL memory and accelerators during runtime, to complete dynamic resource allocation without interrupting business operations, ensure the continuous execution of long-cycle tasks, reduce business switching losses, and improve data center resource utilization and operational reliability.

[0021] Currently, mainstream CXL resource allocation in the industry generally adopts a static binding model, which can only complete the initial fixed allocation and unbinding of hardware resources. It cannot achieve dynamic and seamless migration of CXL resources such as memory and accelerators during business operation, making it difficult to adapt to the core requirements of dynamic resource scheduling in composable data centers. Currently, CXL resource scheduling and migration related technical solutions are mainly divided into three categories: First, the static binding scheme for CXL resources, which completes the initial allocation and unbinding of resources through fixed configuration, and does not support dynamic adjustment and migration of resources during business operation; second, the solution based on traditional server memory hot migration, which relies on data transmission mechanisms such as pre-copy and copy-on-write to achieve cross-node memory data migration; and third, the hot-swappable scheme for CXL devices, which can only realize online access and offline operations of CXL devices. The above technical solutions are designed only around static resource allocation, software-level data copying, and simple device online / offline logic, without considering the real-time operating status of the CXL physical link to trigger resource migration, and lack hardware-level atomic switching capabilities and rapid cache image reconstruction capabilities, making them unsuitable for high-concurrency, high-performance business operation scenarios.

[0022] Furthermore, the relevant CXL resource migration technologies have many inherent defects, severely restricting the stable and efficient operation of composable data centers. First, the migration triggering mechanism lacks intelligence; resource migration decisions rely entirely on software load statistical analysis or manual configuration triggering, without considering the real-time status of the CXL physical links. This results in low accuracy and delayed response in migration decisions, easily leading to false triggers and missed triggers, and extremely poor resource scheduling flexibility and timeliness. Second, migration data transmission efficiency is low; related solutions generally adopt a full data copy mode, failing to distinguish between valid and redundant data, and performing invalid copies of unmodified data. This significantly consumes bandwidth on business links, leading to a substantial increase in migration time, crowding out normal business operation resources, and impacting overall business performance. Third, data consistency assurance capabilities are lacking; related technologies lack hardware-level transaction protection and data verification mechanisms. Continuous write operations during the migration process can easily cause inconsistencies between the source and target data, leading to data loss, system malfunctions, and other failures, severely reducing business operational stability. Meanwhile, the related technologies cannot achieve synchronous migration of the CXL.cache cache consistency state. After the accelerator resources are migrated, the initialization and cache loading processes need to be re-completed, which not only significantly increases the latency of business recovery but also causes increased equipment power consumption and significant performance degradation. Finally, the reliability of business switching is insufficient. The resource migration and business switching process lacks hardware-level atomic switching protection mechanisms, and problems such as business transaction interruption, data packet loss, and runtime sequence anomalies are prone to occur during the switching phase, which cannot meet the continuous operation requirements of long-term, highly reliable services.

[0023] In summary, existing CXL resource scheduling and migration technologies suffer from numerous technical defects, such as scheduling lag, low migration efficiency, poor data consistency, slow business recovery, and insufficient system stability. These shortcomings make it difficult to meet the core requirements of current composable data centers for fast, reliable, and seamless hot migration of CXL resources. There is an urgent need to propose a CXL resource hot migration solution that adapts to hardware characteristics, links physical link status, and provides hardware-level consistency guarantees.

[0024] To address all or part of the aforementioned technical problems, this application provides a resource migration method for computing fast links. This method abandons the traditional delayed migration triggering logic based on software statistics and manual configuration. By collecting real-time data on the round-trip latency of packets and the bandwidth usage of the computing fast links, it calculates a link saturation factor that characterizes the degree of link congestion and triggers resource migration based on a hardware-preset threshold. This achieves accurate and timely migration triggering based on the actual real-time operating conditions of the link, completely solving the defects of inaccurate migration decisions, delayed response, and easy mis-triggering or missed triggering. Simultaneously, during the resource migration process, the physical address of the source device is dynamically redirected using a hardware-level shadow address translation table, enabling dual-end addressability of service access requests for both the source and target devices. In conjunction with hardware dual-write caching, service write requests are cached, and write data is synchronously written to both the source and target devices. While ensuring the continuous operation of services without being aware of it, this method achieves data consistency between both ends throughout the migration process, effectively avoiding the problem of inconsistent data between the source and target ends caused by the lack of hardware protection mechanisms in traditional solutions.

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

[0026] Figure 1 A schematic diagram illustrating the specific hardware architecture upon which the resource migration method for a fast computation link provided in this application depends, as shown in the embodiment. Figure 1 As shown, the hardware architecture includes a physical link monitoring unit, a migration engine, a shadow address translation table hardware module, a dual-write cache module, a cache state synchronization module, an atomic handshake switching module, and an identifier-based routing (IBR) management module.

[0027] The physical link monitoring unit collects round-trip delay and link bandwidth occupancy data of CXL physical link Flit messages at a preset high-frequency sampling frequency. It completes cross-clock domain data synchronization through a three-level synchronizer and Gray code conversion to eliminate metastable interference. Based on the calibrated sampling data, it calculates the link saturation factor in real time, providing a purely physical layer quantitative judgment basis without software intervention for triggering resource migration.

[0028] The migration engine receives the link saturation determination results output by the physical link monitoring unit. When the resource migration trigger conditions are met, it starts a complete set of migration timing logic. It unifies the scheduling of all hardware operations, including address redirection, dual-write data synchronization, cache status acquisition and reconstruction, bandwidth quota management, anomaly fault tolerance verification, atomic handshake switching, and hardware resource reclamation. It coordinates the collaborative work of various hardware modules to achieve autonomous closed-loop control of the entire migration process.

[0029] The shadow address translation table hardware module is used to implement dynamic remapping of hardware addresses during the migration transition period. It is activated and takes effect after the resource migration process starts. It dynamically redirects the physical address range of the source device, so that business read and write requests can simultaneously address the source device and the target device, build a hardware address mapping environment for parallel access from both ends, and ensure that business access is not interrupted during the migration process.

[0030] The dual-write caching module is responsible for ensuring the consistency of transaction data during the migration process. It caches business write requests during the migration cycle and synchronously writes the write data to both the source and target devices. It only replies to the business response after the data writing on both ends is completed, ensuring the integrity and consistency of transaction data before and after the migration switch. At the same time, it works with the hardware Cyclic Redundancy Check (CRC) mechanism to complete real-time consistency detection and abnormal resynchronization of dual-write data, avoiding data synchronization deviation problems.

[0031] The cache state synchronization module constructs a dedicated cache consistency transmission channel independent of the ordinary data channel. It is responsible for completing the interaction and mirror reconstruction of the MESI cache consistency state between the source and target devices. It can accurately collect the modified state and exclusive state valid cache line information of the source device and synchronize it to the target device. It supports the target device to replicate the cache running state consistent with the source device. At the same time, it quantitatively calculates the cache mirror matching degree, providing hardware quantitative basis for cache convergence judgment and traffic switching.

[0032] The atomic handshake switching module is the core hardware module for lossless switching of service traffic. After data synchronization and cache reconstruction are completed, it completes the atomic handshake interaction between the source and target devices through CXL physical layer dedicated signaling, locks the switching sequence, clears the Flit packets in transit on the link, ensures the atomicity and uniqueness of the traffic switching operation, and prevents packet corruption and data loss during the switching process.

[0033] The IBR routing management module is responsible for routing configuration management and traffic switching execution throughout the migration process. In the pre-migration stage, it completes the pre-allocation of target logical identifiers. In the switching stage, it updates the global routing table entries in batches to seamlessly switch all service traffic to the target device. After the migration is completed, it clears the address mapping table entries and reclaims hardware resources. At the same time, in the event of a switching anomaly, it enables fast route rollback within a single Flit cycle to ensure the continuous and stable operation of services.

[0034] Figure 2 This is a flowchart illustrating a resource migration method for computing fast links, provided as an embodiment of this application. Figure 2 As shown, embodiments of this application provide a method for computing fast link resource migration, the method comprising the following steps: S201. Obtain and calculate the round-trip time of messages and the bandwidth usage of the fast link.

[0035] This application can be based on a high-frequency sampling frequency F. S (e.g. F) S =10MHz) collects real-time operational data of CXL physical link layer Flit packets. The core collection parameters include the Flit packet round-trip time T. latency_i Link bandwidth usage data BW consumed .

[0036] S202. Calculate the link saturation factor based on the message round-trip delay and link bandwidth usage data.

[0037] In some embodiments, message round-trip time (RTT) and link bandwidth occupancy data are synchronized across clock cycles. The average RTT over multiple sampling periods is calculated based on the RTT after cross-clock synchronization, and the ratio of the synchronized link bandwidth occupancy data to the total link bandwidth is also calculated. Then, the average RTT is multiplied by this ratio to obtain the link saturation factor.

[0038] Specifically, based on the message round-trip delay and link bandwidth usage data from N consecutive valid sampling periods, the message round-trip delay T can be calculated using a three-stage synchronizer combined with Gray code conversion. latency_i Link bandwidth usage data BW consumed Cross-clock domain synchronization is performed to avoid data distortion caused by metastability and ensure the authenticity and reliability of the sampled data. After cross-clock domain synchronization, the average round-trip time of messages over multiple sampling periods is calculated. This average, combined with the ratio of data occupied by the link bandwidth to the total link bandwidth, yields the link saturation factor. The calculation formula is: Among them, T latency_i This represents the round-trip time for a single sampled Flit message, where N is the preset number of sampling periods, e.g., N=1024; BW consumed For link bandwidth usage data, BW total The rated total bandwidth for the CXL link.

[0039] The above embodiments, targeting the raw message data obtained by high-speed sampling at the CXL physical layer, employ a three-level synchronizer combined with Gray code conversion to achieve cross-clock domain data synchronization under multiple consecutive sampling periods. This effectively avoids metastability issues in high-speed hardware interaction scenarios, prevents distortion and falsification of sampled data caused by clock domain interaction, and ensures the authenticity and reliability of the raw sampled data at the physical layer. This provides an accurate underlying data source for subsequent migration trigger determination. Based on this, the hardware uses the synchronized and processed effective sampled data to calculate the link saturation factor in real time. This factor integrates two dimensions of information: the average round-trip delay of Flit messages over N sampling periods and the ratio of real-time occupied bandwidth to total link bandwidth. It can objectively and comprehensively characterize the actual load and congestion state of the CXL physical link, ensuring that the calculation result of the link saturation factor closely matches the actual operating conditions of the link. This eliminates the risk of false triggering and missed triggering caused by data distortion, ensuring the objectivity and determinism of migration trigger determination at the hardware level, and providing reliable data support for achieving hardware autonomous migration without software intervention.

[0040] S203. When the link saturation factor exceeds the hardware preset threshold, resource migration is initiated.

[0041] The hardware preset threshold T is a pre-set link saturation judgment threshold, such as T=0.75. Resources in this application include, but are not limited to, CXL memory, and may also be accelerators. Specifically, it can be the complete service context of the CXL accelerator, including but not limited to service data, MESI cache status, and accelerator runtime context.

[0042] This application continuously iterates and calculates the link saturation factor Φ. When the value of the link saturation factor Φ continuously and stably exceeds the hardware preset threshold T, it is determined that there is congestion pressure on the current CXL physical link, and the migration engine is automatically triggered to start the resource migration process. This triggering logic is entirely based on physical layer hardware signals, and the decision is stable with no software errors or delays.

[0043] In some embodiments, after initiating resource migration, this application first performs a hardware locking operation on the configuration space of the source device, and then assigns a logical identifier to the target device to complete the pre-initialization of resource migration.

[0044] Specifically, after initiating resource migration, the hardware logic immediately performs a hardware locking operation on the device configuration space of the source device and freezes the configuration parameters, port mapping relationships, and link binding status of the source device through a hardware register latching mechanism. This prevents the configuration of the source device from being rewritten, refreshed, or dynamically changed during the resource migration process, ensuring the uniqueness and stability of the device configuration information within the migration window. Simultaneously, the CXL switch completes the pre-allocation of logical identifiers for the target device. Based on the CXL Fabric interconnection specification, it pre-allocates unique logical identifiers, node identity identifiers, and link mapping identifiers for the target device to be connected, establishing the target device's legitimate network access identity and routing pre-mapping relationship in advance.

[0045] The above hardware locking and pre-allocation operations are completed in one go at the migration initialization node, providing a stable device configuration foundation and legitimate node identification support for subsequent processes. This avoids synchronization anomalies and switching failures caused by changes in device configuration or uninitialized node identifications during resource migration from a hardware perspective.

[0046] S204. During the resource migration process, the physical address of the source device is dynamically redirected through the shadow address translation table, so that the business access request can address both the source and target devices simultaneously; and, the business write request is hardware cached through dual write cache and synchronously written to both the source and target devices.

[0047] The shadow address translation table is configured inside the CXL switch and is used to dynamically redirect physical addresses during resource migration to ensure uninterrupted service access.

[0048] Dual write cache Write Buffer (DWB) is a dedicated high-speed cache hardware module deployed within the hardware path. In CXL accelerator dynamic migration scenarios, it represents the data transmission path between the source and target accelerators.

[0049] After the resource migration process is initiated, this application relies on hardware atomic transaction remapping and a dual-write buffer mechanism to ensure the continuity and consistency of service read and write data during the resource migration process. The dual-write buffer module and Shadow Address Translation Unit (Shadow-ATU) are simultaneously enabled by the CXL Switch. The CXL Switch is a hardware switching device under the CXL high-speed interconnect architecture, serving as the core forwarding hub for packet interaction between various CXL devices, and has the functions of flow control unit (Flit) packet switching and forwarding, logical identifier management, and routing table configuration update.

[0050] Shadow-ATU dynamically redirects the physical address of the source device, allowing read and write requests to address both the source and target devices simultaneously. Meanwhile, the DWB hardware module performs hardware caching and dual-end synchronous writing of write requests issued by the service. Only after both the source and target ends have completed the write operation will a response signal be returned to the service end, ensuring the integrity of transactions during the migration process.

[0051] This application also includes a comprehensive hardware fault tolerance and exception handling mechanism to ensure the stable and reliable operation of the migration process. During the process of synchronously writing business write requests to the source and target devices via dual-write caching, the verification feature values ​​of the data written from the source and the target are compared. If the verification feature values ​​are inconsistent, the business write request is rewritten to both the source and target devices.

[0052] Among them, the source-side write data is the write transaction data that the business write request is sent to the source side through the interconnection channel during the resource migration process, and is distributed and written to the source side by the dual write cache module. This type of data is the original business data to be written to disk and is the benchmark data source for data synchronization during the migration process.

[0053] During resource migration, the dual-write caching module distributes and copies business write requests from the same source, then writes the copy of the data to the target end. The data written to the target end must be consistent with the data on the source end.

[0054] During the data synchronization phase of resource migration, a built-in cyclic redundancy check mechanism is used to detect the consistency of DWB dual-write data in real time. If the check fails or the data consistency does not match, the hardware automatically triggers an in-situ resynchronization operation to fix the data anomaly.

[0055] Specifically, throughout the entire process of dual-end synchronous writing to the source and target devices using the DWB dual-write buffer, the hardware performs cyclic redundancy check (CRC) operations on the dual-end written data in the DWB cache in real time. The hardware CRC logic compares the CRC signatures of the source and target written data to determine the consistency status of the dual-end data in real time. If the CRC signatures match, the dual-end data synchronization is considered valid, and the subsequent migration process proceeds normally. If the hardware detects inconsistencies in the CRC signatures of the two ends, indicating a data synchronization anomaly, it automatically triggers an in-situ resynchronization fault-tolerance mechanism without software intervention. The hardware immediately terminates the current abnormal data synchronization process and re-initiates a local dual-end write synchronization operation based on the original business write request data. It overwrites and repairs the current abnormal data in-situ, correcting the DWB dual-write data differences through multiple hardware-level resynchronizations until the CRC signatures of the dual-end data match. This effectively eliminates data transmission deviations and synchronization distortions during the migration process, ensuring that the dual-end data in the DWB dual-write buffer always maintains a high degree of consistency.

[0056] The above embodiments utilize a hardware CRC check mechanism to perform consistency checks on the synchronized data output from the dual-write cache. Relying on a hardware-level verification path, it compares and identifies the data written from the source and target ends, quickly capturing data copy discrepancies caused by link disturbances and hardware transient interference. Once data inconsistency is detected, the hardware can directly trigger in-situ resynchronization to correct the data without upper-layer software intervention. This not only promptly eliminates data errors generated during incremental write request synchronization in the migration transition period, preventing the continuous spread of erroneous data, but also avoids interrupting the ongoing migration process. It ensures that the data copies of the source and target accelerators remain consistent under the dual-write path, providing a reliable data foundation for subsequent cache convergence determination and atomic switching of business traffic. This effectively reduces the probability of migration failure and business operation errors due to inconsistent synchronized data, improving the data reliability and process stability of the CXL accelerator's dynamic migration process.

[0057] In some embodiments, if a retryable exception occurs during resource migration, a local retry operation is triggered, and the number of retries is counted. This number of retries is compared with a preset maximum retry threshold. If the number of retries is less than the preset maximum retry threshold, the local retry operation continues; if the number of retries is greater than or equal to the preset retry threshold, the resource migration process is terminated, and a hardware fault alarm signal is output. Simultaneously, the service continues to operate normally on the source device.

[0058] Among them, the preset maximum retry threshold K retry As a threshold for distinguishing between ordinary transient link anomalies and inherent hardware faults, such as K retry =5.

[0059] The migration engine in this application incorporates a built-in hardware retry counter that continuously counts and statistically analyzes hardware retry behaviors for various synchronization and verification anomalies in real time. This counter is implemented purely in hardware logic, requiring no software intervention in counting and statistical operations. Whenever a retryable anomaly occurs during the migration process, such as data verification failure, synchronization distortion, or momentary link jitter, the hardware automatically triggers a local retry operation, and the hardware retry counter accumulates the number of retries for each instance. The hardware continuously compares the current cumulative number of retries with the preset maximum retry threshold K. retry Perform a comparison; if the cumulative number of retries does not exceed K... retry If the cumulative number of retries reaches and exceeds K, the hardware automatic retry synchronization process will continue to be executed; retryThe hardware determines that the current anomaly is not a transient link disturbance, but rather an irreversible hardware failure in the device or link. In this case, the hardware immediately and forcibly terminates the current accelerator dynamic migration process, stops all data synchronization and cache rebuilding operations, and synchronously outputs a hardware failure alarm signal to the upper-layer system, completing the fault reporting. Simultaneously, the hardware locks the service operation status of the source device, maintaining the original routing forwarding and data read / write logic unchanged, ensuring that the service continues to operate normally on the source device without interruption, downtime, or service switching anomalies due to migration failures, thus achieving stable service uptime in migration failure scenarios.

[0060] The hardware retry counter built into the migration engine in the above embodiments can perform hardware-level counting and statistics of abnormal retry behaviors during the data synchronization phase, without relying on software to complete the count and judgment logic. When the retry count exceeds the preset maximum retry threshold, a persistent hardware failure can be determined, and the current migration process will be terminated and a hardware failure alarm signal will be output, while the service continues to operate normally on the source accelerator. In this way, it is possible to distinguish between transient link disturbances and persistent hardware failures, avoiding migration process blockage and continuous system resource occupation caused by repeated and unlimited retries. It can promptly handle failures when unrecoverable synchronization anomalies occur, avoid data corruption caused by continuing to perform subsequent traffic switching under inconsistent data conditions, ensure that the service will not be interrupted due to migration failures, and further improve the fault tolerance and operational robustness of the CXL accelerator's hardware dynamic migration process.

[0061] In some embodiments, to avoid migration traffic crowding out core service bandwidth, this application determines the maximum transmission bandwidth of the migration traffic during the resource migration process based on the total link bandwidth, real-time core service traffic, and preset redundant bandwidth. Then, the migration traffic during the resource migration process is controlled according to this maximum transmission bandwidth, ensuring that the migration traffic operates under strict limitations and avoids crowding out core service bandwidth resources. Here, real-time core service traffic refers to the real-time bandwidth usage data of the current core priority service. Preset redundant bandwidth is a pre-configured fixed bandwidth redundancy margin to ensure the stable operation of the CXL physical link.

[0062] Throughout the resource migration process, this application monitors the bandwidth resource usage status of the CXL physical links in real time, collects the total link bandwidth and current real-time core service traffic, and schedules pre-configured redundant bandwidth. It also calculates and limits the maximum transmission bandwidth quota R for the migrated traffic. limit The calculation formula is R limit =BW total -BW priority_traffic - margin In the formula, BW total The rated total bandwidth for the CXL physical link; BW priority_traffic This represents the current real-time core service traffic within the CXL physical link. margin Pre-set bandwidth redundancy margin for the system, for example margin =0.2. This ensures that the migrated traffic is transmitted strictly within the quota, without encroaching on the bandwidth resources of core services.

[0063] In calculating the maximum transmission bandwidth quota R limit Subsequently, real-time rate limiting and constraint control are implemented on the data transmission traffic during the resource migration process, strictly limiting all migration traffic to the maximum transmission bandwidth quota R calculated in real time. limit Transmission is carried out within the specified range. Simultaneously, a hardware-linked idle scheduling mechanism prioritizes bandwidth usage and transmission timing for core service traffic. Migrating traffic only utilizes the remaining idle bandwidth resources of the CXL physical link, without crowding out or preempting the bandwidth quota and transmission resources of core services. This achieves bandwidth isolation between migration traffic and service traffic at the hardware level, ensuring that the throughput performance and transmission latency of core services are not affected by the accelerator migration operation, thus guaranteeing the continuity and stability of service operation.

[0064] In some embodiments, during resource migration, in response to service access requests for data blocks undergoing migration, the physical layer packets transmitted via the compute fast link are monitored in real time to identify idle packets in the compute fast link. Resources are then migrated within the idle time slots corresponding to the idle packets. Thus, for service data access requests arriving during resource migration, this application utilizes the idle gaps of CXL physical link idle packets (IDLE Flit) to complete bidirectional data synchronization without inserting additional waiting periods, effectively controlling service access latency and achieving seamless data migration for services.

[0065] Specifically, during the dynamic migration of the CXL accelerator, when a service requests a data block that is undergoing resource migration, the Flit packets transmitted on the CXL physical link can be monitored in real time to identify idle gaps (IDLE Flits) in the CXL physical link. It should be noted that an IDLE Flit is an idle packet used by the CXL physical layer to fill link space, indicating that there are currently no service payload packets being transmitted on the link.

[0066] After identifying the idle time slot corresponding to the IDLE Flit, the bidirectional migration data to be synchronized is scheduled, and the bidirectional data synchronization operation is interleaved and multiplexed within this idle time slot for transmission. This data synchronization action only occupies the idle transmission window of the IDLE Flit, without inserting additional data transmission operations within the effective transmission time slot of the service message. It eliminates the need for additional waiting periods for the migration synchronization operation and does not interrupt the original transmission and reception sequence of the service messages. By reusing the inherent idle resources of the link to complete bidirectional data synchronization, the migration synchronization operation avoids preempting the service message transmission time slot, thereby suppressing additional latency generated by service access requests. This ensures that upper-layer services are unaware of the latency disturbance caused by the migration, guaranteeing that the latency performance of service access remains essentially at the original level.

[0067] In some embodiments, during resource migration, valid cache line information in the modified and exclusive states of the source device is collected, and a cache state recovery table is generated. Then, based on this cache state recovery table, a cache state consistent with that of the source device is locally replicated on the target device. Subsequently, the cache mirroring match degree is determined based on the ratio of the number of valid cache hits on the target device to the number of modified dirty cache lines on the source device. This cache mirroring match degree characterizes the cache mirroring synchronization effect. When the cache mirroring match degree reaches a preset hardware threshold, and all dirty page data on the source device is synchronized, an atomic handshake handover operation is performed between the source and target devices. In-transit packets on the fast computing link are cleared, and global routing table entries are updated to switch service traffic to the target device, enabling the target device to enter a warm-start ready state.

[0068] The cache state recovery table records all cache state information that needs to be rebuilt on the target device.

[0069] This application addresses the hardware cache consistency scenario of the CXL accelerator, enabling seamless cache state migration through a hardware mirror reconstruction mechanism. This application independently constructs a dedicated cache consistency transmission channel for the extraction and reconstruction synchronization of MESI cache states between the source and target devices, isolated from ordinary data transmission channels. The MESI cache state comprises four cache line states defined by the cache consistency protocol under the CXL interconnect architecture: Modified, Exclusive, Shared, and Invalid. These states characterize the validity of local cache lines on each device, data modification status, and the sharing relationship of cache replicas among multiple devices.

[0070] Specifically, during resource migration, after the migration engine initiates the cache synchronization process, a cache state collection command can be sent to the source device via a dedicated cache consistency transmission channel. Upon receiving this command, the source device filters out valid cache lines in the Modified or Exclusive states, retrieves its local cache state recovery table, and synchronizes the cache state recovery table to the target device via the cache consistency channel. After receiving the cache state recovery table from the source device, the target device, based on the synchronized cache state recovery table's status information, initiates a SnoopPush request to its local cache resources. This request replicates a cache running state completely identical to that of the source device on the target device, enabling the target device to enter a warm-start ready state.

[0071] To quantify the effectiveness of cache image synchronization, the cache image matching degree M can be calculated in real time. cache The calculation method is the ratio of the number of cache lines hit by valid targets to the total number of dirty cache lines modified on the source side, i.e., M. cache =Count(Line Target_Hit ) / Count(Line Source_modified ).

[0072] When M cache Once the hardware meets the preset synchronization threshold δ (e.g., δ=0.98) and all dirty pages on the source side are synchronized, the migration engine outputs a traffic switching command. Upon receiving the traffic switching command, the CXL Switch completes an atomic handshake switch (Handshake_Swap) between the source and target devices using dedicated physical layer signaling, ensuring the atomicity and uniqueness of the switching operation. It then enters the hardware locking cycle T. lock T lock =1Fitcycle clears the in-transit Flit packets that have not yet been transmitted on the CXL physical link. Then, the IBR routing management module updates the global routing table entries in one go, seamlessly switching all service traffic to the target device and completing the service takeover after the cache mirror reconstruction.

[0073] The above embodiment utilizes a dedicated consistency channel to collect the cache state of the source device via a migration engine. Synchronization is only performed on valid cache lines in the modified and exclusive states, avoiding redundant transmission overhead from invalid cache lines and reducing data transmission pressure on interconnect links. The target device generates a SnoopPush request based on the received complete cache table, locally replicates the cache state, and enters a warm-start ready state, achieving hardware-level image reconstruction of the cache context. This solution introduces a cache image validity metric, quantifying the degree of cache synchronization completion as the ratio of the number of valid cache lines hit on the target to the number of dirty cache lines in the modified state on the source. This provides an objective and quantifiable hardware assessment of the cache image synchronization effect, eliminating the latency and uncertainty caused by software-based judgment. The migration engine only issues a switching command after the cache image validity meets a preset hardware threshold and the source dirty page data synchronization is complete, effectively avoiding cache inconsistencies and abnormal business read / write operations caused by insufficient cache synchronization leading to traffic switching. Based on this, the CXL switch completes the atomic handshake between the source and destination ends with the help of physical layer signaling, enters the hardware locking cycle and clears the in-transit flow control unit packets within the link, and then the IBR hardware module completes the routing table update in one go, realizing seamless atomic switching of all service traffic, eliminating the risk of out-of-order packets and loss during the switching process, ensuring that the cache context and service data at both ends of the source and destination are fully aligned at the time of traffic switching, and improving the efficiency of cache reconstruction, the accuracy of switching timing determination and the reliability of service switching in the dynamic migration of the CXL accelerator.

[0074] In some embodiments, after updating the global routing table entries, a state reclamation instruction is generated. In response to this instruction, the hardware caching of service write requests by the dual-write cache is terminated, the synchronous writing of service write requests to the source and destination devices is stopped, and the shadow address translation table is cleared. Subsequently, the interconnect hardware resources occupied by the source device are reclaimed and returned to the system resource pool for dynamic allocation and use by subsequent system nodes.

[0075] After the IBR routing management module completes the batch update of global routing table entries, this application automatically disables the DWB dual-write buffer function, clears all Shadow-ATU mapping entries, synchronously reclaims the CXL switching architecture (Fabric) interconnection resources occupied by the source device, and returns the released hardware resources to the system resource pool to support dynamic scheduling and allocation of other node devices in the future.

[0076] Specifically, after the IBR routing management module completes the batch update of global routing table entries and all service traffic is stably directed to the target device, the hardware generates a state reclamation command. Based on this command, the hardware first disables the dual-end synchronous write enable function of the DWB dual-write buffer, terminates the DWB dual-write buffer's caching and dual-write processing logic for service write requests, and no longer performs synchronous write operations on the source and destination ends for write requests; subsequently, it also disables the Shadow... The ATU shadow address translation table is cleared, deleting all physical address redirection mapping entries corresponding to the source devices and resolving dynamic address remapping relationships. Further, the hardware identifies and reclaims various interconnect hardware resources occupied by the source devices in the CXL Fabric interconnect network, returning these reclaimed resources to the system resource pool. The system resource pool performs unified maintenance and management of the returned hardware resources, making them available for subsequent resource requests and dynamic scheduling allocation by other nodes within the CXL Fabric, completing all post-processing steps for this accelerator dynamic migration. All of the above switching and resource reclamation operations are completed within a single Flit transmission cycle, ensuring uninterrupted and seamless service throughout the entire process.

[0077] After the global routing table entries are updated, the hardware automatically disables the dual-write cache, clears the mapping content of the shadow address translation table, and uniformly reclaims and returns the CXL Fabric interconnect resources occupied by the source device to the system resource pool. This facilitates dynamic resource allocation for subsequent nodes. Traffic switching and resource reclamation operations are implemented by hardware logic and can be completed within a single flow control unit cycle. The entire process requires no software intervention, ensuring uninterrupted, seamless, and packet-free service operation. It also promptly releases temporary hardware resources used during migration, preventing long-term resource occupation and interconnect link resource leakage. This improves the reusability of hardware resources under the CXL interconnect architecture and optimizes the overall system resource scheduling capability.

[0078] In some embodiments, during resource migration, link status, device operating status, data verification status, and route switching status are detected to identify migration anomaly events. For different migration anomaly events, corresponding hierarchical fault-tolerance strategies are executed without software intervention.

[0079] During the resource migration process, the migration engine determines in real time whether any abnormal events have occurred based on the link status, device operating status, data verification status, and route switching status. If an abnormal event is identified, it enters the hierarchical fault-tolerant branch.

[0080] This application employs a tiered fault-tolerance strategy for various migration anomalies: When the migration process is interrupted, the hardware automatically records the current synchronization breakpoint and system configuration. After the link is restored, synchronization data is resumed based on the breakpoint, eliminating the need for full data retransmission; when the target device malfunctions, the system immediately rolls back the updated routing configuration and locks the source device to execute business; when multiple data verifications still fail to achieve data consistency, an alarm is proactively reported and the original business link is restored; when the switching operation fails abnormally, routing table entries are quickly rolled back within a single Flit cycle, comprehensively ensuring uninterrupted business operation and no data loss, achieving highly reliable dynamic migration of hardware-level resources.

[0081] Specifically, throughout the entire resource migration process, link status, device operating status, data verification status, and route switching status are monitored in real time to identify migration anomalies. Then, corresponding hierarchical fault tolerance strategies are executed for different migration anomalies.

[0082] When a migration process is interrupted due to link jitter or momentary disconnection, the hardware captures the current data synchronization progress in real time, automatically saves the current synchronization breakpoint position and the system configuration parameters of the migration process. After the CXL physical link status returns to normal, the hardware directly performs the breakpoint resume synchronization operation based on the saved synchronization breakpoint, and continues to complete the synchronization of the remaining data and cache status. There is no need to perform a full retransmission of all data, which effectively reduces the overhead of abnormal recovery.

[0083] When a fault condition such as abnormal device operation or functional failure is detected in the target device, the hardware immediately triggers the routing rollback mechanism to quickly roll back the routing configuration of the CXL Switch, lock the service operation permission of the source device, maintain the source device to continuously accept all service read and write requests, and avoid service interruption.

[0084] When DWB dual-write data still cannot achieve data consistency between the two ends after multiple hardware CRC checks, and the data synchronization anomaly cannot be self-healed, the hardware actively generates fault alarm information and switches the service transmission path back to the original service link to ensure data transmission reliability.

[0085] When traffic switching operations such as atomic handshake switching and routing table entry updates fail, the hardware can quickly roll back the global routing table entry configuration of the IBR routing management module within a single Flit transmission cycle, cancel the traffic switching operation, and restore the original service routing forwarding logic.

[0086] Through multi-scenario, hierarchical hardware fault-tolerant handling logic, it covers all abnormal operating conditions such as migration interruption, target device abnormality, data synchronization failure, and routing switching failure, ensuring uninterrupted business, no data loss, and stable and reliable system operation during the migration process.

[0087] The above embodiments set up hardware-level fault-tolerant rollback strategies for different abnormal scenarios during the migration process. When the migration link is temporarily interrupted, the hardware automatically retains the synchronization breakpoint and system configuration information. After the link is restored, the remaining data synchronization is completed by relying on the breakpoint resume mechanism, without the need to start a full retransmission, effectively reducing the data transmission overhead during the link fault recovery phase and shortening the fault repair time. When the target device is abnormal, the hardware immediately locks the source end service operation status to prevent unexpected changes in the service context. If multiple verifications still cannot achieve consistent data synchronization, the hardware outputs an alarm signal and switches back to the original service path, terminating the abnormal migration process. If an abnormality occurs during traffic switching, the routing configuration can be quickly rolled back within a single flow control unit cycle. The entire fault-tolerant handling logic is completed independently by the hardware logic, without relying on upper-layer software for fault identification and process rollback. It implements layered responses to various risks such as transient link failures, target hardware failures, data synchronization failures, and switching anomalies. It can efficiently recover from transient disturbances and perform safe rollbacks for unrecoverable failures, avoiding the continuation of the migration process under inconsistent data conditions. It ensures continuous business operation and prevents data loss or corruption throughout the entire migration lifecycle, improving the fault tolerance and overall operational robustness of the CXL accelerator hardware dynamic migration solution.

[0088] like Figure 3 As shown, Figure 3 The flowchart of another method for calculating the resource migration of a fast link provided in the embodiment of this application is shown. After the method is started, the physical link monitoring unit performs high-frequency sampling on the CXL physical layer packets, collects the round-trip delay of Flit packets and the link bandwidth occupancy data, eliminates metastable interference through cross-clock domain synchronization processing, and calculates the link saturation factor in real time. Then the migration engine compares the real-time link saturation factor with the hardware preset threshold. If the link saturation factor does not reach the hardware preset threshold, it returns to the previous step to continue executing link sampling and saturation factor calculation. If the link saturation factor meets the triggering condition, it outputs a hardware migration trigger signal to start the resource migration process. The migration engine controls the IBR routing management module to lock the configuration space of the source CXL device and completes the pre-allocation of the logical identifier of the target device. Activate the shadow address translation table hardware module to establish a hardware address redirection mapping relationship from the source end to the target end, and enable parallel access paths between the source end and the target end. Business requests can simultaneously address the source end accelerator and the target end accelerator. Enable the dual-write caching module to perform dual-write consistency processing on business write requests, and synchronously send business write requests to the source and target ends to ensure the consistency of write transactions on both ends during the migration window. The migration agent triggers the source end to execute a cache verification command, extracts all modified and exclusive cache line information from the source end, synchronizes the cache image to the target end, and generates a cache recovery table; After deducting the core business bandwidth and reserved redundancy, the traffic shaper allocates the remaining available physical bandwidth to migration transactions for parallel transmission of dirty page data and cache state recovery tables. Perform consistency checks on the data and cache status of the source and target ends; if the check results are inconsistent and the retry threshold has not been reached, continue to synchronize data and cache; if the check results are inconsistent and the retry threshold has been reached, the migration is determined to have failed, a hardware fault alarm is triggered, and the migration abnormal exit process is executed; if the check results are consistent, proceed to the cache convergence determination stage. The target device reads the cache recovery table and determines whether the cache reconstruction progress has reached the preset hardware threshold. If it has not reached the threshold, the cache synchronization operation is executed repeatedly. If it meets the threshold, it means that the target device is ready to take over the service. Then, the source device and the target device perform an atomic bus handshake through physical layer signaling, the hardware enters the physical shielding window, forcibly locks the routing calculation logic and clears all packets in transit; After a successful atomic bus handshake, the IBR routing management module updates the global routing table entries, atomically switching all service traffic to the target end; After completing the traffic switch, disable the dual-write cache and address redirection functions, release the source physical resources back to the resource pool, confirm that the link status has returned to the normal range, and complete the resource migration process.

[0089] In summary, the resource migration method for fast computing links provided in this application relies on hardware logic with a link saturation factor as the migration criterion, eliminating the use of software algorithms and prediction logic in decision-making, avoiding latency jitter and prediction bias caused by software scheduling, and ensuring that the migration timing matches the actual link load. It constructs a dual-end parallel access environment through a shadow address translation table hardware module and a dual-write cache module, completes cache image reconstruction, and after determining the cache convergence condition based on the cache state recovery table, achieves atomic switching of service traffic, avoiding out-of-order packet loss. The entire migration process does not require pausing upper-layer services, achieving seamless service operation. Simultaneously… The system is configured with full-process hardware fault tolerance logic, supporting breakpoint resumption after failure. In case of multiple verification failures or target device malfunctions, it can lock the source service, report alarms, and roll back the original service path. In case of switching anomalies, the route rollback can be completed within a single Flit cycle, ensuring uninterrupted service and no data loss. The entire migration process is executed in a closed loop by the hardware module, without the need for operating system and upper-layer driver intervention, and does not occupy host CPU resources, reducing host-side software overhead. This effectively improves the determinism, reliability, and robustness of CXL accelerator dynamic migration, adapting to the low-latency, high-bandwidth service scenario requirements of CXL high-speed interconnect architecture.

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

[0091] Figure 4 This application provides a schematic diagram of the structure of a resource migration device for computing fast links, as shown in the embodiment of the present application. Figure 4 As shown, the device includes: The acquisition module 401 is used to acquire data on the round-trip time of messages and the bandwidth usage of the fast link. The calculation module 402 is used to calculate the link saturation factor based on the message round-trip time delay and link bandwidth usage data; the link saturation factor is used to characterize the congestion level of the fast link. Startup module 403 is used to initiate resource migration when the link saturation factor exceeds a preset hardware threshold; The resource migration module 404 is used to dynamically redirect the physical address of the source device through the shadow address translation table during the resource migration process, so that the business access request can address both the source device and the target device at the same time; and to perform hardware caching of business write requests through dual write caching and synchronously write them to the source device and the target device.

[0092] As an optional implementation provided in this application, the calculation module 402 is used to: perform cross-clock domain synchronization processing on the message round-trip delay and link bandwidth occupancy data; calculate the average message round-trip delay of multiple sampling periods based on the message round-trip delay after cross-clock domain synchronization processing; calculate the ratio of the link bandwidth occupancy data after cross-clock domain synchronization processing to the total link bandwidth; and multiply the average message round-trip delay and the ratio to obtain the link saturation factor.

[0093] As an optional implementation provided in this application embodiment, after starting the resource migration, the startup module 403 is further configured to: perform a hardware locking operation on the configuration space of the source device; and allocate a logical identifier to the target device.

[0094] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: determine the maximum transmission bandwidth of the migration traffic based on the total link bandwidth, real-time core service traffic and preset redundant bandwidth during the resource migration process; and control the migration traffic of the resource migration process according to the maximum transmission bandwidth.

[0095] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: during the resource migration process, in response to a service access request for a data block in the resource migration process, monitor the physical layer packets transmitted on the computing fast link in real time, identify idle packets in the computing fast link, and migrate resources within the idle time slot corresponding to the idle packets.

[0096] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: during the resource migration process, collect valid cache line information of the source device in the modified state and exclusive state, and generate a cache state recovery table; based on the cache state recovery table, locally replicate a cache state consistent with that of the source device on the target device; determine the cache mirror matching degree based on the ratio of the number of valid cache hits on the target device to the number of modified dirty cache lines on the source device; the cache mirror matching degree is used to characterize the cache mirror synchronization effect; when the cache mirror matching degree reaches a preset hardware threshold and all dirty page data of the source device is synchronized, perform an atomic handshake switching operation between the source device and the target device, clear the in-transit packets of the fast computing link, and update the global routing table entries to switch the service traffic to the target device.

[0097] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: generate a state reclamation instruction after updating the global routing table entry; in response to the state reclamation instruction, terminate the hardware caching of service write requests by the dual write cache, and terminate the synchronous writing of service write requests to the source device and the target device; perform a clearing operation on the shadow address translation table; reclaim the interconnection hardware resources occupied by the source device, and return the interconnection hardware resources to the system resource pool.

[0098] As an optional implementation provided in this application embodiment, the resource migration module 404 is used to compare the verification feature values ​​of the data written from the source end and the data written from the target end during the process of synchronously writing the business write request to the source end device and the target end device through the dual write cache; if the verification feature values ​​are inconsistent, the business write request is rewritten to the source end device and the target end device.

[0099] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: trigger a local retry operation and count the number of retries if a retryable exception occurs during the resource migration process; compare the number of retries with a preset maximum retry threshold; if the number of retries is less than the preset maximum retry threshold, continue to execute the local retry operation; if the number of retries is greater than or equal to the preset maximum retry threshold, terminate the resource migration process and output a hardware fault alarm signal.

[0100] As an optional implementation provided in this application embodiment, the resource migration module 404 is further configured to: monitor link status, device operating status, data verification status and routing switching status during the resource migration process, identify migration anomaly events, and execute corresponding hierarchical fault tolerance strategies for different migration anomaly events.

[0101] As an optional implementation provided in this application embodiment, the resource migration module 404 executes corresponding hierarchical fault tolerance strategies for different migration anomaly events, specifically for: When the migration process is interrupted, record the location of the synchronization breakpoint; Once the link status of the fast link has returned to normal, the breakpoint resumption synchronization operation is performed based on the synchronization breakpoint location.

[0102] As an optional implementation method provided in this application embodiment, the resource migration module 404 executes corresponding hierarchical fault tolerance strategies for different migration anomaly events. Specifically, it is used to: roll back the updated routing configuration, lock the service operation permissions of the source device, and maintain the source device's ability to accept service read and write requests when the target device is abnormal.

[0103] As an optional implementation method provided in this application embodiment, the resource migration module 404 executes corresponding hierarchical fault tolerance strategies for different migration anomaly events. Specifically, it is used to generate fault alarm information and switch the service transmission path back to the original service link when the data written by the source end and the data written by the target end are inconsistent after multiple verifications.

[0104] As an optional implementation provided in this application embodiment, the resource migration module 404 executes corresponding hierarchical fault tolerance strategies for different migration anomaly events. Specifically, it is used to: roll back the routing table entry configuration and cancel the service traffic conversion operation within a single message transmission cycle when the service traffic switching operation fails, so that the service traffic returns to the original transmission link. The business traffic switching operation includes at least one of the following: atomic handshake confirmation operation and routing table entry update operation.

[0105] For a description of the features in the embodiment of the resource migration device for computing fast links, please refer to the relevant description in the embodiment of the resource migration method for computing fast links, which will not be repeated here.

[0106] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 5As shown, the electronic device includes a memory 501 and a processor 502. The memory 501 stores a computer program, and the processor 502 is configured to run the computer program to perform the steps in any of the above embodiments of the resource migration method for computing fast links.

[0107] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the resource migration method for fast computing links.

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

[0109] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the resource migration method for fast computing links.

[0110] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the resource migration method for fast computing links.

[0111] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-chip (SoC), a complex programmable logic device (CPLD), a microcontroller unit (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

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

[0113] The resource migration and electronic device for a fast computing link provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for resource migration in computational fast links, characterized in that, include: Obtain and calculate the round-trip time of messages and the bandwidth usage of the fast link; Calculate the link saturation factor based on the message round-trip delay and the link bandwidth usage data; The link saturation factor is used to characterize the congestion level of the computed fast link; When the link saturation factor exceeds a preset hardware threshold, resource migration is initiated. During resource migration, the physical address of the source device is dynamically redirected through a shadow address translation table, so that service access requests can address both the source and target devices simultaneously; and, service write requests are hardware-cached through a dual-write cache and synchronously written to both the source and target devices.

2. The method according to claim 1, characterized in that, The step of calculating the link saturation factor based on the message round-trip delay and link bandwidth occupancy data includes: The round-trip time of the message and the link bandwidth usage data are synchronized across clock domains. Based on the round-trip time of the message after cross-clock domain synchronization processing, calculate the average round-trip time of the message across multiple sampling periods; Calculate the ratio of the data occupied by the link bandwidth after cross-clock domain synchronization processing to the total link bandwidth; The link saturation factor is obtained by multiplying the average round-trip delay of the message by the ratio.

3. The method according to claim 1, characterized in that, When the link saturation factor exceeds the hardware preset threshold, the resource migration process is triggered. During the resource migration process, the physical address of the source device is dynamically redirected through the shadow address translation table, so that the service access request can address both the source device and the target device at the same time. Furthermore, before hardware caching of business write requests through dual-write caching and synchronous writing to the source device and the target device, the method further includes: Perform a hardware lock operation on the configuration space of the source device; Assign logical identifiers to the target device.

4. The method according to claim 1, characterized in that, The method further includes: During the resource migration process, the maximum transmission bandwidth of the migration traffic is determined based on the total link bandwidth, real-time core business traffic, and preset redundant bandwidth. The migration traffic during the resource migration process is controlled based on the maximum transmission bandwidth.

5. The method according to claim 1, characterized in that, The method further includes: During resource migration, in response to service access requests for data blocks in the resource migration process, the physical layer packets transmitted by the computing fast link are monitored in real time to identify idle packets in the computing fast link. Migrate resources within the idle time slot corresponding to the idle message.

6. The method according to claim 1, characterized in that, The method further includes: During resource migration, valid cache line information of the source device in modified and exclusive states is collected, and a cache state recovery table is generated. Based on the cache state recovery table, the cache state consistent with that of the source device is replicated locally on the target device. The cache mirror matching degree is determined by the ratio of the number of valid cache hits on the target device to the number of modified dirty cache lines on the source device; the cache mirror matching degree is used to characterize the cache mirror synchronization effect. When the cache mirror matching degree reaches the preset hardware threshold and all dirty page data of the source device is synchronized, an atomic handshake switching operation is performed between the source device and the target device to clear the in-transit packets of the fast computing link and update the global routing table entries to switch the service traffic to the target device.

7. The method according to claim 6, characterized in that, The method further includes: After updating the global routing table entries, a state reclamation command is generated; In response to the state reclamation instruction, the hardware caching of the service write request by the dual write cache is terminated, and the synchronous writing of the service write request to the source device and the target device is terminated. Perform a clear operation on the shadow address translation table; The interconnect hardware resources occupied by the source device are reclaimed and returned to the system resource pool.

8. The method according to claim 1, characterized in that, Hardware caching of business write requests is performed through dual-write caching, and the requests are synchronously written to both the source device and the target device, including: During the process of synchronously writing business write requests to the source device and the target device through dual write caching, the verification feature values ​​of the source-side written data and the target-side written data are compared. If the verification feature values ​​are inconsistent, the service write request will be rewritten to both the source device and the target device.

9. The method according to claim 1, characterized in that, The method further includes: If a retryable exception occurs during resource migration, a local retry operation is triggered, and the number of retries is counted. The number of retries is compared with a preset maximum retry threshold; If the number of retries is less than the preset maximum retry threshold, the local retry operation will continue to be performed. If the number of retries is greater than or equal to the preset maximum retry threshold, the resource migration process is terminated and a hardware fault alarm signal is output.

10. The method according to claim 1, characterized in that, The method further includes: During resource migration, monitor link status, device operating status, data verification status, and route switching status to identify migration anomalies. For different migration anomalies, corresponding hierarchical fault tolerance strategies are executed.

11. The method according to claim 10, characterized in that, The implementation of corresponding hierarchical fault tolerance strategies for different migration anomaly events includes: When the migration process is interrupted, record the location of the synchronization breakpoint; Once the link status of the fast-link computation is restored to normal, a breakpoint resumption synchronization operation is performed based on the synchronization breakpoint location.

12. The method according to claim 10, characterized in that, The implementation of corresponding hierarchical fault tolerance strategies for different migration anomaly events includes: When a target device malfunctions, the updated routing configuration is rolled back, the service operation permissions of the source device are locked, and the source device is allowed to accept service read and write requests.

13. The method according to claim 10, characterized in that, The implementation of corresponding hierarchical fault tolerance strategies for different migration anomaly events includes: When the data written by the source end and the data written by the target end are inconsistent after multiple verifications, a fault alarm message is generated, and the service transmission path is switched back to the original service link.

14. The method according to claim 10, characterized in that, The implementation of corresponding hierarchical fault tolerance strategies for different migration anomaly events includes: When the service traffic switching operation fails, the routing table entry configuration is rolled back within a single message transmission cycle, the service traffic switching operation is canceled, and the service traffic returns to the original transmission link. The service traffic switching operation includes at least one of an atomic handshake confirmation operation and a routing table entry update operation.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the resource migration method for a fast computing link as described in any one of claims 1 to 14 when executing the computer program.

Images