Ethernet-based CXL protocol extension method, device and system

Abstract

The invention discloses a CXL protocol extension method, device and system based on the Ethernet. The method comprises the following steps of: carrying out long-distance expansion interconnection on a CXL (Compute Express Link) protocol by using Ethernet as a physical transmission medium; by bearing the CXL protocol on the Ethernet, the range of memory pooling is expanded from the rack level to the whole data center (kilometer level), and the potential of the CXL technology is thoroughly released; through protocol translation, label management and flow control realized by pure hardware, an operating system kernel and a software protocol stack are bypassed, so that the end-to-end memory access delay is far lower than that of any software-based network storage scheme, and a reliable request-response tracking and timeout retransmission mechanism is realized through a hardware label manager. By distinguishing the control flow and the data flow, differentiated QoS guarantee is provided for different types of memory flows, and the stability of the system under high load is ensured.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer architecture and data center, and particularly relates to an Ethernet-based CXL protocol extension method, device and system. BACKGROUND

[0002] With the rapid development of artificial intelligence (AI), large language models (LLM) and high-performance computing (HPC), the demand for computing power in data centers is growing exponentially. However, the improvement of computing performance is facing a serious "memory wall" bottleneck: the memory capacity and bandwidth of a single computing node (such as CPU or GPU) cannot meet the storage and access requirements of massive model parameters and dynamic data.

[0003] CXL (Compute Express Link) protocol, as an open high-speed interconnection standard, provides a theoretical basis for memory pooling and memory expansion by providing memory consistency semantics (CXL.mem, CXL.cache), and is considered as a key technology to solve the "memory wall" problem. However, CXL protocol is based on PCIe physical layer, and the transmission distance of its high-speed signal is usually limited within 1 meter, which makes the application scenario of CXL limited to a single server chassis or adjacent racks, and unable to realize large-scale and long-distance memory resource pooling at the data center level.

[0004] On the other hand, Ethernet, as the most popular and cost-effective interconnection technology in data centers, can support connections up to several kilometers. However, the standard Ethernet and its TCP / IP protocol stack are designed for data packet transmission and do not have the low-latency, byte-addressed memory semantics required by CXL. Directly used for memory access will introduce unacceptable performance overhead.

[0005] Therefore, there is an urgent need in the art for a technical solution that can combine the memory semantic advantages of CXL protocol with the distance and scale advantages of Ethernet to realize real data center-level memory pooling and break the limitations of existing technologies.

[0006] There are already various attempts in the industry to extend memory access through the network, but all have obvious deficiencies:

[0007] 1. RDMA (Remote Direct Memory Access) based solutions: such as RoCE (RDMA over Converged Ethernet) and iWARP, although they can also provide low-latency memory access over Ethernet, their core is based on a message passing or one-sided memory operation (One-Sided Put / Get) model. Compared with the present invention, these solutions mainly have two defects: first, they do not natively support the cache coherence semantics defined by CXL.cache, and cannot seamlessly and consistently integrate remote memory into the CPU's memory hierarchy, which is fatal for accelerator and application scenarios that require cache coherence. Second, RDMA requires a specific programming model and API, and cannot be completely transparent to the upper-layer application like the present invention, so the application software needs to be modified a lot to use remote memory.

[0008] 2. Other memory semantic network protocols: such as the former Gen-Z protocol, which also aims to build a memory semantic fabric. However, with the development of the industry, CXL has gained overwhelming market support due to its close integration with the PCIe ecosystem, and Gen-Z has been incorporated into the CXL alliance. Therefore, extending based on a protocol that has been eliminated by the market does not have industrialization prospects. The present invention is based on the current mainstream and promising CXL standard, and has better ecological compatibility and practical significance.

[0009] 3. Private high-speed interconnection technology: such as NVIDIA's NVLink / NVSwitch technology, although they provide extremely high bandwidth and low latency, and support memory sharing between GPUs, but their essence is a closed and proprietary ecosystem. Users must purchase a complete set of hardware from the same manufacturer, which is costly and lacks flexibility. In contrast, the present invention is based on the open CXL standard and the general Ethernet standard, allowing different manufacturers' computing devices and memory devices to interconnect and interoperate, breaking the vendor lock-in and having significant cost and ecological advantages.

[0010] 4. Pure software-implemented distributed shared memory (DSM): such solutions simulate shared memory over a general-purpose network through operating systems and software libraries. The biggest problem is that the performance overhead is huge, because all memory accesses need to go through the operating system kernel and complex software protocol stack, resulting in a delay that is several orders of magnitude higher than hardware solutions, completely unable to meet the needs of high-performance computing scenarios. The present invention achieves ultra-low latency through a pure hardware protocol conversion engine.

[0011] In summary, existing technologies either cannot provide CXL core cache coherence and application transparency, or rely on closed and expensive private ecosystems, or have too poor performance to have practical value. SUMMARY

[0012] The technical problem solved by the present application is to provide an Ethernet-based CXL protocol extension method, device and system, which solves the technical problems that the CXL technology in the prior art is limited by physical distance and cannot be deployed on a large scale, and the existing Ethernet technology cannot efficiently carry memory access semantics.

[0013] The present application solves the above technical problems by adopting the following technical solutions:

[0014] The CXL over Ethernet (CoE) network packet encapsulation structure includes a header, a payload and a check sequence, the header includes Ver / Type, QoS / FlowID, network transaction Tag, Host / VF ID, Opcode, data length and memory address arranged in sequence, wherein QoS / FlowID is set by a traffic classification module and is used for priority scheduling by a network switch; the network transaction Tag is allocated a unique ID by a hardware tag manager and is used for accurate matching of requests and responses.

[0015] The payload part stores the data to be written for a write request, and is empty for a read request.

[0016] The Ethernet-based CXL protocol conversion device includes a CXL interface module for CXL protocol interaction with a host computing unit;

[0017] An Ethernet interface module for data transmission with an Ethernet Fabric;

[0018] A protocol translation engine connected with the CXL interface module and the Ethernet interface module for performing protocol analysis, encapsulation and reconstruction.

[0019] The protocol translation engine internally includes at least:

[0020] A traffic classification and QoS module for identifying the type of CXL request on the outgoing path and marking it with the corresponding QoS identifier;

[0021] A hardware tag manager for allocating, associating and recycling network transaction tags and maintaining a pending request table with a timeout detection mechanism;

[0022] A frame processor for generating and analyzing network packets according to a predefined frame format, the frame format using the CXL over Ethernet network packet encapsulation structure.

[0023] The Ethernet-based CXL protocol conversion system includes a host, a protocol conversion device, an Ethernet switching fabric, and a remote memory resource pool. The protocol conversion device is the aforementioned Ethernet-based CXL protocol conversion device. The host is connected to the protocol conversion device via a native CXL bus. One end of the protocol conversion device is a CXL interface, and the other end is an Ethernet interface. The Ethernet interface is connected to a standard data center Ethernet fabric, and the other end of the Ethernet fabric is connected to the remote memory resource pool, which includes one or more remote memory nodes.

[0024] The CXL memory request sent by the host is converted into a CXL over Ethernet network packet by the protocol conversion device, routed to the remote memory node via Ethernet Fabric, and after the read and write are completed, the response is returned along the same path.

[0025] The CXL protocol extension method based on Ethernet includes outbound data processing and inbound processing. The outbound processing parses memory access requests conforming to the CXL protocol from the host computing unit, and performs traffic classification, transaction label management, and protocol encapsulation in sequence according to the parsing results. The CXL over Ethernet network packet is encapsulated in a standard Ethernet frame and sent to the target memory node through the Ethernet physical interface.

[0026] The incoming processing receives CXL over Ethernet network packets carrying CXL responses from the Ethernet physical interface and parses them. Based on the parsing results, it performs transaction tag matching and protocol reconstruction in sequence to obtain a response transaction that conforms to the CXL protocol specification. The response transaction is then sent back to the host computing unit through the CXL interface, and the completed response transaction is removed from the pending request table, and the network transaction tag is reclaimed.

[0027] The results of the outbound processing and parsing include key information such as request type, target memory address, data size, and CXL transaction tag.

[0028] The traffic classification identifies the request as either a data flow or a control flow based on the request type; the transaction label management assigns a globally unique network transaction label to the request and establishes a mapping relationship between the network transaction label and the original CXL transaction context, storing it in a hardware-managed pending request table.

[0029] The incoming processing parses CXL over Ethernet network packets, extracts network transaction tags and response data; uses the extracted network transaction tags to search and match the original CXL transaction context in the pending request table; and reconstructs a response transaction that conforms to the CXL protocol specification based on the matched CXL transaction context and response data.

[0030] Compared with the prior art, the present application has the following beneficial effects:

[0031] 1、The CXL-over-Ethernet scheme provided by the present application first completely and transparently extends all memory semantics of CXL in a hardware-accelerated manner on an open and standard Ethernet infrastructure, and solves the fundamental defects of the prior art.

[0032] 2、Breaking through physical limitations: By carrying the CXL protocol on the Ethernet, the range of memory pooling is extended from the rack level to the entire data center (kilometer level), and the potential of CXL technology is fully released.

[0033] 3、Maintaining memory semantics and application transparency: The entire conversion process is completely transparent to the upper layer application, and the application program can access the remote shared memory like accessing local memory without any modification, thus preserving the core value of CXL.

[0034] 4、Ultra-low latency performance: Protocol translation, tag management and flow control realized by pure hardware bypass the operating system kernel and software protocol stack, so that the end-to-end memory access delay is much lower than any software-based network storage solution.

[0035] 5、Cost-effective and eco-compatible: Reusing the standard Ethernet infrastructure ubiquitous in data centers greatly reduces deployment costs. The open architecture allows any computing device supporting CXL to access, breaking the monopoly of the private interconnection ecosystem.

[0036] 6、High reliability and quality of service: Reliable request-response tracking and timeout retransmission mechanism is realized by hardware tag manager. By distinguishing control flow and data flow, differentiated QoS guarantee is provided for different types of memory traffic, ensuring the stability of the system under high load. BRIEF DESCRIPTION OF DRAWINGS

[0037] Figure 1 It is a CXL over Ethernet system architecture schematic diagram of the present application.

[0038] Figure 2 It is an internal logic block diagram of the protocol conversion device of the present application.

[0039] Figure 3 It is an encapsulation structure schematic diagram of the CXL-over-Ethernet (CoE) network packet defined by the present application in the Ethernet frame.

[0040] Figure 4 It is a method flowchart of the egress processing flow of the present application.

[0041] Figure 5Method flow chart for Ingress processing flow of the present application.

[0042] Figure 6 Working mechanism schematic diagram of the hardware tag manager of the present application.

[0043] Figure 7 System architecture schematic diagram of the data center system of the present application. DETAILED DESCRIPTION

[0044] The structure and working process of the present application are further described below in combination with the drawings.

[0045] The purpose of the present application is how to design a method and device capable of transparently, low-delay and reliably transmitting CXL memory transactions on a standard Ethernet, so as to build an extensible data center level memory network. The Ethernet is used as a physical transmission medium, and a long-distance expansion interconnection method, protocol conversion device and system of the CXL (Compute Express Link) protocol are provided.

[0046] Firstly, a CXL over Ethernet (abbreviated as CoE) network packet encapsulation structure is constructed, which is encapsulated in a standard Ethernet frame and distinguished from other network traffic by a self-defined EtherType (such as 0xCOEC).

[0047] The CoE network packet encapsulation structure includes a CoE header, a payload and a check sequence, the CoE header includes Ver / Type, QoS / FlowID, network transaction Tag, Host / VF ID, Opcode, data length and memory address arranged in sequence; wherein the QoS / FlowID is set by a traffic classification module and is used for priority scheduling by a network switch; the network transaction Tag is allocated a unique ID by a hardware tag manager and is used for accurate matching of requests and responses.

[0048] Then, a CXL protocol conversion device based on Ethernet is designed, which includes a CXL interface module for interacting with a host computing unit in CXL protocol;

[0049] an Ethernet interface module for data transceiving with an Ethernet Fabric;

[0050] a protocol translation engine connected with the CXL interface module and the Ethernet interface module respectively, for performing protocol analysis, encapsulation and reconstruction.

[0051] and a CXL protocol conversion system based on the protocol conversion device, including a host, a protocol conversion device, an Ethernet switch Fabric, and a remote memory resource pool, the host is connected to the protocol conversion device through a native CXL bus, one end of the protocol conversion device is a CXL interface, the other end is an Ethernet interface, and the Ethernet interface is connected to a standard data center Ethernet Fabric, the other end of the Ethernet Fabric is connected to the remote memory resource pool, and the remote memory resource pool includes one or more remote memory nodes.

[0052] The system can be applied to any scene or project that needs to use CXL to build a memory resource pool, such as a data center and a server.

[0053] Finally, based on the system, a CXL protocol extension method based on Ethernet is proposed, including data out processing and in processing, the out processing analyzes the memory access request from the host computing unit in accordance with the CXL protocol, classifies the traffic, manages the transaction label, and encapsulates the protocol according to the analysis result, encapsulates the CoE network packet in a standard Ethernet frame, and sends it to the target memory node through the Ethernet physical interface.

[0054] The in processing receives the CoE network packet carrying the CXL response from the Ethernet physical interface for analysis, and according to the analysis result, performs transaction label matching and protocol reconstruction in sequence to obtain a response transaction in accordance with the CXL protocol specification; the response transaction is sent back to the host computing unit through the CXL interface, and the completed response transaction is removed from the to-be-processed request table and the network transaction label is recycled.

[0055] Specific embodiments, such as Figures 1 to 7 are shown.

[0056] The embodiment provides a protocol conversion device, mainly composed of a CXL interface module, an Ethernet interface module and a core protocol translation engine; wherein:

[0057] A CXL interface module is used for CXL protocol interaction with a host computing unit;

[0058] An Ethernet interface module is used for data transmission with an Ethernet Fabric;

[0059] A protocol translation engine is connected with the above two interface modules, and the core is a protocol conversion processor for performing protocol analysis, encapsulation and reconstruction. The engine internally at least includes:

[0060] A traffic classification and QoS module is used for identifying the type of CXL request on the out path and marking the corresponding QoS identifier;

[0061] A hardware tag manager for efficiently allocating, associating, recycling network transaction tags, and maintaining a pending request table with a timeout detection mechanism; the hardware tag manager is configured to, while allocating a tag for a request, start a hardware timer associated with the tag for timeout detection.

[0062] Figure 6 is a schematic diagram of the hardware tag manager, which is the core of guaranteeing the reliability of long-distance transmission. The specific processing flow is as follows:

[0063] Allocation: When a CXL request arrives, the allocation / recycling logic takes an idle network transaction Tag from the idle tag pool (usually implemented by BRAM or FIFO).

[0064] Association: associate the Tag with the CXL context of the request (such as the original CXL Tag, host ID, etc.), and write this entry into the pending request table. At the same time, record the current timestamp.

[0065] Matching and timeout: when a CoE response packet arrives, use the Tag carried by it to perform a hardware line-speed lookup in the table, find the matching entry to reconstruct the CXL response. At the same time, a separate hardware timer scans the table, and if the timestamp of a certain entry exceeds the preset threshold and no response is received, the timeout / retransmission logic is triggered.

[0066] Recycling: once the response is successfully processed, or the request is confirmed to have failed due to timeout, the allocation / recycling logic clears the entry from the table, and returns the Tag to the idle tag pool for reuse.

[0067] This pure hardware management mechanism can support tracking of tens of thousands of concurrent in-flight requests, and its performance far exceeds that of a software hash table.

[0068] A CoE frame processor for generating and parsing network packets according to a predefined CoE frame format.

[0069] The predefined CoE frame format is one of the core innovations of the present scheme, as shown in Figure 3

[0070] ​The CoE network packet encapsulation structure is encapsulated in a standard Ethernet frame, and is distinguished from other network traffic by a custom EtherType (such as 0xCOEC). It includes a CoE header, a payload, and a check sequence. The CoE header includes, in order, a Ver / Type, a QoS / FlowID, a network transaction Tag, a Host / VF ID, an Opcode, a data length, and a memory address. The QoS / FlowID is set by a traffic classification module and is used for priority scheduling by a network switch. The network transaction Tag is a unique ID assigned by a hardware tag manager and is used for accurate matching of requests and responses. Specifically,

[0071] The CoE header includes:

[0072] Ver / Type: protocol version and packet type (request / response / management).

[0073] QoS / FlowID: set by a traffic classification module and used for priority scheduling by a network switch. For example, 0x01 represents a high-priority control flow, and 0x02 represents a normal data flow.

[0074] Network transaction Tag: a unique ID assigned by a hardware tag manager and used for accurate matching of requests and responses.

[0075] Host / VF ID: used to support multi-tenancy and virtualization environments.

[0076] Opcode: a specific CXL command, such as Mem.Read.

[0077] Data length and memory address: core parameters for transmitting requests.

[0078] Payload: for write requests, this stores the data to be written. For read requests, this section is empty.

[0079] The header portion of the CoE frame format also includes at least one of the following fields: a protocol version field, a host or virtual machine identifier field, a CXL opcode field, or a memory address field.

[0080] The specific internal structure and data processing flow of the protocol conversion device are as shown in Figure 2 , including two directions.

[0081] Outbound path (solid arrow): CXL memory request enters from CXL interface, first parsed by CXL.mem parser. Then, traffic classification and QoS module tags it with QoS according to request type (e.g. Mem.Read for data flow, MCTP management packet for control flow). Then, hardware tag manager assigns it a network Tag. Finally, CoE frame processor encapsulates all information into CoE packet, which is sent out by Ethernet interface.

[0082] Inbound path (dashed arrow): CoE response packet enters from Ethernet interface, first unpacked by CoE frame processor. Hardware tag manager matches to original request according to Tag in packet. Finally, CXL.mem re-creator generates CXL response, which is returned to host through CXL interface.

[0083] Based on the above structure of the CXL protocol conversion system, including a host, a protocol conversion device, an Ethernet switch Fabric and a remote memory resource pool, the host is connected to the protocol conversion device through a native CXL bus, one end of the protocol conversion device is a CXL interface, the other end is an Ethernet interface, and the Ethernet interface is connected to a standard data center Ethernet Fabric, the other end of the Ethernet Fabric is connected to a remote memory resource pool, and the remote memory resource pool includes one or more remote memory nodes.

[0084] Specifically, the system can be applied to any scene or project that needs to use CXL to build a memory resource pool, such as a data center, a server, etc. As shown in Figure 7 The host includes a CPU or GPU computing unit, which is connected to the protocol conversion device through a native CXL bus. The protocol conversion device is the core of the application, one end of which is a CXL interface, and the other end is an Ethernet interface. The device is connected to a standard data center Ethernet Fabric, which is composed of a series of Ethernet switches. The other end of the network is connected to one or more remote memory nodes, which can be Just a Bunch of Memory (JBOM) devices or ordinary servers with a large amount of memory. The CXL memory request sent by the host is converted into a CoE packet by the device, routed to the memory node through the Ethernet Fabric, and the response is returned on the original path after completing the read and write. The working content of CXL over Ethernet at each layer of the network is shown in Table 1.

[0085] Table 1

[0086]

[0087] For the above device and system, the present scheme provides a CXL protocol extension method based on Ethernet, including:

[0088] I. Egress, comprising the following steps:

[0089] a. At the protocol conversion device, receiving a CXL protocol compliant memory access request from a host computing unit.

[0090] b. Parsing the CXL memory access request to extract key information such as request type, target memory address, data size, and CXL transaction tag.

[0091] c. Traffic classification: identifying the request as a data flow (e.g. high frequency read / write requests) or a control flow (e.g. low frequency address mapping, configuration management messages) based on the request type.

[0092] d. Transaction tag management: assigning a globally unique network transaction tag to the request and establishing a mapping between the network transaction tag and the original CXL transaction context, storing in a hardware managed Pending Request Table.

[0093] e. Protocol encapsulation: generating a CoE network packet based on a predefined CXL-over-Ethernet (CoE) frame format. The CoE frame format includes at least a Quality of Service (QoS) identifier to distinguish data flow from control flow, the network transaction tag, and the extracted key information.

[0094] f. Encapsulating the CoE network packet in a standard Ethernet frame and sending it to the target memory node through an Ethernet physical interface.

[0095] II. Ingress, comprising the following steps:

[0096] a. At the protocol conversion device, receiving a CoE network packet carrying a CXL response from an Ethernet physical interface.

[0097] b. Parsing the CoE network packet to extract the network transaction tag and response data.

[0098] c. Transaction tag matching: using the extracted network transaction tag to find and match the original CXL transaction context in the Pending Request Table.

[0099] d. Protocol reconstruction: reconstructing a CXL protocol compliant response transaction based on the matched CXL transaction context and response data.

[0100] e. Sending the CXL response transaction back to the host computing unit through a CXL interface, removing the completed transaction from the Pending Request Table, and recycling the network transaction tag.

[0101] The step of assigning the network transaction tag is performed by a hardware tag manager, which comprises:

[0102] Obtaining a tag from a hardware-implemented free tag pool;

[0103] Storing the tag in a hardware-implemented pending request table after associating it with the CXL context;

[0104] Returning the tag to the free tag pool after the request is completed or timed out.

[0105] The hardware tag manager further comprises a timeout detection mechanism, which periodically checks the entries in the pending request table and triggers an error handling procedure when the waiting time of a request exceeds a preset threshold.

[0106] The step of classifying the request as a data flow or a control flow is based on the opcode type of the parsed CXL request, and different quality of service identifier values are assigned to data flows and control flows.

[0107] It should be understood that the present solution is not limited to the specific embodiments described above, and that devices and structures not described in detail should be understood as being implemented in a manner common in the art; any person skilled in the art, without departing from the scope of the technical solution of the present solution, can make many possible changes and modifications to the technical solution of the present solution by using the disclosed methods and technical contents, or modify equivalent embodiments with equivalent changes, which does not affect the essential content of the present solution. Therefore, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present solution, without departing from the content of the technical solution of the present solution, still belongs to the protection scope of the technical solution of the present solution.

Claims

1. A CXL over Ethernet network packet encapsulation structure comprising a header, a payload and a check sequence, characterized in that: The header includes Ver / Type, QoS / FlowID, network transaction tag, Host / VF ID, Opcode, data length, and memory address, set sequentially. Among them, QoS / FlowID is set by the traffic classification module and used by the network switch for priority scheduling. The network transaction tag is assigned a unique ID by the hardware tag manager for precise matching of requests and responses.

2. The CXL over Ethernet network packet encapsulation structure of claim 1, wherein: In the payload section, for write requests, the data to be written is stored; for read requests, this section is empty.

3. The CXL protocol conversion device based on Ethernet, characterized in that: Includes a CXL interface module for interacting with the host computing unit via the CXL protocol; Ethernet interface module, used for sending and receiving data with Ethernet Fabric; The protocol translation engine connects to both the CXL interface module and the Ethernet interface module to perform protocol parsing, encapsulation, and reconstruction.

4. The Ethernet-based CXL protocol conversion device of claim 3, wherein: The protocol translation engine internally includes at least: A traffic classification and QoS module is used to identify the type of CXL request on the outbound path and assign it the corresponding QoS identifier; A hardware tag manager is used to assign, associate, and reclaim network transaction tags, and maintain a pending request table that includes a timeout detection mechanism; A frame processor for generating and parsing network packets according to a predefined frame format, said frame format employing the CXL over Ethernet network packet encapsulation structure as described in claim 1 or 2.

5. The CXL protocol conversion system based on Ethernet, characterized in that: The system includes a host, a protocol conversion device, an Ethernet switching fabric, and a remote memory resource pool. The protocol conversion device is the Ethernet-based CXL protocol conversion device as described in claim 3. The host is connected to the protocol conversion device via a native CXL bus. One end of the protocol conversion device is a CXL interface, and the other end is an Ethernet interface. The Ethernet interface is connected to a standard data center Ethernet fabric, and the other end of the Ethernet fabric is connected to a remote memory resource pool, which includes one or more remote memory nodes.

6. The Ethernet-based CXL protocol conversion system of claim 5, wherein: The CXL memory request sent by the host is converted into a CXL over Ethernet network packet by the protocol conversion device, routed to the remote memory node via Ethernet Fabric, and after the read and write are completed, the response is returned along the same path.

7. The method of extending CXL protocol over Ethernet, characterized in that: It includes outbound and inbound data processing. The outbound processing parses memory access requests from the host computing unit that conform to the CXL protocol. Based on the parsing results, it performs traffic classification, transaction label management, and protocol encapsulation in sequence. The CXL over Ethernet network packet is encapsulated in a standard Ethernet frame and sent to the target memory node through the Ethernet physical interface. The incoming processing receives CXL over Ethernet network packets carrying CXL responses from the Ethernet physical interface, parses them, and performs transaction tag matching and protocol reconstruction according to the parsing results to obtain a response transaction that conforms to the CXL protocol specification. The response transaction is sent back to the host computing unit via the CXL interface, and the completed response transaction is removed from the pending request table, and the network transaction tag is revoked.

8. The Ethernet-based CXL protocol extension method according to claim 7, characterized in that: The results of the outbound processing and parsing include key information such as request type, target memory address, data size, and CXL transaction tag.

9. The Ethernet-based CXL protocol extension method according to claim 8, characterized in that: The traffic classification identifies the request as either a data flow or a control flow based on the request type; the transaction label management assigns a globally unique network transaction label to the request and establishes a mapping relationship between the network transaction label and the original CXL transaction context, storing it in a hardware-managed pending request table.

10. The Ethernet-based CXL protocol extension method according to claim 9, characterized in that: Incoming processing parses CXL over Ethernet network packets, extracts network transaction tags and response data; using the extracted network transaction tags, searches for and matches the original CXL transaction context in the pending request table; Based on the matched CXL transaction context and response data, a response transaction conforming to the CXL protocol specification is reconstructed.

Images