Cross-device cache processing method, electronic device and computer program product

Abstract

The embodiment of the invention provides a cross-device cache processing method, an electronic device and a computer program product, and the method comprises the steps: a relay device sends a detection request message to a second device, the detection request message is added with relay time, and the relay time is the time when the relay device receives the detection request message; receiving a detection response message sent by the second device and forwarded by the relay device, wherein the time required for the relay device to exhaust the cache is added in the detection response message; according to the embodiment of the invention, the first device determines to share the cache with the relay device, and determines the priority-based flow control PFC cache parameter based on the relay time and the time required for the relay device to exhaust the cache, so that the problem of packet loss caused by insufficient cache of the single device in a long-distance interconnection scene in the related technology can be solved, and the first device shares the cache with the relay device. The cache sharing mechanism enhances the interconnection flexibility of the data center and improves the data transmission efficiency.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a cross-device caching method, electronic device, and computer program product. Background Technology

[0002] In data center interconnect scenarios, Priority-based Flow Control (PFC) is typically enabled on data communication devices to address sudden packet loss during congestion or link failures by buffering incoming packets. The PFC buffer configuration varies depending on the interface bandwidth and interconnect length. There are generally two methods for configuring PFC buffer parameters: manual and automatic. The manual method involves the network administrator setting appropriate PFC buffer parameters based on prior knowledge of the interconnect link length. The automatic method involves the device automatically sending a distance probe packet, calculating the link distance based on the time parameter in the peer's response packet and the fiber optic transmission delay, and then configuring the PFC buffer parameters accordingly.

[0003] Existing technical implementations already support calculating the distance of long-distance links between devices based on timestamp information by sending 1588 messages. Figure 1 This is a diagram illustrating how to calculate the distance of long-distance links between devices based on timestamp information in related technologies. Figure 1 ,like Figure 1 As shown, device R2 sends a distance probe message at time t1 and records the timestamp in the message; device R1 receives the message at time t2 and records the receiving timestamp; after detecting that the message is a distance probe message, device R1 returns the message to device R2, and simultaneously records the return time t3 timestamp in the message; after receiving the return message, device R2 writes the time t4 into the message and reports it to the R2 control plane. After receiving the returned probe message, device R2 calculates the distance between the two devices based on the four timestamps.

[0004] After calculating the long-distance link length, device R2, based on its own interface bandwidth and forwarding capabilities, automatically issues PFC cache parameters to achieve zero packet loss on the long-distance link. Device R1 follows the same method to determine its optimal configuration.

[0005] This method has significant limitations; when the buffers on both ends of the device are small, it cannot support long-distance device interconnection. Figure 2 This is a diagram illustrating how to calculate the distance of long-distance links between devices based on timestamp information in related technologies. Figure 2 ,like Figure 2 As shown, when the cache size of devices R2 and R3 only supports 100KM long-distance interconnection, the problem of packet loss caused by insufficient cache of a single device in long-distance interconnection scenarios occurs. Summary of the Invention

[0006] This application provides a cross-device caching processing method, electronic device, and computer program product to at least solve the problem of packet loss caused by insufficient caching of a single device in long-distance interconnection scenarios in related technologies.

[0007] According to one embodiment of this application, a cross-device caching processing method is provided, executed by a first device, comprising:

[0008] A probe request message is sent to a second device via a relay device, wherein the probe request message includes a relay time, which is the time when the relay device receives the probe request message;

[0009] The relay device receives a probe response message sent by a second device, which is forwarded by the relay device. The probe response message contains the time required for the relay device to exhaust its buffer.

[0010] Determine if a shared cache is established with the relay device, and determine priority-based flow control (PFC) cache parameters based on the relay time and the time required for the relay device to exhaust its cache.

[0011] According to another embodiment of this application, a cross-device caching processing method is provided, executed by a relay device, comprising:

[0012] The device receives a probe request message sent by a first device, adds a relay time to the probe request message, and then forwards it to a second device, wherein the relay time is the time when the probe request message is received.

[0013] The device receives a probe response message sent by the second device, adds the time required for the relay device to exhaust its cache to the probe response message, and then forwards it to the first device. The probe response message is used to instruct the first device to determine to share a cache with the relay device, and to determine priority-based flow control (PFC) cache parameters based on the relay time and the time required for the relay device to exhaust its cache.

[0014] According to yet another embodiment of this application, a network device is also provided, the network device including a receiver, a transmitter, and a processor, the network device being configured to perform the steps of any of the above method embodiments via at least one of the receiver, the transmitter, and the processor.

[0015] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0016] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0017] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0018] Through the above embodiments of this application, the first device sends a probe request message to the second device via a relay device. This probe request message includes a relay time, which is the time the relay device receives the probe request message. The first device receives a probe response message forwarded by the relay device from the second device. This probe response message includes the time required for the relay device to exhaust its cache. The device determines to share a cache with the relay device and determines priority-based flow control (PFC) cache parameters based on the relay time and the time required for the relay device to exhaust its cache. This addresses the packet loss problem caused by insufficient cache on a single device in long-distance interconnection scenarios in related technologies. By adding a distance measurement relay function to the cascaded device, the device carries the time of receiving the request message and the time required for the relay device to exhaust its cache in the relay message and notifies the first device. The first device and the relay device share a cache. This cache-sharing mechanism enhances the flexibility of data center interconnection and improves data transmission efficiency. Attached Figure Description

[0019] Figure 1 This is a diagram illustrating how to calculate the distance of long-distance links between devices based on timestamp information in related technologies. Figure 1 ;

[0020] Figure 2 This is a diagram illustrating how to calculate the distance of long-distance links between devices based on timestamp information in related technologies. Figure 2 ;

[0021] Figure 3 This is a hardware structure block diagram of a mobile terminal for a cross-device caching processing method according to an embodiment of this application;

[0022] Figure 4 This is a flowchart of a cross-device caching method according to an embodiment of this application. Figure 1 ;

[0023] Figure 5 This is a flowchart of a cross-device caching method according to an embodiment of this application. Figure 2 ;

[0024] Figure 6 This is a diagram of the 1588 message format in related technologies. Figure 1 ;

[0025] Figure 7 This is a diagram of the 1588 message format in related technologies. Figure 2 ;

[0026] Figure 8 This is a schematic diagram of the probe request message format according to an embodiment of this application;

[0027] Figure 9 This is a schematic diagram of the probe response message format according to an embodiment of this application;

[0028] Figure 10 This is a schematic diagram of the relay request message format according to an embodiment of this application;

[0029] Figure 11 This is a schematic diagram of the relay response message format according to an embodiment of this application;

[0030] Figure 12 This is a schematic diagram of shared cache between devices in long-distance interconnection networking according to an embodiment of this application. Figure 1 ;

[0031] Figure 13 This is a schematic diagram of shared cache between devices in long-distance interconnection networking according to an embodiment of this application. Figure 2 . Detailed Implementation

[0032] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0034] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 3 This is a hardware structure block diagram of a mobile terminal according to an embodiment of the cross-device caching processing method of this application. Figure 3 As shown, a mobile terminal may include one or more ( Figure 3 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 3The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0035] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the cross-device caching processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0036] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0037] This embodiment provides a cross-device caching method. Figure 4 This is a flowchart of a cross-device caching method according to an embodiment of this application. Figure 1 ,like Figure 4 As shown, the process, executed by the first device, includes the following steps:

[0038] Step S402: Send a probe request message to the second device through the relay device. The probe request message includes a relay time, which is the time when the relay device receives the probe request message.

[0039] Step S404: Receive a probe response message sent by the second device and forwarded by the relay device, wherein the probe response message contains the time required for the relay device to exhaust its buffer;

[0040] Step S406: Determine if a cache is shared with the relay device, and determine the PFC cache parameters based on the relay time and the time required for the relay device to exhaust its cache.

[0041] Through steps S402 to S406, the first device can effectively handle cross-device cache sharing issues, especially for lossless data transmission in long-distance data center interconnection networks. In this embodiment, a relay device sends a probe request message to the second device, which includes the relay time—the specific time the relay device receives the probe request message. Upon receiving the request message, the second device calculates the time required for the relay device to exhaust its cache and carries this crucial information in its returned probe response message. Upon receiving the response message, the first device can determine whether to share the cache with the relay device and calculate more accurate PFC cache parameters based on the relay time and the time required for the relay device to exhaust its cache. Through this series of operations, even with limited device cache capacity, the continuity and integrity of data during long-distance cross-device transmission can be ensured, avoiding packet loss due to cache bottlenecks. This intelligent cache sharing mechanism enhances the flexibility of data center interconnection, improves data transmission efficiency, and provides strong technical support for building larger-scale network architectures.

[0042] The first device (or second device) needs to calculate how much buffer space it should reserve to process packets received from the relay device based on the relay device's buffer processing capacity and the actual latency of the entire link. This ensures that packets are not dropped at the first device due to insufficient buffer space. This demonstrates the importance of the first device dynamically adjusting its own buffer parameters based on the buffer status of the upstream relay device in the buffer sharing mechanism. In this embodiment of the application, step S406 above, determining the priority-based flow control (PFC) cache parameters based on the relay time and the time required for the relay device to exhaust its cache, may include: obtaining the relay time, the interface sending time of the first device, the interface receiving time of the second device, the time required for the relay device to exhaust its cache, the interface receiving time of the relay device, the interface sending time of the second device, and the interface receiving time of the first device; determining the packet probe delay based on the relay time, the interface sending time of the first device, the interface receiving time of the second device, the interface sending time of the relay device, and the interface receiving time of the first device; determining the required local cache length based on the time required for the relay device to exhaust its cache and the packet probe delay; and determining the PFC cache parameters based on the required local cache length.

[0043] By adding a relay timestamp (to carry relay time) and a difference timestamp field (to carry the time required for the relay device to exhaust its cache) to the original fields of the 1588 message, devices can announce their respective cache capabilities, thereby achieving automatic cache sharing. In specific implementation, the first device sends a probe request message, which the relay device forwards to the second device upon receipt. The second device processes the message and sends the timestamp information back to the relay device via a probe response message. The relay device then converts the cache capacity supported by its local interface into a time difference value and records it in the relay message, finally sending it to the first device. The first device calculates the message probe latency based on the received multiple timestamps, combines this with the time required for the relay device's local cache to exhaust it, determines the required local cache length, and sets the PFC cache parameters accordingly. Through this process, even if each device only supports a 100KM cache capacity, long-distance, lossless interconnection over 200KM can be achieved through cache sharing, greatly improving network configuration flexibility and performance in cross-data center interconnection scenarios and providing technical support for users to build longer-distance networks.

[0044] Accurate measurement and application of these time parameters—relay time, first device's interface transmission time, second device's interface reception time, time required for the relay device to exhaust its buffer, and interface reception time of the relay device, the second device's interface transmission time, and the first device's interface reception time—are crucial for achieving buffer sharing. By calculating the packet probe delay, the actual link distance can be quantified. Next, the required local buffer length is determined based on the relay device's buffer exhaust time and the packet probe delay, ensuring no packet loss during data transmission. Finally, the PFC buffer parameters are adjusted according to the required local buffer length, enabling the device to fully utilize network resources and improve data transmission efficiency.

[0045] In an exemplary embodiment, the packet probe delay is determined based on the following formula, according to the relay time, the interface transmission time of the first device, the interface reception time of the second device, the interface reception time of the relay device, the interface transmission time of the second device, and the interface reception time of the first device: T=[(t6-t1)-(t5-t2)-(t4-t3)] / 2; where t2 is the relay time, t1 is the interface transmission time of the first device, t3 is the interface reception time of the second device, t5 is the interface reception time of the relay device, t4 is the interface transmission time of the second device, t6 is the interface reception time of the first device, and T is the packet probe delay.

[0046] By employing a precise time calculation mechanism, the packet probe delay is determined, enabling more accurate cache configuration. Specifically, based on the relay timestamp, the first device interface sending timestamp, the second device interface receiving timestamp, the relay device interface receiving timestamp, the second device interface sending timestamp, and the first device interface receiving timestamp, the packet probe delay T is calculated using the formula T=[(t6-t1)-(t5-t2)-(t4-t3)] / 2. This calculation method effectively measures the actual latency of packets traveling through the link by comparing different timestamps, ensuring the accuracy of cache parameter settings. It ensures accurate calculation of packet latency even in complex scenarios with multi-level device cache sharing, thereby enabling reasonable cache configuration, avoiding packet loss during long-distance interconnection, and improving network stability and efficiency.

[0047] In an exemplary embodiment, the required local buffer length is determined based on the following formula, considering the time required for the relay device to exhaust its buffer and the packet probe delay: L=2 10 8 (T-T'), where L is the required local cache length and T' is the time required for the relay device to exhaust its cache.

[0048] This calculation process ensures that the downstream device (i.e., the first device) can automatically adjust its local buffer length according to the actual buffering capacity of the relay device to compensate for the latency of incoming packets in long-distance links and avoid packet loss during transmission. By accurately measuring the round-trip latency of packets and combining it with the relay device's buffering parameters, the downstream device dynamically configures its buffer, achieving efficient utilization of buffer resources and cross-device sharing, enhancing the flexibility and stability of interconnection networking, and effectively solving the problem of insufficient buffering on a single device in long-distance interconnection scenarios. Of course, in other embodiments not shown, the parameters in the formula can be adjusted accordingly based on different physical distances and network requirements to adapt to a wider range of network interconnection scenarios.

[0049] In this embodiment, the Send Timestamp field in the probe request message is filled with the interface sending time t1 of the first device, the newly added Relay Send Timestamp field is filled with the relay time t2, and the Receive Timestamp field is filled with the interface receiving time t3 of the second device; the newly added GAP Timestamp field in the probe response message is filled with the time required for the relay device to exhaust its buffer, the Reply Send Timestamp field is filled with the interface sending time t4 of the second device, the newly added Relay Receive Timestamp field is filled with the interface receiving time t5 of the relay device, and the Reply Receive Timestamp field is filled with the interface receiving time t6 of the first device.

[0050] The probe request message is sent by the requesting device (i.e., the first device). The Send Timestamp field records the sending time t1 of the first device's interface (the requesting device), while the newly added Relay Send Timestamp field is filled with the relay device's interface sending time t2. When the receiving device receives the request message, it writes its own interface receiving time t3 into the Receive Timestamp field. The probe response message is designed to include additional time information: the GAP Timestamp field records the time difference required for the relay device's local cache to be consumed, serving as a quantitative indicator of cache capacity; the Reply Send Timestamp field records the receiving device's interface sending time t4, while the ReplyReceive Timestamp field captures the first device's interface receiving time t6. Additionally, the newly added Relay ReceiveTimestamp field stores the relay device's interface receiving time t5. This entire scheme accurately measures the distance between devices through a timestamp mechanism and converts the relay device's cache capacity into a time difference value, effectively announcing and sharing cache parameters between upstream and downstream devices, thus solving the long-distance interconnection networking problem caused by insufficient cache on a single device. This time difference-based cache sharing mechanism not only enhances the stability of remote communication between devices, but also enables efficient utilization of cache resources between devices, providing strong technical support for building a network with zero packet loss across data centers.

[0051] This application also provides a cross-device caching method. Figure 5 This is a flowchart of a cross-device caching method according to an embodiment of this application. Figure 2 ,like Figure 5As shown, this is performed by the relay device and includes:

[0052] Step S502: Receive the probe request message sent by the first device, add a relay time to the probe request message and forward it to the second device, where the relay time is the time when the probe request message is received.

[0053] Step S504: Receive the probe response message sent by the second device, add the time required for the relay device to exhaust its buffer to the probe response message and then forward it to the first device. The probe response message is used to instruct the first device to determine to share the buffer with the relay device and to determine the PFC buffer parameters based on the relay time and the time required for the relay device to exhaust its buffer.

[0054] Through steps S502 to S504, after receiving the probe request message sent by the first device, the relay device adds a relay time and forwards it to the second device. The relay time is the time when the probe request message was received. The relay device receives the probe response message returned by the second device. This probe response message contains the time required to exhaust the local cache, i.e., the GAP Timestamp. The relay device adds this time information to the probe response message and forwards it to the first device. The first device can determine the PFC cache parameters based on the relay time and the time required for the relay device to exhaust its cache, thereby enabling the first device and the relay device to share the cache. This solves the packet loss problem caused by insufficient cache of a single device in long-distance interconnection scenarios. This not only improves the flexibility of the network but also increases the utilization rate of cache resources, providing technical support for building a packet loss-free network for interconnecting intelligent computing centers. Especially when chip cache is limited, it can effectively utilize the cache resources of each device in the network and enhance the long-distance transmission capability of the network.

[0055] In an exemplary embodiment, the method further includes: configuring a first interface, issuing local PFC cache parameters of the first interface, wherein the local PFC cache parameters are recorded as the time required for the relay device to exhaust its cache; associating the first interface with a second interface, and sharing the cache with the first device corresponding to the second interface, wherein the first interface is used to detect a first distance link, the second interface is used to detect a second distance link, and the length of the first distance link is greater than the length of the second distance link; and enabling ranging relay capability on the first interface.

[0056] By configuring the first interface and distributing its local PFC cache parameters, the time required for the relay device to exhaust its cache is recorded, enabling the device to accurately assess its own buffer capacity. Associating the first interface with the second interface aims to implement a cache-sharing strategy with the first device corresponding to the second interface. The first interface is used to probe the first distance link, while the second interface is responsible for probing the relatively shorter second distance link. The length of the first distance link is designed to be greater than the length of the second distance link. Enabling ranging relay capability on the first interface allows for the transmission of timestamp information over long-distance links, thereby assessing the cache demand across the entire link and enabling dynamic allocation of cache resources. This series of operations not only overcomes the limitations of a single device's cache capacity but also automatically adjusts cache parameters across links of different physical distances, ensuring the continuity and efficiency of data transmission. Especially in long-distance cross-data center interconnection scenarios, it significantly enhances the flexibility of device networking and the ability to transmit data without packet loss.

[0057] In one exemplary embodiment, forwarding a probe request message to a second device after adding a relay time may include: setting a Relay bit in a probe request message received through a second interface and filling the newly added Relay Send Timestamp field in the probe request message with a relay time; forwarding the probe request message to a first interface; and forwarding the filled probe request message from the first interface to the second device.

[0058] After receiving a probe request message, relay device R2 sets the Relay bit and fills the newly added Relay Send Timestamp field on its short-range interface P2 (i.e., the second interface), records the relay time t2, and then forwards the probe request message to the long-range interface P1 (i.e., the first interface). At the P1 interface, the message is further processed and forwarded to the downstream device R1. This process effectively utilizes timestamp information to measure distance. By accurately calculating the round-trip time of the message, the physical distance between devices can be accurately assessed, and PFC buffer parameters can be configured accordingly to ensure packet loss-free data transmission performance in long-distance interconnection. In an embodiment not shown in the figure, when R2's P1 interface records and forwards the message, it simultaneously writes the locally supported buffering capacity into the GAP Timestamp field in the form of a time difference. This data is used by the requesting device R3 to calculate the local buffer configuration, thereby realizing automatic sharing and optimization of buffers among multiple devices. By dynamically adjusting the buffer allocation, this scheme significantly improves the reliability and efficiency of long-distance interconnection, providing a technical foundation for building a packet loss-free network environment across data centers.

[0059] In one exemplary embodiment, forwarding the probe response message to the first device after adding the time required for the relay device to exhaust its buffer may include: setting the Relay bit in the probe response message and writing the time required for the buffer to exhaust recorded on the first interface into the newly added time interval timestamp (GAP Timestamp) field of the probe response message; forwarding the probe response message to the second interface, and writing the interface reception time t5 of the relay device into the newly added relay reception timestamp (Relay Receive Timestamp) field of the probe response message on the second interface; and forwarding the filled probe response message from the second interface to the first device.

[0060] When cascaded devices perform long-distance interconnection, a mechanism for transmitting cache time differences is implemented by setting a Relay bit in the probe response message and writing the time required for the relay device to exhaust its cache, recorded on the first interface of the relay device, into the newly added time interval timestamp (GAP Timestamp) field. Subsequently, the message is forwarded from the first interface to the second interface, where the second interface of the relay device writes the received response time t5 into the Relay Receive Timestamp field, further filling the message. Finally, the filled probe response message is forwarded from the second interface to the requesting device, i.e., the first device, thus achieving cascaded sharing of cache parameters. This precise timestamp mechanism effectively solves the packet loss problem in long-distance interconnection caused by single-device cache bottlenecks, improving the stability and efficiency of cross-data center interconnection.

[0061] In an exemplary embodiment, the method further includes: the SendTimestamp field of the probe request message is filled with the interface sending time t1 of the first device, and the ReceiveTimestamp field is filled with the interface receiving time t3 of the second device; the ReplySendTimestamp field of the probe response message is filled with the interface sending time t4 of the second device, and the ReplyReceiveTimestamp field is filled with the interface receiving time t6 of the first device.

[0062] When interconnecting long-distance data centers, caching capabilities are shared among multiple devices by carrying timestamp information in 1588 messages. This addresses the problem of being unable to build long-distance, lossless interconnects due to single-device caching bottlenecks. Specifically, the Send Timestamp field of the probe request message is filled with the interface sending time t1 of device R3 (corresponding to the first device mentioned above), while the Receive Timestamp field is filled with the interface receiving time t3 of device R1 (corresponding to the second device mentioned above) after receiving the message. In the probe response message, the Reply Send Timestamp field records the interface sending time t4 of device R1, while the Reply Receive Timestamp field is filled with the interface receiving time t6 of device R3. This process combines timestamp information with distance calculation, enabling devices to dynamically adjust caching parameters, thereby maintaining data transmission continuity and lossless characteristics even at different physical intervals. By exchanging timestamps between cascaded devices, not only can the actual physical distance between devices be accurately measured, but the required buffer latency can also be calculated based on the device's buffering capacity and link distance. This enables automatic adjustment and sharing of buffer parameters, effectively enhancing the flexibility and stability of the network. Especially in long-distance interconnection scenarios, it can significantly improve the efficiency and reliability of data transmission and support packet loss-free transmission over longer links.

[0063] In one exemplary embodiment, the method further includes: obtaining PFC cache parameters of the first device; receiving PFC messages sent by the first device; and stopping the transmission of message traffic to the first device after a length cache delay corresponding to the PFC cache parameters of the first device.

[0064] When the PFC buffer of the first device (downstream device) reaches its capacity limit, it sends a PFC message to the upstream device, instructing the upstream device to stop sending packets of a specific priority. Upon receiving the PFC message, the upstream device reserves a corresponding amount of time in its local buffer (i.e., the length buffer delay, determined by the PFC buffer parameters of device R3) to ensure that these packets are not dropped when the first device's buffer is full. Through the PFC mechanism, the upstream device can more intelligently control packet traffic, avoiding blindly sending packets when the link is congested, thereby reducing the processing pressure on the first device and improving network stability and efficiency.

[0065] In long-distance, cross-data center interconnection scenarios, cascaded devices need to interact with each other to announce the caching capabilities of upstream and downstream devices in order to achieve the goal of setting up PFC (Programmable Cache Control) for shared cache. This application's embodiment updates the specifications of the original ranging message by adding relay timestamps and differential timestamps. Key devices calculate the PFC cache parameters they need to set locally based on these timestamps, thereby achieving PFC cache announcement and realizing the goal of cross-device cache sharing.

[0066] In related technologies, the 1588 message supports both Ethernet encapsulation and IP encapsulation; the outer layer of the 1588 Ethernet encapsulation is identified by the Type value 0x88F7. Figure 6 This is a diagram of the 1588 message format in related technologies. Figure 1 ,like Figure 6 As shown, it includes: 6 bytes Dst MAC, 6 bytes Src MAC, 2 bytes Type (0x88F7), 44-64 bytes 1588 payload, and 4 bytes FCS.

[0067] IP encapsulation uses UDP port number 319 to identify 1588 packets, and supports both IPv4 and IPv6 packet encapsulation. Figure 7 This is a diagram of the 1588 message format in related technologies. Figure 2 ,like Figure 7 As shown, it includes: 6 bytes Dst MAC, 6 bytes SrcMAC, 2 bytes Type (0x88F7), IP, 8 bytes UDP (Dpor=319), 44-64 bytes 1588 payload, and 4 bytes FCS.

[0068] Regarding the definition of the 1588 Payload field, in this embodiment of the application, the field definitions of the probe request message and probe response message remain unchanged from the original preceding probe request message. Figure 8 This is a schematic diagram of the probe request message format according to an embodiment of this application, such as... Figure 8 As shown, it includes:

[0069] TranSpec: Indicates transmission related information, occupying 4 bits, 0 indicates a 1588 message.

[0070] MsgType: Indicates the message type, occupying 4 bits. 0x04 indicates a probe request message.

[0071] Reserved: Reserved field, occupying 4 bits.

[0072] VerPTP: Indicates the version of the 1588 protocol, occupying 4 bits. 0x02 indicates a 1588v2 message.

[0073] MsgLength: Indicates the message length, occupying 16 bits.

[0074] SeqenceID: Represents the message sequence number, occupying 8 bits.

[0075] Send Timestamp: Represents the timestamp sent by the requesting device's interface, occupying 64 bits.

[0076] Receive Timestamp: Represents the timestamp received by the receiving device's interface, occupying 64 bits.

[0077] Figure 9 This is a schematic diagram of the probe response message format according to an embodiment of this application, such as... Figure 9 As shown, it includes:

[0078] TranSpec: Indicates transmission related information, occupying 4 bits, 0 indicates a 1588 message.

[0079] MsgType: Indicates the message type, occupying 4 bits. 0x05 indicates a probe response message.

[0080] Reserved: Reserved field, occupying 4 bits.

[0081] VerPTP: Indicates the version of the 1588 protocol, occupying 4 bits. 0x02 indicates a 1588v2 message.

[0082] MsgLength: Indicates the message length, occupying 16 bits.

[0083] SeqenceID: Represents the message sequence number, occupying 8 bits.

[0084] Send Timestamp: Represents the timestamp sent by the requesting device's interface, occupying 64 bits.

[0085] Receive Timestamp: Represents the timestamp received by the receiving device's interface, occupying 64 bits.

[0086] Reply Send Timestamp: Represents the timestamp sent by the receiving device's interface, occupying 64 bits.

[0087] Reply Receive Timestamp: Represents the timestamp of the interface received by the requesting device, occupying 64 bits.

[0088] This application extends the original message function by using the high 4 bits of the Reserved flag after SeqenceID as a relay bit. This means that the relay device forwards the received probe request message, which is called a relay request message. Figure 10 This is a schematic diagram of the relay request message format according to an embodiment of this application, such as... Figure 10 As shown, it includes:

[0089] TranSpec: Indicates transmission related information, occupying 4 bits, 0 indicates a 1588 message.

[0090] MsgType: Indicates the message type, occupying 4 bits. 0x04 indicates a probe request message.

[0091] Reserved: Reserved field, occupying 4 bits.

[0092] VerPTP: Indicates the version of the 1588 protocol, occupying 4 bits. 0x02 indicates a 1588v2 message.

[0093] MsgLength: Indicates the message length, occupying 16 bits.

[0094] SeqenceID: Represents the message sequence number, occupying 8 bits.

[0095] Relay: Represents a relay message, occupies 4 bits, and has a value of 0x01.

[0096] Send Timestamp: Represents the timestamp sent by the requesting device's interface, occupying 64 bits.

[0097] Receive Timestamp: Represents the timestamp received by the receiving device's interface, occupying 64 bits.

[0098] Relay Send Timestamp: This represents the relay sending timestamp, which refers to the timestamp sent by the relay device's interface, occupying 64 bits.

[0099] The 1588 payload content is a custom field defined in this application. The fields and contents defined in the examples of this application are the best definition suggestions. Other definitions of the field, other attributes, or other definitions of the length are within the protection scope of this application.

[0100] The response message is modified to include a new type of relay response message. This relay message is used by relay devices to relay received probe response messages. Figure 11 This is a schematic diagram of the relay response message format according to an embodiment of this application, such as... Figure 11 As shown, it includes:

[0101] TranSpec: Indicates transmission related information, occupying 4 bits, 0 indicates a 1588 message.

[0102] MsgType: Indicates the message type, occupying 4 bits. 0x05 indicates a probe response message.

[0103] Reserved: Reserved field, occupying 4 bits.

[0104] VerPTP: Indicates the version of the 1588 protocol, occupying 4 bits. 0x02 indicates a 1588v2 message.

[0105] MsgLength: Indicates the message length, occupying 16 bits.

[0106] SeqenceID: Represents the message sequence number, occupying 8 bits.

[0107] Relay: Represents a relay message, occupies 4 bits, and has a value of 0x01.

[0108] Send Timestamp: Represents the timestamp sent by the requesting device's interface, occupying 64 bits.

[0109] Receive Timestamp: Represents the timestamp received by the receiving device's interface, occupying 64 bits.

[0110] Reply Send Timestamp: Represents the timestamp sent by the receiving device's interface, occupying 64 bits.

[0111] Reply Receive Timestamp: Represents the timestamp of the interface received by the requesting device, occupying 64 bits.

[0112] Relay Send Timestamp: This represents the relay sending timestamp, which refers to the timestamp sent by the relay device's interface, occupying 64 bits.

[0113] Relay Receive Timestamp: This indicates the relay receive timestamp, which refers to the interface receive timestamp of the relay device and occupies 64 bits.

[0114] GAP Timestamp: Represents a time interval timestamp used to measure the time required for a relay device to exhaust its buffer, occupying 64 seconds.

[0115] The 1588 payload content is a custom field in this application embodiment. The defined field and content are the best definition suggestions for both. Other defined positions, other attributes, or other defined distance lengths (such as delay, length value, etc.) are within the protection scope of this application embodiment.

[0116] 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. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0117] This embodiment also provides a cross-device caching processing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated. The apparatus includes:

[0118] The sending module is used to send a probe request message to the second device through the relay device. The probe request message includes a relay time, which is the time when the relay device receives the probe request message.

[0119] The first receiving module is used to receive the probe response message sent by the second device and forwarded by the relay device. The probe response message contains the time required for the relay device to exhaust its buffer.

[0120] The determination module is used to determine the shared cache with the relay device and to determine the PFC cache parameters based on the relay time and the time required for the relay device to exhaust its cache.

[0121] This application embodiment also provides a cross-device cache processing apparatus, the apparatus comprising:

[0122] The first forwarding module is used to receive the probe request message sent by the first device, add a relay time to the probe request message and forward it to the second device, wherein the relay time is the time when the probe request message is received.

[0123] The second forwarding module is used to receive the probe response message sent by the second device, add the time required for the relay device to exhaust its buffer in the probe response message, and then forward it to the first device. The probe response message is used to instruct the first device to determine to share the buffer with the relay device, and to determine the PFC buffer parameters based on the relay time and the time required for the relay device to exhaust its buffer.

[0124] In the embodiments of this application, the above-mentioned device may also include different modules, and the naming and functional division of the modules may be selected in different ways according to the actual situation, without specific restrictions.

[0125] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0126] 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 method embodiments when run.

[0127] 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 USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0128] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0129] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0131] In one exemplary embodiment, the computer program product described above includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the methods described in various embodiments of this application.

[0132] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0133] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular hardware and software combination.

[0134] To enable those skilled in the art to better understand the technical solution of this application, the following example illustrates the networking of three devices to build a long-distance interconnection network across data centers.

[0135] The networking environment is such that the distance between receiving device R1 and relay device R2 is 100KM, and the physical distance between relay device R2 and requesting device R3 is 50M and they are both devices in the same data center. Figure 12 This is a schematic diagram of shared cache between devices in long-distance interconnection networking according to an embodiment of this application. Figure 1 ,like Figure 12 As shown, device R1 has a cache capability supporting a distance of 200km, while devices R2 and R3 each have a cache capability supporting 100km. After sharing a cache, they can support a distance of 200km. In the process of probing the distance to achieve shared cache, R1 is the receiving device, R2 is the relay device, and R3 is the requesting device. The specific cache sharing workflow is as follows:

[0136] 1) The relay equipment configuration includes:

[0137] 1. R2, as a relay device, first configures the local long-distance interface P1. After the P1 interface detects that the long-distance link length is 200KM, it sends out PFC cache parameters. Due to insufficient local cache capacity, the upper limit is set to 100KM based on the device's capacity.

[0138] 2. The P1 interface locally sends out the configured cache parameters. These parameters are recorded in terms of duration and are used to fill the GAP Timestamp field in subsequent relay messages. They are denoted as Δt and represent the time required for the relay device to exhaust its cache.

[0139] 3. Associate the long-distance interface P1 with the short-distance interface P2, indicating that the peer device P2 supports cache sharing.

[0140] 4. Enable ranging relay capability on P2 interface. After receiving the ranging message 1588 on P2 interface, it will no longer process it locally, but will instead transmit it to the remote end via P1 interface.

[0141] Request the device to calculate the distance and configure caching. Figure 13 This is a schematic diagram of shared cache between devices in long-distance interconnection networking according to an embodiment of this application. Figure 2 ,like Figure 13 As shown, R3, acting as the requesting device, requires R2 as a relay when performing long-distance link ranging. After obtaining several time intervals, it sends out local cache configuration based on Δt recorded by R2's long-distance port P1. Its workflow includes:

[0142] 1. R3, as the requesting device, sends a distance detection request message. The Send Timestamp field of the message is the timestamp of interface P1 (denoted as t1), and other fields are filled according to the standard protocol content.

[0143] 2. After receiving the distance probe message, the P2 interface of R2 triggers the relay function, sets the Relay position in the probe message, writes the timestamp of the P2 interface into the Relay Send Timestamp field (denoted as t2), and modifies MsgLength. After the message is filled, it forwards the message from the P1 interface to the R1 device.

[0144] 3. R1, acting as the receiving device, receives the distance probe message on the P1 interface and writes the P1 interface timestamp into the Receive Timestamp field (denoted as t3). After chip processing, the message is transmitted back from the P1 interface, the message MsgType is modified to 0x05, a Reply Send Timestamp field is added, and the P1 interface timestamp is written (denoted as t4). At the same time, the Reply Receive Timestamp, Relay Receive Timestamp, and GAP Timestamp fields are added according to the protocol standard (the contents of the three fields are set to empty), and the MsgLength is modified. After the message is filled, the message is forwarded from the P1 interface to the R2 device.

[0145] 4. After receiving the returned probe message, the P1 interface of R2 writes the Δt recorded on the interface into the GAP Timestamp field; and forwards the message to the P2 interface inside the device. The P2 interface writes the local timestamp into the Relay ReceiveTimestamp field (denoted as t5); after the message is filled, it forwards the message from the P1 interface to the R3 device.

[0146] 5. After receiving the returned probe message on the P1 interface of device R3, it writes the local timestamp into the Reply ReceiveTimestamp field (denoted as t6). The forwarding chip processes the message and sends it to the CPU. The control plane of device R3 calculates the configuration required by the device based on several timestamps. The method is as follows: Message probe delay T = [(t6-t1)-(t5-t2)-(t4-t3)] / 2 (unit: ns); The buffer time supported by the upper-level device T' = Δt (unit: ns); The distance buffer L that needs to be calculated locally = 2. 10 8 (T-T') (unit: m). The R3 device configures the PFC buffer parameters of the P1 interface based on the final obtained length distance L.

[0147] 6. Subsequently, after processing by the upper-layer control software, R2's P2 interface will determine the corresponding buffer capacity of R3's P1 interface. Upon receiving the PFC message from R3, it will then process the corresponding L=2... 10 8 After a (T-T') length buffer delay, packet traffic is stopped, thereby achieving the goal of sharing local long-range port flight packets using the surplus buffer of R3.

[0148] Through the above process, R2 and R3, which each only support a 100KM length caching capability, achieved a 200KM length of packet loss-free interconnection by sharing the cache.

[0149] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A cross-device cache handling method, characterized by, The method is performed by a first device, comprising: sending a probe request packet to a second device through a relay device, wherein a relay time is added in the probe request packet, and the relay time is a time when the relay device receives the probe request packet; receiving a probe response packet sent by the second device and forwarded by the relay device, wherein a time required for the relay device to exhaust a cache is added in the probe response packet; determining a priority-based flow control (PFC) cache parameter based on a shared cache with the relay device and the relay time and the time required for the relay device to exhaust the cache.

2. The method of claim 1, wherein, The method further comprises: obtaining the relay time, an interface sending time of the first device, an interface receiving time of the second device, the time required for the relay device to exhaust the cache, an interface receiving time of the relay device, an interface sending time of the second device, and an interface receiving time of the first device; determining a packet probe delay based on the relay time, the interface sending time of the first device, the interface receiving time of the second device, the interface receiving time of the relay device, the interface sending time of the second device, and the interface receiving time of the first device; determining a local required cache length based on the time required for the relay device to exhaust the cache and the packet probe delay; determining the PFC cache parameter based on the local required cache length.

3. The method of claim 2, wherein, The method further comprises: determining the packet probe delay based on the relay time, the interface sending time of the first device, the interface receiving time of the second device, the interface receiving time of the relay device, the interface sending time of the second device, and the interface receiving time of the first device according to the following formula: T = [(t6-t1)-(t5-t2)-(t4-t3)] / 2; wherein t2 is the relay time, t1 is the interface sending time of the first device, t3 is the interface receiving time of the second device, t5 is the interface receiving time of the relay device, t4 is the interface sending time of the second device, t6 is the interface receiving time of the first device, and T is the packet probe delay.

4. The method of claim 3, wherein, The method further comprises: determining the local required cache length based on the time required for the relay device to exhaust the cache and the packet probe delay according to the following formula: L = 2 10 8 (T-T'), L is the local required cache length, T' is the time required for the relay device to exhaust the cache.

5. The method of any one of claims 1 to 4, wherein: a Send Timestamp field in the probe request packet is filled with the interface sending time of the first device, a newly added Relay Send Timestamp field is filled with the relay time, and a Receive Timestamp field is filled with the interface receiving time of the second device. The newly added time interval timestamp GAP Timestamp field of the probe response message is filled with the time required for the relay device to exhaust the cache, the relay sending timestamp Reply Send Timestamp field is filled with the interface sending time of the second device, the newly added relay receiving timestamp Relay Receive Timestamp field is filled with the interface receiving time of the relay device, and the relay receiving timestamp Reply Receive Timestamp field is filled with the interface receiving time of the first device.

6. A cross-device cache processing method, characterized by, The method is performed by a relay device and includes: receiving a probe request message sent by a first device, and forwarding the probe request message to a second device after adding a relay time in the probe request message, wherein the relay time is a time at which the probe request message is received; receiving a probe response message sent by the second device, and forwarding the probe response message to the first device after adding a time required for the relay device to exhaust the cache in the probe response message, wherein the probe response message is used to instruct the first device to determine to share the cache with the relay device, and to determine a priority-based flow control (PFC) cache parameter based on the relay time and the time required for the relay device to exhaust the cache.

7. The method of claim 6, wherein, The method further includes: configuring a first interface, and issuing a local PFC cache parameter of the first interface, wherein the local PFC cache parameter records the time required for the relay device to exhaust the cache; associating the first interface with a second interface, and sharing the cache with the first device corresponding to the second interface, wherein the first interface is used to probe a first distance link, the second interface is used to probe a second distance link, the length of the first distance link is greater than the length of the second distance link, and the first interface is enabled to start a ranging relay capability. adding the relay time in the probe request message and forwarding the probe request message to the second device includes:

8. The method of claim 7, wherein, setting a Relay bit in the probe request message received through the second interface, and filling a newly added relay sending timestamp Relay Send Timestamp field in the probe request message with the relay time; forwarding the probe request message to the first interface; forwarding the probe request message after the filling is completed from the first interface to the second device. adding the time required for the relay device to exhaust the cache in the probe response message and forwarding the probe response message to the first device includes:

9. The method of claim 8, wherein, setting a Relay bit in the probe response message, and writing the time required for the relay device to exhaust the cache recorded on the first interface into a newly added time interval timestamp GAP Timestamp field in the probe response message; forwarding the probe response message to the second interface, and writing an interface receiving time of the relay device into a newly added relay receiving timestamp Relay Receive Timestamp field in the probe response message on the second interface; forwarding the probe response message after the filling is completed from the second interface to the first device. ​ 10. The method of claim 9, wherein, The method further comprises: a Send Timestamp field of the probe request message is filled with an interface sending time of the first device, and a Receive Timestamp field is filled with an interface receiving time of the second device; a Reply Send Timestamp field of the probe response message is filled with an interface sending time of the second device, and a Reply Receive Timestamp field is filled with an interface receiving time of the first device.

11. The method according to any one of claims 7 to 10, characterized in that, The method further comprises: obtaining a PFC buffer parameter of the first device; receiving a PFC message sent by the first device; stopping sending a message flow to the first device after a length buffer delay corresponding to the PFC buffer parameter of the first device. 12.An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 5, or to implement the steps of the method in any one of claims 6 to 11.

13. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 5, or to implement the steps of the method in any one of claims 6 to 11.

Images