Credit updating method, apparatus, device, system, and storage medium

Abstract

The present application relates to the technical field of communications, and discloses a credit updating method, an apparatus, a device, a system, and a storage medium. For example, when a first apparatus performs the method, the first apparatus determines a first credit limit of the first apparatus, wherein the first credit limit indicates a limit, updated by the first apparatus, on the amount of data allowed to be received; and the first apparatus sends first instruction information to a second apparatus, wherein the first instruction information instructs the second apparatus to update a credit limit of the second apparatus according to the first credit limit. The method provides a means for updating a credit limit, such that the configuration of the credit limit can be dynamically adjusted on the basis of a change in the limit on the amount of data that a first apparatus allows to receive. Moreover, during implementation of update of the credit limit, the method does not require interruption of a data stream between the first apparatus and a second apparatus, thereby avoiding the effect of the update of the credit limit on the transmission of the data stream.

Description

Credit updating method, device, equipment, system and storage medium

[0001] The present application claims priority from the Chinese patent application No. 202411392356.4 filed on September 30, 2024 and entitled "Credit updating method, device, equipment, system and storage medium", the whole content of which is incorporated herein by reference. TECHNICAL FIELD

[0002] The present application relates to the field of communication technology, in particular to a credit updating method, device, equipment, system and storage medium. BACKGROUND

[0003] In the field of communication technology, credit based flow control (CBFC) technology is a commonly used flow control technology on a network or a bus, and the CBFC can also be referred to as authorization based flow control. The CBFC includes an initialization configuration phase and a data transmission phase. The initialization configuration phase is used to configure a credit limit according to a constraint of an allowed data amount of a receiving end. The data transmission phase is used to control the transmission of data according to the configured credit limit, so that the amount of transmitted data does not exceed the allowed data amount of the receiving end.

[0004] In this scenario, if the constraint of the allowed data amount of the receiving end changes, how to update the already configured credit limit is a problem to be solved urgently. SUMMARY

[0005] The present application provides a credit updating method, device, equipment, system and storage medium, which are used to update a credit limit.

[0006] In a first aspect, a credit updating method is provided. Taking an example of a first device executing the method, the method includes: determining, by the first device, a first credit limit of the first device, the first credit limit indicating a constraint of an allowed data amount of the first device to be updated; and sending, by the first device, first indication information to a second device, the first indication information indicating that the second device updates a credit limit of the second device according to the first credit limit.

[0007] Optionally, the constraint of the allowed data amount of the first device to be updated can be an upper limit value of the allowed data amount of the first device to be updated.

[0008] In the method, the first device can instruct the second device to update the credit constraint by sending the first indication information to the second device. Thus, a means for updating the credit constraint is provided, so that the configuration of the credit constraint can be dynamically adjusted according to the change of the constraint on the amount of data allowed to be received by the first device. Moreover, the method can update the credit constraint without interrupting the data flow between the first device and the second device, so as to avoid the influence of the updating of the credit constraint on the transmission of the data flow.

[0009] In a possible implementation, the first credit constraint comprises a total credit constraint of a plurality of first virtual queues on the first device, and the total credit constraint of the plurality of first virtual queues indicates a constraint on the amount of data allowed to be updated by the plurality of first virtual queues; and the first indication information instructs the second device to update a total credit constraint of a plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues, and the plurality of first virtual queues correspond to the plurality of second virtual queues. Thus, the total credit constraint of the plurality of virtual queues can be dynamically adjusted, and the total credit constraint refers to a credit constraint allocated to the plurality of virtual queues as a whole by the first device, and the plurality of first virtual queues share the total credit constraint.

[0010] In a possible implementation, the first credit constraint comprises a credit constraint corresponding to a first virtual queue on the first device, and the credit constraint corresponding to the first virtual queue indicates a constraint on the amount of data allowed to be updated by the first virtual queue; and the first indication information instructs the second device to update a credit constraint corresponding to a second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue, and the first virtual queue corresponds to the second virtual queue. Thus, the credit constraint corresponding to each virtual queue can be dynamically adjusted, and the credit constraint corresponding to each virtual queue refers to a corresponding credit constraint allocated to each virtual queue in the plurality of virtual queues by the first device respectively, and the credit constraint of any virtual queue is exclusively used by the virtual queue.

[0011] In a possible implementation, in the case where the first credit constraint comprises a total credit constraint of a plurality of first virtual queues on the first device, the first indication information further instructs the credit constraint of the second device to be switched from the credit constraint corresponding to a second virtual queue on the second device to the total credit constraint of a plurality of second virtual queues on the second device.

[0012] In a possible implementation, in the case where the first credit constraint comprises a credit constraint corresponding to a first virtual queue on the first device, the first indication information further instructs the credit constraint of the second device to be switched from the total credit constraint of a plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue on the second device.

[0013] Thus, the switching of the credit configuration mode is also realized by the sending of the first indication information, that is, the switching of the credit configuration mode and the updating of the credit constraint are simultaneously realized by one indication information, so that the utilization rate of the indication information is higher. The credit configuration mode refers to a mode in which a single virtual queue is configured with an exclusive credit constraint, and a mode in which multiple virtual queues are configured with a shared overall credit constraint. For the second device, the switching of the credit configuration mode includes switching of the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the multiple second virtual queues, and switching of the overall credit constraint of the multiple second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0014] In a possible implementation, in a case where the first credit constraint includes the overall credit constraint of the multiple first virtual queues on the first device, the first device further sends, to the second device, second indication information, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the multiple second virtual queues.

[0015] In a possible implementation, in a case where the first credit constraint includes the credit constraint corresponding to the first virtual queue on the first device, the first device further sends, to the second device, third indication information, the third indication information indicating that the credit constraint of the second device is switched from the overall credit constraint of the multiple second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0016] Thus, the switching of the credit configuration mode is realized by the additional sending of the second indication information or the third indication information, that is, the first indication information and the second indication information are respectively used to realize the updating of the credit constraint and the switching of the credit configuration mode, or the first indication information and the third indication information are respectively used to realize the updating of the credit constraint and the switching of the credit configuration mode, so that the sending of the indication information is more flexible.

[0017] In a possible implementation, in a case where the first credit constraint includes the credit constraint corresponding to the first virtual queue on the first device, the first credit constraint further includes the overall credit constraint of the multiple first virtual queues on the first device, the overall credit constraint of the multiple first virtual queues indicating a constraint on an allowed receiving data amount of the multiple first virtual queues; and the first indication information further indicates that the second device updates the overall credit constraint of the multiple second virtual queues on the second device according to the overall credit constraint of the multiple first virtual queues, the multiple first virtual queues corresponding to the multiple second virtual queues. Thus, the overall credit constraint of the multiple virtual queues and the credit constraint corresponding to each virtual queue can be simultaneously dynamically adjusted.

[0018] In a possible implementation, in a case where the first indication information indicates that the second device updates the overall credit constraint of the plurality of second virtual queues on the second device according to the overall credit constraint of the plurality of first virtual queues, the first device further sends the overall credit constraint of the plurality of first virtual queues to the second device. This enables the second device to quickly obtain at least one of the overall credit constraint of the plurality of first virtual queues or the credit constraint corresponding to the first virtual queue, thereby improving the updating efficiency of the credit constraint.

[0019] In a possible implementation, in a case where the first indication information indicates that the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue, the first device further sends the credit constraint corresponding to the first virtual queue to the second device. This enables the second device to quickly obtain the credit constraint corresponding to the first virtual queue, thereby improving the updating efficiency of the credit constraint.

[0020] In a possible implementation, the first device further receives a response to the credit configuration mode switching sent by the second device. In this way, by sending the response to the credit configuration mode switching, the first device can determine that the second device has completed the switching of the credit configuration mode.

[0021] In a possible implementation, before receiving the response to the credit configuration mode switching sent by the second device, the first device switches the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues; or after receiving the response to the credit configuration mode switching sent by the second device, the first device switches the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues.

[0022] In a possible implementation, before receiving the response to the credit mode switching sent by the second device, the first device switches the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues; or after receiving the response to the credit mode switching sent by the second device, the first device switches the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues.

[0023] In a possible implementation, before receiving the response to the credit mode switching sent by the second device, the first device switches the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device; or after receiving the response to the credit mode switching sent by the second device, the first device switches the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device.

[0024] Thus, two manners of switching the credit configuration mode of the first device are provided, so that the switching operation of the credit configuration mode of the first device is more flexible, and the switching operation after receiving the response can better ensure lossless transmission.

[0025] In a possible implementation, the first device further receives a response to the credit constraint update sent by the second device. The response to the credit constraint update can be a response of the second device to the first indication information, and the response to the credit constraint update indicates that the second device completes the update of the second credit constraint. Thus, by sending the response to the credit constraint update, the first device can determine that the second device has completed the update of the credit constraint.

[0026] In a possible implementation, the first device receives data according to the buffer space corresponding to the first credit constraint before receiving the response to the credit constraint update sent by the second device, or the first device receives data according to the buffer space corresponding to the first credit constraint after receiving the response to the credit constraint update sent by the second device. Thus, the first device can perform the update operation of the credit constraint more flexibly, and the operation after receiving the response can better ensure lossless transmission.

[0027] Optionally, in the case where the update operation is to increase the first credit constraint, the first device completes the update of the first credit constraint before receiving the response to the credit constraint update sent by the second device. Thus, the first device can complete the update of the first credit constraint in advance, and the update efficiency of the first device is improved. In the case where the update operation is to decrease the first credit constraint, the first device performs the update of the first credit constraint after receiving the response to the credit constraint update sent by the second device. The data loss caused by the first device decreasing the first credit constraint in advance is reduced, and lossless transmission of data can be better ensured.

[0028] In a possible implementation, the first device sends the first indication information to the second device, including: the first device sends a link layer discovery protocol (LLDP) packet to the second device, and the LLDP packet carries the first indication information; or the first device sends an ordered set (O) code to the second device, and the O code carries the first indication information. Two simple and easy-to-implement manners of sending the first indication information are provided, and the flexibility of the sending manner of the first indication information is improved.

[0029] In a second aspect, a credit updating method is provided. For example, the method is performed by a second device, and includes: receiving, by the second device, first indication information sent by a first device, the first indication information indicating that the second device updates a credit constraint of the second device according to a first credit constraint, the first credit constraint indicating a constraint of an updated allowed receiving data amount of the first device; and updating, by the second device, a second credit constraint of the second device according to the first indication information and the first credit constraint, the second credit constraint indicating a constraint of an updated allowed sending data amount of the second device.

[0030] Optionally, the constraint of the updated allowed sending data amount of the second device can be an upper limit value of the updated allowed sending data amount of the second device.

[0031] In the method, the second device updates the second credit constraint by receiving the first indication information sent by the first device. Thus, a means for updating the credit constraint is provided, so that the configuration of the credit constraint can be dynamically adjusted according to the change of the constraint of the updated allowed receiving data amount of the first device. Moreover, the method does not interrupt the data flow between the first device and the second device in the process of updating the credit constraint, so as to avoid the influence of the updating of the credit constraint on the transmission of the data flow.

[0032] In a possible implementation, the first indication information indicates that the second device updates a total credit constraint of a plurality of second virtual queues on the second device according to a total credit constraint of a plurality of first virtual queues on the first device, the plurality of second virtual queues corresponding to the plurality of first virtual queues; and the updating, by the second device, of the second credit constraint of the second device according to the first indication information includes: updating, by the second device, the total credit constraint of the plurality of second virtual queues on the second device according to the first indication information and the total credit constraint of the plurality of first virtual queues, the total credit constraint of the plurality of second virtual queues indicating a constraint of an updated allowed sending data amount of the plurality of second virtual queues.

[0033] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to a total credit constraint of a plurality of second virtual queues; and the method further includes: switching, by the second device, the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues according to the first indication information.

[0034] In a possible implementation, the method further includes: receiving, by the second device, second indication information sent by the second device, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues; and switching, by the second device according to the second indication information, the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues.

[0035] In a possible implementation, the method further includes: updating, by the second device according to the updated overall credit constraint of the plurality of second virtual queues, the credit constraint of any second virtual queue in the plurality of second virtual queues, the credit constraint of the any second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the any second virtual queue.

[0036] In a possible implementation, the first indication information indicates that the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue on the first device, the first virtual queue corresponding to the second virtual queue; and the updating, by the second device according to the first indication information, of the second credit constraint of the second device according to the first credit constraint includes: updating, by the second device according to the first indication information, the credit constraint corresponding to the second virtual queue according to the credit constraint corresponding to the first virtual queue, the credit constraint corresponding to the second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the second virtual queue.

[0037] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue, and the method further includes: switching, by the second device according to the first indication information, the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0038] In a possible implementation, the method further includes: receiving, by the second device, third indication information sent by the second device, the third indication information indicating that the credit constraint of the second device is switched from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue; and switching, by the second device according to the third indication information, the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0039] In a possible implementation, the first indication information further indicates that the second device updates the total credit constraint of the second plurality of virtual queues on the second device according to the total credit constraint of the first plurality of virtual queues on the first device, the first plurality of virtual queues corresponding to the second plurality of virtual queues; and the second device updates the second credit constraint of the second device according to the first indication information according to the first credit constraint, further includes that the second device updates the total credit constraint of the second plurality of virtual queues on the second device according to the first indication information according to the total credit constraint of the first plurality of virtual queues, and the total credit constraint of the second plurality of virtual queues indicates a constraint of an allowed sending data amount of the second plurality of virtual queues after the update.

[0040] In a possible implementation, before the total credit constraint of the second plurality of virtual queues on the second device is updated according to the total credit constraint of the first plurality of virtual queues, the method further includes that the second device receives the total credit constraint of the first plurality of virtual queues sent by the first device.

[0041] In a possible implementation, before the credit constraint corresponding to the second virtual queue is updated according to the credit constraint corresponding to the first virtual queue, the method further includes that the second device receives the credit constraint corresponding to the first virtual queue sent by the first device.

[0042] In a possible implementation, the method further includes that the second device sends a response of the credit configuration mode switching to the first device.

[0043] In a possible implementation, the method further includes that the second device sends a response of the credit constraint update to the first device.

[0044] In a possible implementation, the method further includes that the second device sends a data stream to the first device while updating the second credit constraint. In this way, the data stream is ensured not to be interrupted during the credit update process.

[0045] In any of the possible implementations of the above first aspect and second aspect, the first device and the second device are directly connected upstream and downstream devices, or are non-directly connected upstream and downstream devices, or are end point devices at two ends of a network. This makes the method applicable to a variety of scenarios.

[0046] In a third aspect, a credit update device is provided, which includes a transceiver module and a processing module. Optionally, the credit update device can be applied to the above first device or second device. The transceiver module can include a receiving module and / or a sending module. The receiving module is configured to perform operations related to receiving, and the sending module is configured to perform operations related to sending.

[0047] In a possible implementation, the processing module is configured to determine a first credit constraint of the first device, the first credit constraint indicating a constraint on an amount of data allowed to be received by the first device for updating; and the transceiver is configured to send, to the second device, first indication information indicating that the second device updates a credit constraint of the second device according to the first credit constraint.

[0048] In a possible implementation, the processing module is configured to determine a first credit constraint of the first device, the first credit constraint indicating a constraint on an amount of data allowed to be received by the first device for updating; and the transceiver is configured to send, to the second device, first indication information indicating that the second device updates a credit constraint of the second device according to the first credit constraint.

[0049] In a possible implementation, the first credit constraint includes a total credit constraint of a plurality of first virtual queues on the first device, the total credit constraint of the plurality of first virtual queues indicating a constraint on an amount of data allowed to be received by the plurality of first virtual queues for updating; and the first indication information indicates that the second device updates a total credit constraint of a plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues, the plurality of first virtual queues corresponding to the plurality of second virtual queues.

[0050] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues.

[0051] In a possible implementation, the transceiver is further configured to send, to the second device, second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues.

[0052] In a possible implementation, the first credit constraint includes a credit constraint corresponding to a first virtual queue on the first device, the credit constraint corresponding to the first virtual queue indicating a constraint on an amount of data allowed to be received by the first virtual queue for updating; and the first indication information indicates that the second device updates a credit constraint corresponding to a second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue, the first virtual queue corresponding to the second virtual queue.

[0053] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from a total credit constraint of a plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0054] In a possible implementation, the transceiving module is further configured to send third indication information to the second device, where the third indication information indicates that the credit constraint of the second device is switched from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0055] In a possible implementation, the first credit constraint further includes an overall credit constraint of a plurality of first virtual queues on the first device, where the overall credit constraint of the plurality of first virtual queues indicates a constraint on an updated amount of received data of the plurality of first virtual queues; and the first indication information further indicates that the second device updates the overall credit constraint of the plurality of second virtual queues on the second device according to the overall credit constraint of the plurality of first virtual queues, where the plurality of first virtual queues correspond to the plurality of second virtual queues.

[0056] In a possible implementation, the transceiving module is further configured to send the overall credit constraint of the plurality of first virtual queues to the second device.

[0057] In a possible implementation, the transceiving module is further configured to send the credit constraint corresponding to the first virtual queue to the second device.

[0058] In a possible implementation, the transceiving module is further configured to receive a response to the credit configuration mode switching sent by the second device.

[0059] In a possible implementation, the processing module is further configured to switch the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues before receiving the response to the credit mode switching sent by the second device, or switch the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues after receiving the response to the credit mode switching sent by the second device.

[0060] In a possible implementation, the processing module is further configured to switch the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device before receiving the response to the credit mode switching sent by the second device, or switch the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device after receiving the response to the credit mode switching sent by the second device.

[0061] In a possible implementation, the transceiving module is further configured to receive a response to the credit constraint updating sent by the second device.

[0062] In a possible implementation, the processing module is further configured to receive data according to the buffer space corresponding to the first credit constraint before receiving a response to the credit constraint update sent by the second device; or the processing module is further configured to receive data according to the buffer space corresponding to the first credit constraint after receiving the response to the credit constraint update sent by the second device.

[0063] In a possible implementation, the transceiver module is configured to send an LLDP packet to the second device, the LLDP packet carrying the first indication information; or the transceiver module is configured to send an O-code to the second device, the O-code carrying the first indication information.

[0064] In the case where the credit update device is applied to the second device, the transceiver module is configured to perform the receiving and / or sending operations performed in the second aspect or any possible implementation of the second aspect; and the processing module is configured to perform other operations in addition to the receiving and / or sending operations in the second aspect or any possible implementation of the second aspect.

[0065] In a possible implementation, the transceiver module is configured to receive first indication information sent by the first device, the first indication information indicating that the second device updates a credit constraint of the second device according to a first credit constraint, the first credit constraint indicating a constraint on an amount of data allowed to be received by the first device after the update; and the processing module is configured to update a second credit constraint of the second device according to the first credit constraint according to the first indication information, the second credit constraint indicating a constraint on an amount of data allowed to be sent by the second device after the update.

[0066] In a possible implementation, the first indication information indicates that the second device updates a total credit constraint of a plurality of second virtual queues on the second device according to a total credit constraint of a plurality of first virtual queues on the first device, the plurality of second virtual queues corresponding to the plurality of first virtual queues; and the processing module is configured to update the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues according to the first indication information, the total credit constraint of the plurality of second virtual queues indicating a constraint on an amount of data allowed to be sent by the plurality of second virtual queues after the update.

[0067] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues; and the processing module is further configured to switch the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues according to the first indication information.

[0068] In a possible implementation, the transceiving module is further configured to receive second indication information sent by the second device, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues; and the processing module is further configured to switch the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues according to the second indication information.

[0069] In a possible implementation, the processing module is further configured to update the credit constraint of any second virtual queue in the plurality of second virtual queues according to the updated overall credit constraint of the plurality of second virtual queues, the credit constraint of the any second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the any second virtual queue.

[0070] In a possible implementation, the first indication information indicates that the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue on the first device, the first virtual queue corresponding to the second virtual queue; and the processing module is configured to update the credit constraint corresponding to the second virtual queue according to the credit constraint corresponding to the first virtual queue according to the first indication information, the credit constraint corresponding to the second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the second virtual queue.

[0071] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue; and the processing module is further configured to switch the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue according to the first indication information.

[0072] In a possible implementation, the transceiving module is further configured to receive third indication information sent by the second device, the third indication information indicating that the credit constraint of the second device is switched from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue; and the processing module is further configured to switch the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue according to the third indication information.

[0073] In a possible implementation, the first indication information further indicates that the second device updates the total credit constraint of the second plurality of virtual queues on the second device according to the total credit constraint of the first plurality of virtual queues on the first device, the first plurality of virtual queues corresponding to the second plurality of virtual queues; and the processing module is further configured to update the total credit constraint of the second plurality of virtual queues on the second device according to the total credit constraint of the first plurality of virtual queues on the first device according to the first indication information, the total credit constraint of the second plurality of virtual queues indicating a constraint on an amount of data allowed to be sent by the second plurality of virtual queues after the update.

[0074] In a possible implementation, the transceiver module is further configured to receive the total credit constraint of the first plurality of virtual queues sent by the first device.

[0075] In a possible implementation, the transceiver module is further configured to receive the credit constraint corresponding to the first virtual queue sent by the first device.

[0076] In a possible implementation, the transceiver module is further configured to send, to the first device, a response to the switching of the credit configuration mode.

[0077] In a possible implementation, the transceiver module is further configured to send, to the first device, a response to the credit constraint update.

[0078] In a possible implementation, the transceiver module is further configured to send, to the first device, a data stream while updating the second credit constraint.

[0079] In a fourth aspect, a network device is provided, which includes a processor configured to load and execute at least one program instruction or code to enable the network device to implement the credit update method in any possible implementation of the first aspect or the second aspect.

[0080] In a possible implementation, the network device further includes a memory coupled to the processor, and the memory stores the at least one program instruction or code loaded and executed by the processor.

[0081] Optionally, the processor is one or more, and the memory is one or more.

[0082] Optionally, the memory can be integrated with the processor, or the memory and the processor are separately arranged.

[0083] In a specific implementation process, the memory can be a non-transitory memory, for example, a read only memory (ROM), which can be integrated on the same chip with the processor, or can be separately arranged on different chips. The type of the memory and the arrangement manner of the memory and the processor are not limited in the present application.

[0084] In a fifth aspect, a credit updating system is provided, which comprises a first device and a second device; the first device is configured to execute the credit updating method in the first aspect or any possible implementation manner of the first aspect, and the second device is configured to execute the credit updating method in the second aspect or any possible implementation manner of the second aspect.

[0085] In a sixth aspect, a computer readable storage medium is provided, which stores at least one instruction, the instruction is loaded and executed by a processor, so as to enable a computer to implement the credit updating method in the first aspect or any possible implementation manner of the first aspect, or implement the credit updating method in the second aspect or any possible implementation manner of the second aspect.

[0086] In a seventh aspect, a computer program (product) is provided, which comprises computer program code, when the computer program code is run by a computer, so as to enable the computer to execute the credit updating method in the above aspects.

[0087] In an eighth aspect, a chip is provided, which comprises a processor, configured to invoke and run instructions stored in a memory, so as to enable a communication device installed with the chip to execute the credit updating method in the above aspects.

[0088] In a ninth aspect, another chip is provided, which comprises an input interface, an output interface, a processor and a memory, the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is configured to execute code in the memory, when the code is executed, the processor is configured to execute the credit updating method in the above aspects.

[0089] It should be understood that the beneficial effects achieved by the second aspect to the ninth aspect and the corresponding possible implementation manners of the present application can refer to the technical effects of the first aspect and the corresponding possible implementation manners, which will not be repeated here. In addition, the credit updating device mentioned in the third aspect can be the network device mentioned in the fourth aspect, or the chip mentioned in the eighth aspect or the ninth aspect. BRIEF DESCRIPTION OF DRAWINGS

[0090] FIG. 1 is a schematic diagram of a CBFC transceiving process provided by an embodiment of the present application;

[0091] FIG. 2 is a schematic diagram of a flow of deleting a VC in a CBFC according to an embodiment of the present application;

[0092] FIG. 3 is a schematic diagram of a flow of adding a VC in a CBFC according to an embodiment of the present application;

[0093] FIG. 4 is a schematic diagram of an implementation environment of a credit updating method according to an embodiment of the present application;

[0094] FIG. 5 is a schematic diagram of a system architecture of a first device and a second device according to an embodiment of the present application;

[0095] FIG. 6 is a schematic diagram of an interaction of a credit updating method according to an embodiment of the present application;

[0096] FIG. 7 is a schematic diagram of a credit updating flow according to an embodiment of the present application;

[0097] FIG. 8 is a schematic diagram of a credit increasing flow according to an embodiment of the present application;

[0098] FIG. 9 is a schematic diagram of a credit decreasing flow according to an embodiment of the present application;

[0099] FIG. 10 is a schematic diagram of a credit switching flow according to an embodiment of the present application;

[0100] FIG. 11 is a schematic diagram of a structure of a credit updating device according to an embodiment of the present application;

[0101] FIG. 12 is a schematic diagram of a structure of a network device according to an embodiment of the present application;

[0102] FIG. 13 is a schematic diagram of a structure of a network device according to an embodiment of the present application. DETAILED DESCRIPTION

[0103] To make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0104] In a scenario of data transmission using CBFC technology, a receiving end configures a credit limit of a port according to a size of a buffer area used for receiving data, and sends the credit limit to a sending end. The sending end controls sending of data packets of the port based on the received credit limit, on one hand to ensure that the sent data packets will not cause overflow of the buffer area of the receiving end, i.e. to avoid loss of data packets, and to realize lossless network transmission, and on the other hand to improve throughput to ensure port utilization and data sending delay.

[0105] The CBFC can divide the port into multiple virtual channels (VCs), and the receiving end can configure a total credit limit for the multiple VCs, i.e., the multiple VCs share a buffer and the total credit limit; or configure a corresponding credit limit for each VC, i.e., each VC exclusively uses a corresponding buffer and credit limit. That is, the credit limit configuration includes two cases: one is that multiple VCs correspond to a total credit limit, i.e., a shared credit mode; and the other is that each VC corresponds to a corresponding credit limit, i.e., a per-VC credit limit.

[0106] In the case where multiple VCs share the total credit limit, the sum of the total used credits corresponding to the total amount of data already sent by the sending end through the multiple VCs and the credits corresponding to the amount of data to be sent through the multiple VCs (to-be-sent data credits) needs to be less than or equal to the total credit limit, i.e., total credit limit>total used credits+to-be-sent data credits. The sending end configures a corresponding credit limit (per-VC credit limit) for each VC in the multiple VCs according to the total used credits of the multiple VCs, i.e., the sending end locally configures a corresponding credit limit for each VC. Optionally, based on the total credit limit control of data sending, on the premise of ensuring that total credit limit>total used credits+to-be-sent data credits, the sum of the per-VC used credits corresponding to the amount of data already sent through any VC and the credits corresponding to the amount of data to be sent through the any VC (to-be-sent data credits) can also be less than or equal to the credit limit corresponding to the any VC as a judgment, i.e., per-VC credit limit>per-VC used credits+to-be-sent data credits.

[0107] In the case that each VC configuration corresponds to a credit limit, the sum of the per-VC used credits corresponding to the data amount sent by the sending end through any VC and the credit corresponding to the data amount to be sent through the any VC (to-be-sent data credit) needs to be less than or equal to the credit limit corresponding to the any VC (per-VC credit limit), that is, per-VC credit limit > per-VC used credits + to-be-sent data credit. Wherein, the to-be-sent message can be multiple, that is, multiple messages are queued and waiting to be sent, but each time of sending, the credit corresponding to the data amount of one message is taken to determine the to-be-sent data credit. That is, the data amount to be sent through the VC refers to the data amount of one message.

[0108] In the related art, the credit constraint configuration described above is statically configured, so that after the configuration is initialized, the credit limit is fixed, and in the subsequent process of transmitting data, the sending end controls the sending of data according to the fixed credit limit. Taking the credit limit corresponding to each VC configuration as an example, the sending end sends data through any VC based on the credit limit of the any VC, increases the used credit of the any VC or reduces the available credit of the any VC according to the data that has been sent; the receiving end receives data through the any VC and stores it into the buffer corresponding to the any VC, and if the data is taken out from the buffer corresponding to the any VC, the corresponding credit is released, and an announcement of releasing the credit is sent to the sending end; after the sending end receives the announcement of releasing the credit sent by the receiving end, the available credit of the any VC is increased or the used credit of the any VC is reduced; the sending end can continue to send data only in the case that there is still available credit, otherwise it stops sending data and waits for the credit release of the receiving end.

[0109] wherein the available credit refers to a constraint of the amount of data that the sender can still send. Optionally, the available credit can be equal to the difference between the credit limit and the used credit, or can be greater than the difference between the credit limit and the used credit. For example, in the case of the receiver configuring the total credit limit, the per-VC credit limit is configured locally by the sender. When the sender actually sends data, the total credit limit is a hard constraint, i.e., the total used credit and the credit for data to be sent must not exceed the total credit limit. However, the per-VC credit limit is not a hard constraint. For example, when there is no data to be sent in the first VC, the second VC can use the credit corresponding to the first VC, and at this time, the sum of the available credit and the used credit corresponding to the second VC is greater than the per-VC credit limit corresponding to the second VC. In a possible case, the per-VC credit limit corresponding to each VC can be directly configured as the total credit limit, which means that the VC that sends data first occupies the credit first.

[0110] Exemplarily, referring to the schematic diagram of the CBFC transceiving process shown in FIG. 1. Taking the case of multiple VCs sharing one buffer and the total credit limit as an example, after the buffer for receiving data and the total credit limit determined according to the buffer are configured, the receiver generates the released credit based on the data taken out from the buffer, and sends the released credit to the sender. The sender adjusts the used credit in the total credit limit according to the released credit, and sends data to the receiver in the case that the used credit does not exceed the total credit limit. The receiver stores the data received through multiple VCs into the buffer.

[0111] That is, the credit limit is determined by the buffer size, and after the credit constraint configuration, the size of the credit limit is fixed. If the buffer size of the receiving end changes, the size of the credit limit should also change accordingly. Therefore, a means for updating the credit limit is needed. The CBFC provides a method for adding and deleting VC. In a possible implementation, the original configured VC can be deleted first, and then a newly configured VC is added. The new VC reinitializes a new credit limit, thereby realizing the change from the original credit limit to the new credit limit.

[0112] Exemplarily, the flow of deleting a VC in the CBFC can be as shown in FIG. 2. ① The receiving end updates the CBFC receiving configuration, which refers to the credit constraint configuration of the receiving end. Among them, one or more VCs are deleted, and the updated CBFC receiving configuration includes: local.R_VC_Want[x] = 0 (representing that the receiving end wants to delete VC[x], x being the number of VC), local.R_VC_RTR[x] = 1 (representing that the receiving end maintains the receiving state of VC[x]). ② The receiving end sends the updated CBFC receiving configuration to the sending end to request the sending end to delete VC[x]. ③ After the sending end receives the updated CBFC receiving configuration sent by the receiving end, the following operations are performed: for each VC[x] that satisfies remote.R_VC_Want[x] = = 0 and local.S_VC_RTS[x] = = 1, that is, the VC[x] that the remote receiving end wants to delete and that the local sending end is in the sending state, stop the subsequent data from entering the VC[x] queue, and wait for the VC[x] queue to be emptied (that is, the data in the current queue is sent). The sending end updates the CBFC sending configuration, which refers to the credit constraint configuration of the sending end. The updated CBFC sending configuration includes: local.S_VC_RTS[x] = 0 (representing that the sending end stops sending data of VC[x]).

[0113] Wherein, from the receiving end, local refers to the receiving end, remote refers to the sending end; from the sending end, local refers to the sending end, remote refers to the receiving end. In the embodiment of the application, local is used to indicate a parameter configured locally, and remote is used to indicate a parameter configured for the opposite end. For example, R_VC_Want[x] is a parameter configured for the receiving end, so that R_VC_Want[x] is local.R_VC_Want[x] at the receiving end and remote.R_VC_Want[x] at the sending end. The value of remote.R_VC_Want[x] is the same as that of local.R_VC_Want[x], which is the value of R_VC_Want[x]. For another example, S_VC_RTS[x] is a parameter configured for the sending end, so that S_VC_RTS[x] is local.S_VC_RTS[x] at the sending end and remote.S_VC_RTS[x] at the receiving end. The value of remote.S_VC_RTS[x] is the same as that of local.S_VC_RTS[x], which is the value of S_VC_RTS[x].

[0114] Continuing to refer to FIG. 2, ④ the sending end sends the updated CBFC sending configuration to the receiving end, to inform the receiving end that the sending of data of VC[x] has been stopped. ⑤ After receiving the updated CBFC sending configuration sent by the sending end, the receiving end performs the following operations: for each VC[x] with remote.S_VC_RTS[x] == 0 and local.R_VC_RTR[x] == 1, i.e. the VC[x] for which the sending end has stopped sending and the receiving end is still in the receiving state, waits for the data of VC[x] to be taken out from the buffer of the receiving end for processing, updates the CBFC receiving configuration, and the updated CBFC sending configuration includes: local.R_VC_RTR[x] = 0 (representing that the receiving end stops receiving data of VC[x]). ⑥ The receiving end sends the updated CBFC receiving configuration to the sending end, to inform the sending end that the receiving of data of VC[x] has been stopped. ⑦ The sending end deletes VC[x]. For each VC[x] with the state of remote.R_VC_RTR[x] changing from 1 to 0, the VC[x] is deleted through the above process. The deleted VC[x] can be temporarily suspended, or can be changed from a lossless VC to a best effort VC, and can be changed back to a lossless VC with a new credit limit through re-initialization. The lossless VC refers to a VC for controlling traffic transmission based on a credit limit, and can realize lossless transmission; the best effort VC refers to a VC for transmitting as much traffic as possible, and may have losses such as packet loss.

[0115] Exemplarily, the process of adding a VC in CBFC can be shown in FIG. 3. Taking the credit limit corresponding to each VC configuration as an example, ① the receiving end updates the CBFC receiving configuration. Among them, one or more VCs are added, and the updated CBFC receiving configuration includes: local.R_VC_Want[x] = 1 (representing that the receiving end wants to add VC[x]), local.R_VC_RTR[x] = 0 (representing that the receiving end is not ready for data reception of VC[x]), and local.R_VC_Creditlimit[x] (representing the credit limit of VC[x]). ② The receiving end sends the updated CBFC receiving configuration to the sending end to request the sending end to add VC[x]. ③ After the sending end receives the updated CBFC receiving configuration sent by the receiving end, the sending end performs the following operations: for each VC[x] that satisfies remote.R_VC_Want[x] = = 1 and local.S_VC_RTS[x] = = 0, the sending end updates local.S_VC_RTS[x] = 1 (representing that the sending end is ready for data sending of VC[x]) in the CBFC sending configuration, and configures the credit limit of VC[x] using Remote.R_VC_CreditLmit[x].

[0116] Continuing FIG. 3, ④ the sending end sends the updated CBFC sending configuration to the receiving end to notify the receiving end that the sending end is ready for data sending of VC[x]. ⑤ After the receiving end receives the updated CBFC sending configuration sent by the sending end, the receiving end performs the following operations: for each VC[x] that satisfies remote.S_VC_RTS[0] = = 1 and local.R_VC_RTR[x] = = 0, i.e., the sending end is ready for sending and the receiving end is not ready for receiving, the receiving end updates local.R_VC_RTR[x] = 1 in the CBFC receiving configuration. ⑥ The receiving end sends the updated CBFC receiving configuration to the sending end to notify the sending end that the receiving end is ready for data reception of VC[x]. ⑦ The sending end sends data based on the credit limit of VC[x] for each VC[x] that satisfies remote.R_VC_RTR[x] = = 1 and local.S_VC_RTS[x] = = 1. In this way, the new credit limit configuration of new VC[x], i.e., the addition of lossless VC, is completed.

[0117] However, the updating of the credit constraint by adding or deleting the VC needs the sending end and the receiving end to suspend the traffic transmission and reception of the original VC, which will cause the traffic interruption of the original VC, affect the sending time and completion time of the service traffic, and affect the service performance. Therefore, how to dynamically adjust the credit limit of the started VC without affecting the service traffic (i.e., without flow suspension) is a problem to be solved urgently.

[0118] Embodiments of the present application provide a credit updating method, which can realize dynamic adjustment of the credit limit. The method can be applied to any CBFC using scenario, including but not limited to networks such as Ultra Ethernet Consortium (UEC), InfiniBand, and buses such as peripheral component interconnect express (PCIe) and NVLink. Referring to FIG. 4, FIG. 4 is a schematic diagram of an implementation environment of a credit updating method provided by an embodiment of the present application, which includes a first device 101 and a second device 102. The first device 101 and the second device 102 are connected in communication by wireless or wired manner, for example, are directly connected by an Ethernet cable or an optical cable, or there can be other devices between the first device 101 and the second device 102, i.e., the first device 101 and the second device 102 are not directly connected, and the CBFC function is deployed on the first device 101 and the second device 102. Optionally, the first device 101 is a sending end, and the second device 102 is a receiving end; or the first device 101 is a receiving end, and the second device 102 is a sending end.

[0119] It should be noted that the first device 101 or the second device 102 mentioned in the embodiments of the present application can be a switch, a router, a terminal, a server, etc., or a part of a component on a device, for example, a single board, a line card, a network card, or a functional module on the device, or a chip for implementing the method of the present application, for example, a data center switching chip or a graphics processing unit (GPU) chip, etc., which is not limited in the embodiments of the present application. When the first device 101 or the second device 102 is a chip, the transceiver module for implementing the method can be an interface circuit of the chip, and the processing module can be a processing circuit with processing function in the chip.

[0120] Exemplarily, the system architecture of the first device 101 or the second device 102 can be as shown in FIG. 5. The system architecture of the first device 101 is the same as that of the second device 102, and the first device 101 is taken as an example for description. The first device 101 includes a data link layer and a physical (PHY) layer, and the data link layer and the PHY layer perform data transmission through a medium independent interface (MII).

[0121] The data link layer includes a plurality of VC queues, a transmission selection, an input buffer and a medium access control (MAC) layer. The plurality of VC queues are used to buffer data to be sent. The transmission selection performs data transmission according to the control of the CBFC. The input buffer is used to buffer received data. The CBFC is located between the transmission selection and the input buffer to perform flow control. The PHY layer includes a physical coding sublayer (PCS), a physical media attach (PMA) and a physical media dependent (PMD). Optionally, the CBFC is implemented in the interface link layer of the first device 101 or the second device 102, and the credit constraint configuration is also implemented in the interface register and the link layer function.

[0122] Those skilled in the art should understand that the above-mentioned first device 101 and second device 102 are only examples, and other existing or future first devices 101 and second devices 102 that can be applicable to the present application should also be included in the protection scope of the present application, and are hereby incorporated by reference.

[0123] Referring to FIG. 6, FIG. 6 is an interaction diagram of a credit updating method provided by an embodiment of the present application. The method is taken as an example of being executed by the first device and the second device, and the method can be applied to the implementation environment shown in FIG. 4, i.e., the first device and the second device can be the first device 101 and the second device 102 shown in FIG. 4. In the method, the first device is a receiving end of data, and the second device is a sending end of data. Before the method is executed, the credit constraint configuration between the first device and the second device has been negotiated. Optionally, the data transmission based on the configured credit constraint between the first device and the second device has been started. As shown in FIG. 6, the credit updating method includes the following steps 601-603.

[0124] In step 601, the first device determines a first credit constraint of the first device, the first credit constraint indicating a constraint of an updated allowed received data amount of the first device.

[0125] In the embodiments of the present application, the first device is a receiving end of data transmission, and the first device controls the reception of data according to the credit constraint of the first device, which can be referred to as a receiving credit constraint. The first credit constraint is a variable describing the constraint of the updated allowed received data amount of the first device, and the value of the first credit constraint determines the size of the data amount that the first device can receive after being updated. The constraint of the data amount can be an upper limit value of the data amount or a maximum value of the data amount.

[0126] In the embodiments of the present application, determining the first credit constraint means determining the value of the first credit constraint. The value of the first credit constraint is determined, which does not mean that the first device uses the first credit constraint for data reception, that is, the first device has completed the update of the credit constraint, and the value of the first credit constraint can also be determined before the update action is performed. Similarly, the constraint of the updated allowed received data amount does not mean that the first device has updated the constraint of the allowed received data amount, and the value of the constraint of the updated allowed received data amount can also be determined before the update action is performed.

[0127] Optionally, the first credit constraint can be determined according to the updated buffer. For example, R-credit limit=(buffer size÷cell size), or R-credit limit=(buffer size÷cell size)-1. Wherein, R-credit limit represents the first credit constraint, buffer size represents the size of the updated buffer, and cell size represents the unit size of a credit. The updated buffer is similar to the first credit constraint, and the updated buffer in the embodiments of the present application means determining the value of the updated buffer. The value of the updated buffer is determined, which does not mean that the buffer of the first device has been updated, and the value of the updated buffer can also be determined before the update action is performed. The value of the updated buffer can be obtained by manual configuration, or can be determined according to the usage of the buffer.

[0128] It can be understood that the embodiment of the present application does not limit the value of the first credit constraint, and in an implementation, the first credit constraint can also be determined according to the third credit constraint and the change of the service demand. The third credit constraint indicates the constraint of the allowed received data amount of the first device before the update. Specifically, the service demand for credit increases, so that the first credit constraint is greater than the credit value corresponding to the third credit constraint, and the difference is related to the case of the increase of the service demand. Conversely, the service demand for credit decreases, so that the first credit constraint is less than the credit value corresponding to the third credit constraint, and the difference is also related to the case of the decrease of the service demand.

[0129] In step 602, the first device sends first indication information to the second device, and the first indication information indicates that the second device updates the credit constraint of the second device according to the first credit constraint.

[0130] After determining the first credit constraint, the first device sends the first indication information to the second device, regardless of whether the first credit constraint of the first device is updated. Thus, the first indication information indicates that the second device updates the credit constraint of the second device according to the first credit constraint. Alternatively, if the first device has completed the update of the first credit constraint, the first indication information can also indicate that the first device updates the first credit constraint; or the first indication information no longer indicates that the second device updates the credit constraint of the second device according to the first credit constraint, but only indicates that the first device updates the first credit constraint, and the second device can actively update the credit constraint of the second device according to the first credit constraint according to the received first indication information.

[0131] In the embodiment of the present application, one port between the first device and the second device can be divided into multiple VCs, and data is transmitted through the multiple VCs. The multiple VCs are lossless VCs. The multiple VCs correspond to multiple first virtual queues on the first device, and correspond to multiple second virtual queues on the second device, that is, the multiple first virtual queues on the first device and the multiple second virtual queues on the second device correspond one-to-one. The credit configuration mode between the first device and the second device includes but is not limited to three modes, and the content of the first credit constraint is different for different credit configuration modes.

[0132] The first kind is a shared credit mode.

[0133] In the shared credit mode, the first device configures one overall credit constraint for the multiple VCs. That is, the multiple VCs correspond to the multiple first virtual queues on the first device, which share one buffer space, and the overall credit constraint of the multiple first virtual queues can be determined according to the overall size of the buffer and the unit buffer size represented by one credit. Among them, the multiple VCs can be all or part of the VCs in one port, or multiple VCs in multiple ports.

[0134] Therefore, the first credit constraint comprises a total credit constraint of the plurality of first virtual queues on the first device, and the total credit constraint of the plurality of first virtual queues indicates a constraint of an allowed received data amount updated by the plurality of first virtual queues. In this case, the first indication information indicates that the second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues.

[0135] In a possible implementation, before determining the first credit constraint, the first device further determines switching of a credit configuration mode of the first device, i.e., switching from the exclusive credit mode to the shared credit mode, so that the first credit constraint comprises a total credit constraint of the plurality of first virtual queues on the first device. That is, the credit constraint before updating, i.e., the third credit constraint, comprises a credit constraint corresponding to a first virtual queue on the first device. In accordance with the determination of the first credit constraint, the determination of the switching of the credit configuration mode of the first device in the embodiment of the application only means that the first device needs to switch the mode according to the updating requirement, and does not mean that the first device has already switched the mode.

[0136] In this case, the first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to a total credit constraint of the plurality of second virtual queues on the second device, i.e., indicates that the second device switches from the exclusive credit mode to the shared credit mode. That is, the first indication information realizes both the functions of indicating the updating of the credit constraint and indicating the switching of the credit configuration mode, thereby improving the utilization rate of the first indication information. Alternatively, the first device sends second indication information to the second device, and the second indication information indicates that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues on the second device, i.e., indicates that the second device switches from the exclusive credit mode to the shared credit mode. That is, the first indication information realizes the function of indicating the updating of the credit constraint, and the second indication information realizes the function of switching the credit configuration mode, so that the sending of the indication information is more flexible.

[0137] Secondly, the exclusive credit mode.

[0138] In the exclusive credit mode, the first device configures a corresponding credit constraint for each VC. That is, each VC corresponds to a buffer space exclusively used by each first virtual queue on the first device, and the credit constraint corresponding to each first virtual queue can be determined according to a buffer size corresponding to each first virtual queue and a unit buffer size represented by a credit.

[0139] Therefore, the first credit constraint can include a credit constraint corresponding to the first virtual queue on the first device, and the credit constraint corresponding to the first virtual queue indicates a constraint on an allowed amount of data received by the first virtual queue for updating. In this case, the first indication information indicates that the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue, and the first virtual queue corresponds to the second virtual queue. The first virtual queue can be any one of the first virtual queues on the first device. Alternatively, the first credit constraint can include credit constraints corresponding to a plurality of first virtual queues on the first device, and the first indication information indicates that the second device updates the credit constraints corresponding to a plurality of second virtual queues on the second device according to the credit constraints corresponding to the plurality of first virtual queues, respectively.

[0140] In a possible implementation, before determining the first credit constraint, the first device further determines switching of a credit configuration mode of the first device, i.e., switching from the shared credit mode to the exclusive credit mode, so that the first credit constraint includes the credit constraint corresponding to the first virtual queue on the first device. That is, the credit constraint before updating, i.e., the third credit constraint, includes the total credit constraint of the plurality of first virtual queues on the first device.

[0141] In this case, the first indication information further indicates that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue, i.e., indicates that the mode switching from the shared credit mode to the exclusive credit mode is performed before updating the second credit constraint. That is, the two functions of indicating the updating of the credit constraint and indicating the switching of the credit configuration mode are realized by one first indication information, thereby improving the utilization of the first indication information. Alternatively, the first device sends third indication information to the second device, and the third indication information indicates that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue, i.e., indicates that the mode switching from the shared credit mode to the exclusive credit mode is performed before updating the second credit constraint. That is, the function of indicating the updating of the credit constraint is realized by the first indication information, and the function of switching the credit configuration mode is realized by the third indication information, so that the sending of the indication information is more flexible.

[0142] Thirdly, a hybrid credit mode.

[0143] In the hybrid credit mode, a total credit constraint is configured for the plurality of VC, and a corresponding credit constraint is configured for each VC. Each VC can be each of the plurality of VC, or can be other VC in addition to the plurality of VC. Therefore, the data transmission of each VC can be precisely controlled, and the total data transmission of the plurality of VC can be controlled from the overall perspective.

[0144] Therefore, the first credit constraint includes both the total credit constraint of the plurality of first virtual queues on the first device and the total credit constraint of the plurality of first virtual queues on the first device. In this case, the first indication information indicates both that the second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues and that the second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues.

[0145] Thus, the embodiments of the present application can implement credit updating for the three different credit configuration modes. In the case where no mode switching occurs, the updating in the embodiments of the present application includes increasing or decreasing, the first indication information can include two types of indication information 1 and indication information 2, the indication information 1 represents increasing, and the indication information 2 represents decreasing. In the case where mode switching occurs, the updating in the embodiments of the present application also includes switching and updating, the first indication information can also include a third type of indication information 3, and the indication information 3 represents switching and updating. The switching and updating can be switching the mode first and then increasing or decreasing, or can be increasing or decreasing first and then switching, and the embodiments of the present application do not limit this.

[0146] The embodiments of the present application do not limit the communication protocol used for the interaction between the first device and the second device in the credit updating process, and the communication protocol can include, but is not limited to, a physical layer protocol, a data link layer protocol, or a transmission control protocol, etc. For example, the first indication information, the second indication information, or the third indication information can be carried through an LLDP message or an O-code extension. The O-code is a mechanism used for enhancing control and state information transmission in high-speed Ethernet. In this case, taking sending the first indication information as an example, the first device sending the first indication information to the second device can include: the first device sending an LLDP message to the second device, the LLDP message carrying the first indication information; or the first device sending an O-code to the second device, the O-code carrying the first indication information. For example, the first indication information is carried in an extension TLV field of the LLDP message, and the TLV field is an abbreviation of type (type), length (length), and value (value) field.

[0147] Exemplarily, taking the case of carrying the first indication information through O code as an example. In the case that the first indication information indicates both the switching of the credit constraint and the switching of the credit configuration mode, one O code can carry one code block which can indicate both the switching of the credit constraint and the switching of the credit configuration mode; or, two code blocks can be carried through the O code, and the two code blocks are respectively used for indicating the switching of the credit constraint and indicating the switching of the credit configuration mode. Taking the case of sending the first indication information and the second indication information through O code as an example, the first indication information and the second indication information can be carried through two O codes respectively, or the first indication information and the second indication information can be carried through two parts of one O code, or the first indication information and the second indication information can be carried through at least two O codes.

[0148] In a possible implementation, the first indication information can contain the first credit constraint, so that the second device can obtain the first credit constraint after receiving the first indication information. In another possible implementation, the first indication information can not contain the first credit constraint, and the first device can send the first credit constraint to the second device, so that the second device can quickly obtain the first credit constraint; or, the first device can negotiate with the second device in advance the step size of each update, and the first device updates according to the step size after receiving the first indication information, and the step size can indicate the first credit constraint.

[0149] Optionally, the first device sends the total credit constraint of the plurality of first virtual queues to the second device; or, the first device sends the credit constraint corresponding to the first virtual queue to the second device; or, the first device sends the total credit constraint of the plurality of first virtual queues and the credit constraint corresponding to the first virtual queue to the second device. In this way, the second device can quickly update the credit constraint of the second device according to the first credit constraint, and the efficiency of credit update is improved. The sending mode of the first credit constraint can refer to the sending mode of the first indication information, for example, the first credit constraint is carried through the LLDP packet or O code extension, which will not be described herein again.

[0150] Exemplarily, the embodiment of the present application defines a new O-code as a credit limit_update Ordered Set (CL_Update Ordered Set), and the type value of the CL_Update Ordered Set adopts a new value, for example, the type value is 0x11. Taking an example of sending a first credit limit through the CL_Update Ordered Set, the first credit limit includes a credit limit corresponding to a first virtual queue. The CL_Update Ordered Set can include the type value and the credit limit (the credit limit corresponding to the first virtual queue), and the value of the type value is used to indicate that the O-code is a credit limit_update Ordered Set. Optionally, the CL_Update Ordered Set can further include at least one of the following: a VC number (VC[x]) corresponding to the first virtual queue, a credit configuration mode (mode), an O-code identifier (O-code), or a cyclic redundancy check (CRC).

[0151] Taking an example of a 64B / 66B PCS encoding mode, the encoding format of the CL_Update Ordered Set can be shown in Table 1 as follows: the first row represents bit positions, and the second row represents Ordered Set Content. The Ordered Set Content includes a sync header, a code block type, a type value, a VC[x], a mode, an O-code, a credit limit, and a reserved (resv) bit. Exemplarily, the value of the sync header is ‘b10, the value of the code block type is 0x4B, 0x4B indicates that the code block is an O-code, the credit limit occupies 20 bits, and the reserved bit can carry a CRC. The O-code in the UEC is 0xf, and the embodiment of the present application can apply for a new O-code value to indicate that the CL_Update Ordered Set is a new code. The length and position of each field in Table 1 are only examples, and can be flexibly adjusted in actual application.

[0152] Table 1

[0153] The format of the Ordered Set content in Table 1 transmitted through the MII can be shown in Table 2. The message of the CL_Update Ordered Set transmission is CL_Update. The MII includes 8 lanes, and different lanes are used to transmit different Ordered Set content.

[0154] Table 2

[0155] In step 603, the second device receives the first indication information sent by the first device, and updates the second credit constraint of the second device according to the first indication information according to the first credit constraint. The second credit constraint indicates the constraint of the updated data amount allowed to be sent by the second device.

[0156] In the embodiments of the present application, the second device is a sending end of data transmission, and the second device controls the sending of data according to the credit constraint of the second device. The credit constraint of the second device can be referred to as a sending credit constraint. Updating the second credit constraint of the second device means updating the credit constraint of the second device to the second credit constraint. The second credit constraint is a variable describing the constraint of the updated data amount allowed to be sent by the second device, and the value of the second credit constraint determines the size of the data amount that can be received by the second device. The constraint of the data amount can be the upper limit value of the data amount or the maximum value of the data amount. Alternatively, the first device and the second device are directly connected upstream and downstream devices, or are non-directly connected upstream and downstream devices, or are end point devices at both ends of the network, for example, non-directly connected end point devices at both ends of the network.

[0157] In a possible implementation, the way of updating the second credit constraint of the second device according to the first indication information according to the first credit constraint can be that the second credit constraint is determined as the first credit constraint according to the first indication information, that is, the synchronization of the first credit constraint and the second credit constraint is maintained; or the second credit constraint is determined as a value smaller than the first credit constraint according to the first indication information, that is, it is ensured that the second credit constraint will not exceed the first credit constraint.

[0158] According to the three credit configuration modes introduced in step 602, for different credit configuration modes, the way of updating the second credit constraint of the second device is also different.

[0159] In the shared credit mode, the first credit constraint includes a total credit constraint of the plurality of first virtual queues on the first device, and the second device updates a total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues. Optionally, the second device updates a credit constraint of any second virtual queue in the plurality of second virtual queues according to the updated total credit constraint of the plurality of second virtual queues, the credit constraint of the any second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the any second virtual queue. For example, the total credit constraint of the plurality of second virtual queues is allocated to each second virtual queue in the plurality of second virtual queues in a manner not limited by embodiments of the present application, including but not limited to uniform allocation or allocation according to a preset ratio.

[0160] If the first indication information further indicates that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues, or the second device receives the second indication information, the second device performs mode switching from the exclusive credit mode to the shared credit mode before updating the second credit constraint, so that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues.

[0161] In the exclusive credit mode, the first credit constraint can include the credit constraint corresponding to the first virtual queue on the first device, and the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue. If the first indication information further indicates that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue, or the second device receives the third indication information, the second device performs mode switching from the shared credit mode to the exclusive credit mode before updating the second credit constraint, so that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

[0162] In the hybrid credit mode, the first credit constraint includes both the total credit constraint of the plurality of first virtual queues on the first device and the total credit constraint of the plurality of first virtual queues on the first device. Then, the second device updates both the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues and the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues.

[0163] Thus, the second device can complete the updating of the second credit constraint in the above-mentioned manners. Optionally, the second device sends the data stream to the first device while updating the second credit constraint. Thus, the second device can keep sending the data stream to the first device in the process of updating the second credit constraint, without interrupting the data stream, thereby avoiding the impact of the updating of the credit constraint on the transmission of the data stream. That is, the deleting or disabling operation of the started VC is not involved in the process of updating the credit constraint, and thus the transmission of the data stream through the started VC can be kept.

[0164] In a possible implementation, after completing the updating of the second credit constraint, the second device sends a credit constraint updating response to the first device, where the credit constraint updating response indicates that the second device has completed the updating of the second credit constraint; and the first device receives the credit constraint updating response sent by the second device, so as to enable the first device to determine that the second device has completed the credit updating. The sending manner of the credit constraint updating response can refer to the sending manner of the first indication information, which will not be described herein again.

[0165] In the embodiments of the present application, the timing of updating the first credit constraint by the first device is not limited. Optionally, the first device can receive data according to the buffer space corresponding to the first credit constraint before receiving the credit constraint updating response sent by the second device; or the first device needs to keep receiving data according to the buffer space corresponding to the third credit constraint before receiving the credit constraint updating response sent by the second device, and receive data according to the buffer space corresponding to the first credit constraint after receiving the credit constraint updating response sent by the second device.

[0166] Exemplarily, in the case where the updating operation is to increase the first credit constraint, the first device completes the updating of the first signal constraint before receiving the credit constraint updating response sent by the second device. In the case where the updating operation is to decrease the first credit constraint, the first device updates the first signal constraint after receiving the credit constraint updating response sent by the second device.

[0167] In the method provided in the embodiments of the present application, the order of updating the first credit constraint by the first device and receiving the response sent by the second device is not limited, and the order of updating the first credit constraint by the first device and sending the first indication information is not limited. The first device can receive data according to the buffer space corresponding to the first credit constraint before sending the first indication information to the second device, or receive data according to the buffer space corresponding to the first credit constraint after sending the first indication information to the second device.

[0168] Optionally, in the case where the updating process includes mode switching, the response of the credit constraint updating also indicates that the second device has completed the switching of the credit configuration mode. Alternatively, the second device sends a response of the credit configuration mode switching to the first device after completing the mode switching, and the response of the credit configuration mode switching indicates that the second device has completed the switching of the credit configuration mode. Thus, the first device can determine that the second device has completed the switching of the credit configuration mode. Similarly to the manner in which the first device updates the first credit constraint, the first device can complete the mode switching before determining that the second device has completed the switching of the credit configuration mode, or perform the mode switching after determining that the second device has completed the switching of the credit configuration mode. In one possible case, the response of the credit constraint updating and the response of the credit configuration mode switching can be the same response, i.e., the same response indicates that the second device has completed the switching of the credit configuration mode and the updating of the credit constraint.

[0169] Thus, through the steps 601-603, the first device and the second device achieve the updating of the credit constraint without interrupting the data flow, avoid the impact of the credit updating on the transmission of the data flow, enable dynamic adjustment of the credit constraint configuration according to buffer changes, and further enable more accurate flow control results based on the updated credit constraint.

[0170] Next, taking the first device as the receiving end and the second device as the sending end, and taking the data exchanged between the first device and the second device in the credit updating process through the LLDP packet as an example, the credit updating method provided in the embodiments of the present application is described in combination with FIGS. 7-10.

[0171] Before the first device and the second device perform the credit updating process, the first device and the second device have completed the initialization configuration of the credit constraint. The initialization configuration parameters of the receiving end can include: local.R_NumVCs (representing the total number of locally supported VCs of the receiving end), local.R_TotalCredits (representing the total credit constraint of all VCs of the receiving end), local.R_CreditSize (representing the unit size of a credit corresponding to the input buffer of the receiving end), local.R_PktOvhd (representing the overhead size of each data packet in the buffer), and parameters corresponding to each VC. Taking VC[x] as an example, the parameters corresponding to the VC[x] include: local.R_VC_Want[x] = 1 (representing that the VC[x] remains as a lossless VC), local.R_VC_RTR[x] = 1 (representing that the VC[x] remains to use credits to receive packets), and local.R_VC_CreditLimit[x] (representing the credit constraint corresponding to the VC[x]).

[0172] Wherein, in case of shared credit mode, local.R_TotalCredits is non-0 and local.R_VC_CreditLimit[x] is 0; in case of exclusive credit mode, local.R_TotalCredits is 0 and local.R_VC_CreditLimit[x] is non-0; in case of hybrid credit mode, local.R_TotalCredits is non-0 and local.R_VC_CreditLimit[x] is also non-0.

[0173] In the credit update procedure shown in Fig. 7, the receiver initiates the credit update, and the updated configuration parameters include: local.R_VC_RTC[x] = 1 (representing that the receiver requests to update the credit constraint of the VC[x], i.e. the first indication information), R_TotalCredits and / or R_VC_CreditLimit[x] (updating R_TotalCredits in shared credit mode, updating R_VC_CreditLimit[x] in exclusive credit mode, and updating R_TotalCredits and R_VC_CreditLimit[x] in hybrid credit mode). In the updated configuration parameters, the receiver keeps local.R_VC_Want[x] = 1 (representing that the VC[x] remains as a lossless VC) and local.R_VC_RTR[x] = 1 (representing that the VC[x] remains to use credit to receive packets). Wherein, in case of increasing the credit constraint, the receiver directly uses the updated credit constraint, i.e. using the new buffer corresponding to the updated credit constraint to receive the data stream; in case of decreasing the credit constraint, the receiver keeps using the original credit constraint, i.e. using the original buffer corresponding to the original credit constraint to receive the data stream.

[0174] As shown in FIG. 7, the receiving end sends the updated configuration parameters of the receiving end to the sending end through a first LLDP message, i.e., the first LLDP message can carry R_VC_RTC[x] = 1, R_TotalCredits and / or R_VC_CreditLimit[x], etc. After receiving the first LLDP message, the sending end updates the configuration parameters of the sending end according to the updated configuration parameters of the remote end, i.e., the receiving end. For example, the sending end performs the following update operation on each VC[x] for which local.S_VC_RTS[x] == 1 and remote.R_RTC[x] == 1: for the shared credit mode, the sending end updates local.S_TotalCredits according to R_TotalCredits, and distributes the updated S_TotalCredits to all VCs (i.e., the sending end updates and sets the credit limit corresponding to each VC); for the exclusive credit mode, the sending end updates local.S_VC_CreditLimit[x] according to R_VC_CreditLimit[x].

[0175] Then, the sending end updates the state Local.S_VC_RTC[x] = 1 (representing that the sending end completes the credit configuration change, i.e., the response of the credit constraint update). The sending end sends the response of the credit constraint update to the receiving end through a second LLDP message, i.e., the LLDP message can carry S_VC_RTC[x] = 1. After receiving the second LLDP message, the receiving end determines that the credit configuration update of the two ends is completed based on remote.S_VC_RTC[x] == 1 and local.R_VC_RTC[x] == 1. In the case that the update of the credit constraint is to reduce, the receiving end starts to apply the updated credit constraint, and uses the new buffer corresponding to the updated credit constraint to receive the data stream.

[0176] Optionally, the first LLDP message can also carry R_VC_RTR[x] = 1 and R_VC_Want[x] = 1. This enables the receiving end to determine, according to R_VC_RTR[x] = 1, that the receiving end maintains the data reception of VC[x], and to determine, according to R_VC_Want[x] = 1, that the receiving end maintains VC[x] as a lossless VC. Thus, the sending end can perform the above update operation on each VC[x] for which R_VC_Want[x] == 1 and local.S_VC_RTS[x] == 1 and remote.R_RTC[x] == 1. And based on remote.R_VC_RTR[x] = 1, the sending end maintains local.S_VC_RTS[x] = 1 (representing that the sending end maintains the data sending, i.e., the data stream is not interrupted). Optionally, the first LLDP message can also include S_VC_RTS[x] = 1, so that the receiving end can determine that the sending end maintains the data sending.

[0177] In the credit increase procedure shown in FIG. 8, the difference from the credit update procedure shown in FIG. 7 is that the first indication information is replaced by R VC R TI [x] = 1 (representing that the receiving end requests to increase the credit constraint of the VC [x]), so that the receiving end can directly use the updated credit constraint, i.e., use the new buffer corresponding to the updated credit constraint to receive the data stream. In the credit decrease procedure shown in FIG. 9, the difference from the credit update procedure shown in FIG. 7 is that the first indication information is replaced by R VC R TD [x] = 1 (representing that the receiving end requests to decrease the credit constraint of the VC [x]), so that the receiving end needs to first keep using the credit constraint before the update, i.e., use the original buffer corresponding to the credit constraint before the update to receive the data stream. After confirming that the sending end completes the credit update, the receiving end uses the updated credit constraint, i.e., uses the new buffer corresponding to the updated credit constraint to receive the data stream.

[0178] In addition to dynamically updating the configuration value of the credit constraint, the credit configuration mode can also be dynamically modified. In the credit mode switching procedure shown in FIG. 10, the difference from the credit update procedure shown in FIG. 7 is that the first indication information is replaced by R VC R TM [x] = 1 (representing that the receiving end requests to switch the credit configuration mode of the VC [x]), and at this time the receiving end needs to first keep using the credit constraint before the mode switching. If the receiving end switches the credit configuration mode from the shared credit mode to the exclusive credit mode, R VC TotalCredit is set to 0, and the corresponding R VC CreditLimit [x] is set to the updated credit constraint, and then R VC CreditLimit [x] is carried in the first LLDP packet. If the credit configuration mode is switched from the exclusive credit mode to the shared credit mode, R VC CreditLimit [x] is set to 0, and the corresponding R VC TotalCredit is set to the updated total credit constraint, and then R VC TotalCredit is carried in the first LLDP packet. After receiving S VC R TM [x] = 1, the receiving end performs the mode switching operation and uses the updated credit constraint to receive the data.

[0179] The credit updating method of the embodiments of the present application is introduced above, and the embodiments of the present application further provide a credit updating apparatus corresponding to the above method. FIG. 11 is a structural schematic diagram of a credit updating apparatus provided by the embodiments of the present application, which can be applied to the first apparatus or the second apparatus. Based on the following multiple modules shown in FIG. 11, the credit updating apparatus shown in FIG. 11 can perform all or part of the operations performed by the first apparatus or the second apparatus in the method shown in FIG. 6. It should be understood that the apparatus can include more additional modules than the shown modules or omit part of the shown modules, and the embodiments of the present application do not limit this.

[0180] As shown in FIG. 11, the credit updating apparatus includes a transceiver module 1101 and a processing module 1102. The transceiver module 1101 can include a receiving module and / or a sending module. The receiving module is configured to perform operations related to receiving, and the sending module is configured to perform operations related to sending. In the case where the credit updating apparatus is applied to the first apparatus, the transceiver module 1101 is configured to perform the operations related to receiving and / or sending performed by the first apparatus in the method shown in FIG. 6, and the processing module 1102 is configured to perform other operations in addition to the operations related to receiving and / or sending performed by the first apparatus in the method shown in FIG. 6.

[0181] In a possible implementation, the processing module 1102 is configured to determine a first credit constraint of the first apparatus, the first credit constraint indicating a constraint on an amount of data allowed to be received by the first apparatus for updating; and the transceiver module 1101 is configured to send first indication information to the second apparatus, the first indication information indicating that the second apparatus updates a credit constraint of the second apparatus according to the first credit constraint.

[0182] In a possible implementation, the first credit constraint includes a total credit constraint of multiple first virtual queues on the first apparatus, the total credit constraint of the multiple first virtual queues indicating a constraint on an amount of data allowed to be received by the multiple first virtual queues for updating; and the first indication information indicates that the second apparatus updates a total credit constraint of multiple second virtual queues on the second apparatus according to the total credit constraint of the multiple first virtual queues, the multiple first virtual queues corresponding to the multiple second virtual queues.

[0183] In a possible implementation, the first indication information further indicates that the credit constraint of the second apparatus is switched from a credit constraint corresponding to a second virtual queue on the second apparatus to the total credit constraint of the multiple second virtual queues.

[0184] In a possible implementation, the transceiver module 1101 is further configured to send second indication information to the second apparatus, the second indication information indicating that the credit constraint of the second apparatus is switched from the credit constraint corresponding to the second virtual queue on the second apparatus to the total credit constraint of the multiple second virtual queues.

[0185] In a possible implementation, the first credit constraint comprises a first virtual queue corresponding credit constraint on the first device, the first virtual queue corresponding credit constraint indicating a constraint on an allowed received data amount of the first virtual queue updating; and the first indication information indicates that the second device updates the second virtual queue corresponding credit constraint on the second device according to the first virtual queue corresponding credit constraint, the first virtual queue corresponding to the second virtual queue.

[0186] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from a total credit constraint of a plurality of second virtual queues on the second device to the second virtual queue corresponding credit constraint.

[0187] In a possible implementation, the transceiver 1101 is further configured to send, to the second device, third indication information, the third indication information indicating that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the second virtual queue corresponding credit constraint.

[0188] In a possible implementation, the first credit constraint further comprises a total credit constraint of a plurality of first virtual queues on the first device, the total credit constraint of the plurality of first virtual queues indicating a constraint on an allowed received data amount of the plurality of first virtual queue updating; and the first indication information further indicates that the second device updates the total credit constraint of a plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues, the plurality of first virtual queues corresponding to the plurality of second virtual queues.

[0189] In a possible implementation, the transceiver 1101 is further configured to send, to the second device, the total credit constraint of the plurality of first virtual queues.

[0190] In a possible implementation, the transceiver 1101 is further configured to send, to the second device, the first virtual queue corresponding credit constraint.

[0191] In a possible implementation, the transceiver 1101 is further configured to receive a response to the credit configuration mode switching sent by the second device.

[0192] In a possible implementation, the processing module 1102 is further configured to switch the first credit constraint from the first virtual queue corresponding credit constraint on the first device to the total credit constraint of the plurality of first virtual queues before receiving the response to the credit mode switching sent by the second device; or switch the first credit constraint from the first virtual queue corresponding credit constraint on the first device to the total credit constraint of the plurality of first virtual queues after receiving the response to the credit mode switching sent by the second device.

[0193] In a possible implementation, the processing module 1102 is further configured to switch the first credit constraint from the total credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device before receiving the response to the credit mode switching sent by the second device; or switch the first credit constraint from the total credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device after receiving the response to the credit mode switching sent by the second device.

[0194] In a possible implementation, the transceiver module 1101 is further configured to receive the response to the credit constraint updating sent by the second device.

[0195] In a possible implementation, the processing module 1102 is further configured to receive data according to the buffer space corresponding to the first credit constraint before receiving the response to the credit constraint updating sent by the second device; or the processing module 1102 is further configured to receive data according to the buffer space corresponding to the first credit constraint after receiving the response to the credit constraint updating sent by the second device.

[0196] In a possible implementation, the transceiver module 1101 is configured to send an LLDP packet to the second device, where the LLDP packet carries the first indication information; or the transceiver module 1101 is configured to send an O code to the second device, where the O code carries the first indication information.

[0197] In the case where the credit updating device is applied to the second device, the transceiver module 1101 is configured to perform the receiving and / or sending related operations performed by the second device in the method shown in FIG. 6, and the processing module 1102 is configured to perform other operations in addition to the receiving and / or sending related operations performed by the second device in the method shown in FIG. 6.

[0198] In a possible implementation, the transceiver module 1101 is configured to receive the first indication information sent by the first device, where the first indication information indicates that the second device updates the credit constraint of the second device according to the first credit constraint, and the first credit constraint indicates the constraint of the data amount allowed to be received by the first device after the update; and the processing module 1102 is configured to update the second credit constraint of the second device according to the first credit constraint according to the first indication information, where the second credit constraint indicates the constraint of the data amount allowed to be sent by the second device after the update.

[0199] In a possible implementation, the first indication information indicates that the second device updates the overall credit constraint of the plurality of second virtual queues on the second device according to the overall credit constraint of the plurality of first virtual queues on the first device, the plurality of second virtual queues corresponding to the plurality of first virtual queues; the processing module 1102 is configured to update the overall credit constraint of the plurality of second virtual queues on the second device according to the overall credit constraint of the plurality of first virtual queues according to the first indication information, the overall credit constraint of the plurality of second virtual queues indicating a constraint on an updated amount of data allowed to be sent by the plurality of second virtual queues.

[0200] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues; the processing module 1102 is further configured to switch the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues according to the first indication information.

[0201] In a possible implementation, the transceiver module 1101 is further configured to receive second indication information sent by the second device, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues; and the processing module 1102 is further configured to switch the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues according to the second indication information.

[0202] In a possible implementation, the processing module 1102 is further configured to update the credit constraint of any second virtual queue in the plurality of second virtual queues according to the updated overall credit constraint of the plurality of second virtual queues, the credit constraint of the any second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the any second virtual queue.

[0203] In a possible implementation, the first indication information indicates that the second device updates the credit constraint corresponding to the second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue on the first device, the first virtual queue corresponding to the second virtual queue; and the processing module 1102 is configured to update the credit constraint corresponding to the second virtual queue according to the credit constraint corresponding to the first virtual queue according to the first indication information, the credit constraint corresponding to the second virtual queue indicating a constraint on an updated amount of data allowed to be sent by the second virtual queue.

[0204] In a possible implementation, the first indication information further indicates that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue; the processing module 1102 is further configured to switch the second credit constraint from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue according to the first indication information.

[0205] In a possible implementation, the transceiver module 1101 is further configured to receive third indication information sent by the second device, the third indication information indicating that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue; and the processing module 1102 is further configured to switch the second credit constraint from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue according to the third indication information.

[0206] In a possible implementation, the first indication information further indicates that the second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues on the first device, the plurality of first virtual queues corresponding to the plurality of second virtual queues; and the processing module 1102 is further configured to update the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues according to the first indication information, the total credit constraint of the plurality of second virtual queues indicating the updated allowed sending data amount constraint of the plurality of second virtual queues.

[0207] In a possible implementation, the transceiver module 1101 is further configured to receive the total credit constraint of the plurality of first virtual queues sent by the first device.

[0208] In a possible implementation, the transceiver module 1101 is further configured to receive the credit constraint corresponding to the first virtual queue sent by the first device.

[0209] In a possible implementation, the transceiver module 1101 is further configured to send, to the first device, a response of the credit configuration mode switching.

[0210] In a possible implementation, the transceiver module 1101 is further configured to send, to the first device, a response of the credit constraint updating.

[0211] In a possible implementation, the transceiver module 1101 is further configured to send, to the first device, a data stream while updating the second credit constraint.

[0212] It should be understood that the apparatus provided by the above-mentioned Figure 11 is only exemplified by the above-mentioned division of functional modules when implementing its functions, and in actual application, the above-mentioned functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided by the above-mentioned embodiments belong to the same concept, and the specific implementation process and beneficial effects are detailed in the method embodiments, which will not be described here.

[0213] Referring to Figure 12, Figure 12 shows a structural schematic diagram of a network device 2000 provided by an example embodiment of the present application. The network device 2000 shown in Figure 12 is used to perform the operations involved in the credit updating method shown in Figure 6 described above. The network device 2000 is, for example, a switch, a router, etc., and the network device 2000 can be implemented by a general bus architecture.

[0214] As shown in Figure 12, the network device 2000 includes at least one processor 2001, a memory 2003, and at least one communication interface 2004.

[0215] The processor 2001 is, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processer (NP), a graphics processing unit (GPU), a neural-network processing units (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits used to implement a design described in the present application. For example, the processor 2001 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or other programmable logic device, transistor logic, a hardware component, or any combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. It can implement or execute various logical blocks, modules, and circuits described in combination with the disclosure of the embodiments of the present application. The processor can also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0216] Optionally, the network device 2000 also includes a bus. The bus is used to transmit information between the components of the network device 2000. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one line is shown in FIG. 12, but it does not mean that there is only one bus or only one type of bus.

[0217] The memory 2003 is, for example, a read-only memory (ROM) or other type of static storage device that can store static information and instructions that are not expected to change, a random access memory (RAM), or other type of dynamic storage device that can store information and instructions that are expected to change, a electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disk storage, a magnetic disk storage or other magnetic storage devices, or any other medium capable of storing instructions or data that is accessible to a computer, but not limited to. The memory 2003 may, for example, exist independently and be connected to the processor 2001 through a bus. The memory 2003 may, for example, be integrated with the processor 2001.

[0218] The communication interface 2004 uses any transceiver-like mechanism for communicating with other devices or a communication network, which can be an Ethernet, a radio access network (RAN), a wireless local area networks (WLAN), or the like. The communication interface 2004 can include a wired communication interface and can also include a wireless communication interface. The communication interface 2004 can be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a wireless local area networks (WLAN) interface, a cellular network communication interface, or a combination thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In the embodiments of the present application, the communication interface 2004 can be used for the network device 2000 to communicate with other devices.

[0219] In particular implementations, as one example, the processor 2001 can include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 12. Each of these processors can be a single-core CPU or a multi-core CPU. A processor, as used herein, can refer to one or more devices, circuits, and / or processing cores for processing data, such as computer program instructions.

[0220] In particular implementations, as one example, the network device 2000 can include multiple processors, such as the processor 2001 and the processor 2005 shown in FIG. 12. Each of these processors can be a single-core CPU or a multi-core CPU. A processor, as used herein, can refer to one or more devices, circuits, and / or processing cores for processing data, such as computer program instructions.

[0221] In particular implementations, as one example, the network device 2000 can also include an output device and an input device. The output device is in communication with the processor 2001 and can display information in various ways. For example, the output device can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, a projector, or the like. The input device is in communication with the processor 2001 and can receive user input in various ways. For example, the input device can be a mouse, a keyboard, a touch screen device, a sensor device, or the like.

[0222] In some embodiments, the memory 2003 is used to store program code 2010 for implementing the solutions of the present application, and the processor 2001 can execute the program code 2010 stored in the memory 2003. That is, the network device 2000 can implement the credit updating method provided by the method embodiments through the processor 2001 and the program code 2010 in the memory 2003. The program code 2010 can include one or more software modules. Alternatively, the processor 2001 itself can also store program codes or instructions for implementing the solutions of the present application.

[0223] In particular embodiments, the network device 2000 of the embodiments of the present application can correspond to the first device in each of the above method embodiments, and the processor 2001 in the network device 2000 reads instructions in the memory 2003, so that the network device 2000 shown in FIG. 12 can perform all or part of the operations performed by the first device.

[0224] In a possible implementation, the processor 2001 is configured to determine a first credit constraint of the first device, the first credit constraint indicating a constraint on an allowed received data amount of the first device for updating; and send first indication information to the second device, the first indication information indicating that the second device updates a credit constraint of the second device according to the first credit constraint.

[0225] For details of other optional implementations, refer to the method embodiments described above, which will not be repeated here.

[0226] For example, the network device 2000 can correspond to the second device in the method embodiments described above. The processor 2001 in the network device 2000 reads the instructions in the memory 2003, so that the network device 2000 shown in FIG. 12 can perform all or part of the operations performed by the second device.

[0227] In a possible implementation, the processor 2001 is configured to receive first indication information sent by the first device, the first indication information indicating that the second device updates a credit constraint of the second device according to a first credit constraint, and the first credit constraint indicating a constraint on an allowed received data amount of the first device for updating; and update the second credit constraint of the second device according to the first credit constraint according to the first indication information, and the second credit constraint indicating a constraint on an allowed sent data amount of the second device for updating.

[0228] For details of other optional implementations, refer to the method embodiments described above, which will not be repeated here.

[0229] The network device 2000 can also correspond to the credit updating device shown in FIG. 11. Each functional module in the credit updating device is implemented by software of the network device 2000. In other words, the functional modules included in the credit updating device are generated after the processor 2001 of the network device 2000 reads the program code 2010 stored in the memory 2003.

[0230] The steps of the credit updating method shown in FIG. 6 are completed by the integrated logic circuit of hardware or the instructions in the form of software in the processor of the network device 2000. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being completed by the hardware processor, or completed by the combination of hardware and software modules in the processor. The software module can be located in the random access memory, the flash memory, the read-only memory, the programmable read-only memory, the electrically programmable read-only memory, the register, or other mature storage media in the field. The storage medium is located in the storage memory, and the processor reads the information in the storage memory and combines the hardware to complete the steps of the above method. To avoid repetition, the details will not be described here.

[0231] Referring to FIG. 13, FIG. 13 shows a structural diagram of a network device 2100 according to another example embodiment of the present application. The network device 2100 shown in FIG. 13 is configured to perform all or part of the operations involved in the credit updating method shown in FIG. 6. The network device 2100 can be a switch, a router, or the like, and can be implemented by a general bus architecture.

[0232] As shown in FIG. 13, the network device 2100 includes a main control board 2110 and an interface board 2130.

[0233] The main control board 2110, also referred to as a main processing unit (MPU) or a route processor card, is configured to control and manage various components in the network device 2100, including route calculation, device management, device maintenance, and protocol processing functions. The main control board 2110 includes a central processor 2111 and a memory 2112.

[0234] The interface board 2130, also referred to as a line processing unit (LPU), a line card, or a service board, is configured to provide various service interfaces and implement data packet forwarding. The service interfaces include, but are not limited to, Ethernet interfaces, POS (Packet over SONET / SDH) interfaces, and the like. The Ethernet interface can be, for example, a Flexible Ethernet Client (FlexE Client) interface. The interface board 2130 includes a central processor 2131, a network processor 2132, a forwarding table item memory 2134, and a physical interface card (PIC) 2133.

[0235] The central processor 2131 on the interface board 2130 is configured to control and manage the interface board 2130 and communicate with the central processor 2111 on the main control board 2110.

[0236] The network processor 2132 is configured to implement the forwarding processing of the packet. The network processor 2132 can be a forwarding chip. The forwarding chip can be a network processor (NP). In some embodiments, the forwarding chip can be implemented by an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA). Specifically, the network processor 2132 is configured to forward the received packet based on a forwarding table stored in the forwarding table entry memory 2134, and if the destination address of the packet is the address of the network device 2100, the packet is sent to the CPU (such as the central processor 2131) for processing; if the destination address of the packet is not the address of the network device 2100, the next hop and the out interface corresponding to the destination address are found from the forwarding table according to the destination address, and the packet is forwarded to the out interface corresponding to the destination address. The processing of the uplink packet can include the processing of the packet entry interface and the forwarding table lookup; the processing of the downlink packet can include the forwarding table lookup, and the like. In some embodiments, the central processor can also perform the function of the forwarding chip, such as implementing software forwarding based on a general-purpose CPU, so that the interface board does not need a forwarding chip.

[0237] The physical interface card 2133 is configured to implement the interfacing function of the physical layer, and the original traffic enters the interface board 2130 through the physical interface card 2133, and the processed packet is sent out from the physical interface card 2133. The physical interface card 2133 is also called a daughter card, which can be installed on the interface board 2130 and is responsible for converting the optical and electrical signals into packets and forwarding the packets to the network processor 2132 for processing after performing the legality check. In some embodiments, the central processor 2131 can also perform the function of the network processor 2132, such as implementing software forwarding based on a general-purpose CPU, so that the physical interface card 2133 does not need a network processor 2132.

[0238] Optionally, the network device 2100 includes a plurality of interface boards, for example, the network device 2100 further includes an interface board 2140, the interface board 2140 includes a central processor 2141, a network processor 2142, a forwarding table entry memory 2144 and a physical interface card 2143. The functions and implementation manners of the components in the interface board 2140 are the same as or similar to those of the interface board 2130, and are not described herein again.

[0239] Optionally, the network device 2100 further includes a switch fabric 2120. The switch fabric 2120 can also be referred to as a switch fabric unit (SFU). In the case where the network device 2100 has multiple interface boards, the switch fabric 2120 is used to complete data exchange between the interface boards. For example, the interface board 2130 and the interface board 2140 can communicate through the switch fabric 2120.

[0240] The main control board 2110 is coupled with the interface boards. For example, the main control board 2110, the interface board 2130, the interface board 2140, and the switch fabric 2120 are connected through a system bus and a system backplane to communicate with each other. In a possible implementation, an inter-process communication (IPC) channel is established between the main control board 2110 and the interface board 2130 and the interface board 2140, and the main control board 2110 and the interface board 2130 and the interface board 2140 communicate through the IPC channel.

[0241] In logic, the network device 2100 includes a control plane and a forwarding plane. The control plane includes the main control board 2110 and the central processor 2111, and the forwarding plane includes various components that perform forwarding, such as the forwarding table entry memory 2134, the physical interface card 2133, and the network processor 2132. The control plane performs functions such as generating a forwarding table, processing signaling and protocol packets, configuring and maintaining the state of the network device, and the like. The control plane generates a forwarding table and delivers the forwarding table to the forwarding plane. In the forwarding plane, the network processor 2132 performs table lookup and forwarding on a packet received by the physical interface card 2133 based on the forwarding table delivered by the control plane. The forwarding table delivered by the control plane can be stored in the forwarding table entry memory 2134. In some embodiments, the control plane and the forwarding plane can be completely separated and not on the same network device.

[0242] It is worth mentioning that the master board can be one or more, and when there are multiple master boards, the master boards can include a primary master board and a backup master board. The interface board can be one or more, and the stronger the data processing capability of the network device, the more interface boards are provided. The physical interface card on the interface board can also be one or more. The switching network board can be none or one or more, and when there are multiple switching network boards, the switching network boards can collectively implement load sharing and redundancy. In the centralized forwarding architecture, the network device can not need the switching network board, and the interface board can undertake the processing function of the entire system. In the distributed forwarding architecture, the network device can have at least one switching network board, and the switching network board can be used to realize data exchange between multiple interface boards and provide large-capacity data exchange and processing capability. Therefore, the data access and processing capability of the network device in the distributed architecture is greater than that of the network device in the centralized architecture. Alternatively, the network device can also be in the form of only one board, that is, the functions of the switching network board and the interface board are integrated on the one board, and at this time, the central processor on the interface board and the central processor on the master board can be combined into one central processor on the one board to perform the functions of the two superimposed central processors. The data exchange and processing capability of the network device in this form is relatively low (for example, low-end switches or routers, etc.). Which architecture to use depends on the specific network deployment scenario, and no limitation is made herein.

[0243] In specific embodiments, the network device 2100 corresponds to the credit updating apparatus shown in FIG. 11. In some embodiments, the transceiver module 1101 in the credit updating apparatus shown in FIG. 11 corresponds to the physical interface card 2133 in the network device 2100, and the processing module 1102 corresponds to the central processor 2111 or the network processor 2132 in the network device 2100.

[0244] The embodiments of the present application also provide a credit updating system, which includes a first apparatus and a second apparatus. For example, the first apparatus is the network device 2000 shown in FIG. 12 or the network device 2100 shown in FIG. 13, and the second apparatus is the network device 2000 shown in FIG. 12 or the network device 2100 shown in FIG. 13. The credit updating method performed by the first apparatus and the second apparatus can refer to the related description of the embodiment shown in FIG. 6, which will not be repeated here.

[0245] The embodiments of the present application also provide a communication apparatus, which includes a transceiver, a memory and a processor. The transceiver, the memory and the processor communicate with each other through an internal connection path. The memory is used to store instructions, and the processor is used to execute the instructions stored in the memory to control the transceiver to receive a signal and control the transceiver to send a signal. When the processor executes the instructions stored in the memory, the processor executes the method required to be executed by the first apparatus or the second apparatus.

[0246] It is to be understood that the above-described processor can be a CPU, and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic components, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is to be noted that the processor can be an advanced RISC machines (ARM) architecture processor.

[0247] Further, in an alternative embodiment, the above-described memory can include a read-only memory and a random access memory, and provide instructions and data to the processor. The memory can also include a non-volatile random access memory. For example, the memory can also store device type information.

[0248] The memory can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically EPROM (EEPROM) or a flash memory. The volatile memory can be a random access memory (RAM) used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM) and direct rambus RAM (DR RAM).

[0249] The embodiment of the present application further provides a computer readable storage medium, at least one instruction is stored in the storage medium, the instruction is loaded and executed by a processor, so that the computer implements the credit updating method according to any one of the above.

[0250] The embodiment of the present application further provides a computer program (product), when the computer program is executed by a computer, the processor or the computer can execute the corresponding steps and / or processes in the above method embodiment.

[0251] The embodiment of the present application further provides a chip, comprising a processor, for calling and running the instruction stored in the memory, so that the communication device installed with the chip executes the credit updating method according to any one of the above.

[0252] The embodiment of the present application further provides another chip, comprising: an input interface, an output interface, a processor and a memory, the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is used for executing the code in the memory, when the code is executed, the processor is used for executing the credit updating method according to any one of the above.

[0253] In the above embodiment, all or part of the above embodiment can be realized by software, hardware, firmware or any combination thereof. When realized by software, all or part of the above embodiment can be realized in the form of a computer program product. The computer program product comprises one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media (such as DVD) or semiconductor media (such as solid state disk) and the like.

[0254] Those skilled in the art can understand that, in combination with the method steps and modules described in the embodiments disclosed in the present application, all or part of the steps can be implemented by software, hardware, firmware or any combination thereof. In order to clearly illustrate the interchangeability of hardware and software, the steps and components of the embodiments have been described in the above description in general terms. Whether the functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0255] Those skilled in the art can understand that all or part of the steps of the above-mentioned embodiments can be completed by hardware, or by programs instructing related hardware, which can be stored in a computer readable storage medium. The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0256] When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. As an example, the method of the embodiments of the present application can be described in the context of machine executable instructions, such as program modules executed by devices included in the target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functions of the program modules can be combined or divided among the described program modules. Machine executable instructions for program modules can be executed within local or distributed devices. In distributed devices, program modules can be located in both local and remote storage media.

[0257] The computer program code for implementing the method of the embodiments of the present application can be written in one or more programming languages. These computer program codes can be provided to the processor of a general purpose computer, a special purpose computer or other programmable data processing apparatus, so that the program codes cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented when the computer or other programmable data processing apparatus executes the program codes. The program codes can be executed entirely on the computer, partially on the computer, as a separate software package, partially on the computer and partially on a remote computer, or entirely on a remote computer or server.

[0258] In the context of the embodiments of the present application, computer program codes or related data can be carried by any appropriate carrier to enable the device, apparatus or processor to perform the various processes and operations described above. Examples of the carrier include signals, computer readable media, etc.

[0259] Examples of a signal can include electrical, optical, radio frequency, sound, or other forms of propagated signals, such as carrier waves, infrared signals, etc.

[0260] A machine-readable medium can be any tangible medium that contains or stores the program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), and a digital versatile disc (DVD), or any suitable combination of the foregoing.

[0261] It should be clearly understood that, for the sake of brevity and clarity, detailed working processes of the system, device and module described above can refer to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0262] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic, and the division of the modules is merely a logical function division, and there can be another division manner in actual implementation, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling or direct coupling or communication connection between the modules can be indirect coupling or communication connection through some interfaces, devices or modules, and can also be electrical, mechanical or other forms of connection.

[0263] The modules illustrated as separate components can or can not be physically separate, and the components illustrated as modules can or can not be physical modules, i.e., can be located in one place, or can be distributed to a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0264] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically, or two or more modules can be integrated into one module. The above integrated module can be realized in the form of hardware or in the form of a software functional module.

[0265] The integrated module, if implemented in the form of a software function module and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0266] The terms "first", "second", and the like in the present application are used to distinguish between items or similar items having substantially the same function and action. It should be understood that there is no logical or chronological dependency between "first", "second", and "nth", and the number and execution order are not limited. It should also be understood that although the following description uses the terms first, second, and the like to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of various examples, a first image can be referred to as a second image, and similarly, a second image can be referred to as a first image. The first image and the second image can both be images, and in some cases, can be separate and distinct images.

[0267] It should also be understood that in various embodiments of the present application, the size of the serial number of each process does not mean the order of execution, and the execution order of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0268] The term "at least one" in the present application means one or more, and the term "multiple" in the present application means two or more, for example, multiple second messages refer to two or more second messages. The terms "system" and "network" are often used interchangeably in this document.

[0269] It should be understood that the terms used in the description of various described examples herein are only for the purpose of describing specific examples and are not intended to be limiting. As used in the description of various described examples and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0270] It should also be understood that, as used in this specification, the terms "comprises", "comprising", "includes", "including", "with" or "comprising", specifies the presence of stated features, integers, steps, operations, elements, and / or components but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0271] It should also be understood that the terms "comprises", "comprising", "includes", "including", "with" or "comprising", specifies the presence of stated features, integers, steps, operations, elements, and / or components but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0272] It should also be understood that the terms "if' and "when" can be construed to mean "upon" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" can be construed to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]", depending on the context.

[0273] It should be understood that a determination of B according to A does not mean that B is determined only according to A, but B can also be determined according to A and / or other information.

[0274] It should also be understood that the terms "one embodiment", "an embodiment", "one possible implementation", as used in the specification are intended to mean that a particular feature, structure, or characteristic described in connection with the embodiment or implementation is included in at least one implementation of the application. Thus, appearances of the phrases "in one embodiment" or "in an embodiment", "one possible implementation", as well as variations thereof, in various places throughout the specification are not necessarily intended to refer to the same embodiment or implementation, unless otherwise indicated. Furthermore, it is appreciated that the particular features, structures, or characteristics can be combined in any suitable manner in one or more implementations.

[0275] The above description is only optional embodiments of the application, and is not used to limit the application, any modification, equivalent replacement, improvement, etc. made within the principles of the application should be included in the protection scope of the application.

Claims

1. A credit update method characterized by comprising: The method comprises: The first device determines a first credit constraint of the first device, the first credit constraint indicating a constraint on an amount of data allowed to be received by the first device for updating; The first device sends first indication information to a second device, the first indication information indicating that the second device updates a credit constraint of the second device according to the first credit constraint.

2. The method of claim 1, wherein, The first credit constraint comprises a total credit constraint of a plurality of first virtual queues on the first device, the total credit constraint of the plurality of first virtual queues indicating a constraint on an amount of data allowed to be received by the plurality of first virtual queues for updating; The first indication information indicates that the second device updates a total credit constraint of a plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues, the plurality of first virtual queues corresponding to the plurality of second virtual queues.

3. The method of claim 2, wherein, The first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues.

4. The method of claim 2, wherein, The method further comprises: The first device sends second indication information to the second device, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the total credit constraint of the plurality of second virtual queues.

5. The method of claim 1, wherein, The first credit constraint comprises a credit constraint corresponding to a first virtual queue on the first device, the credit constraint corresponding to the first virtual queue indicating a constraint on an amount of data allowed to be received by the first virtual queue for updating; The first indication information indicates that the second device updates a credit constraint corresponding to a second virtual queue on the second device according to the credit constraint corresponding to the first virtual queue, the first virtual queue corresponding to the second virtual queue.

6. The method of claim 5, wherein, The first indication information further indicates that the credit constraint of the second device is switched from a total credit constraint of a plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

7. The method of claim 5, wherein, The method further comprises: The first device sends third indication information to the second device, the third indication information indicating that the credit constraint of the second device is switched from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

8. The method according to any one of claims 5 to 7, characterized in that, The first credit constraint further comprises a total credit constraint of a plurality of first virtual queues on the first device, the total credit constraint of the plurality of first virtual queues indicating a constraint on an amount of data allowed to be received by the plurality of first virtual queues for updating; and the first indication information further indicates that the second device updates a total credit constraint of a plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues, the plurality of first virtual queues corresponding to the plurality of second virtual queues.

9. The method according to any one of claims 2-4, 8, characterized in that, The method further comprises: The first device sends the total credit constraint of the plurality of first virtual queues to the second device.

10. The method according to any one of claims 5 to 7, characterized in that, The method further comprises: The first device sends the credit constraint corresponding to the first virtual queue to the second device.

11. The method according to any one of claims 3, 4, 6 and 7, characterized in that, The method further comprises: The first device receives the response of the second device to the credit mode switching.

12. The method of claim 3 or 4, wherein, The method further comprises: Before receiving the response of the second device to the credit mode switching, the first device switches the first credit constraint from the credit constraint corresponding to the first virtual queue on the first device to the overall credit constraint of the plurality of first virtual queues. Alternatively, after receiving the response of the second device to the credit mode switching, the first device switches the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device.

13. The method of claim 6 or 7, wherein, The method further comprises: Before receiving the response of the second device to the credit mode switching, the first device switches the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device. Alternatively, after receiving the response of the second device to the credit mode switching, the first device switches the first credit constraint from the overall credit constraint of the plurality of first virtual queues to the credit constraint corresponding to the first virtual queue on the first device.

14. The method according to any one of claims 1 to 13, characterized in that, The method further comprises: The first device receives the response of the second device to the credit constraint update.

15. The method of claim 14, wherein, Before receiving the response of the second device to the credit constraint update, the method further comprises: The first device receives data according to the buffer space corresponding to the first credit constraint; Alternatively, after receiving the response of the second device to the credit constraint update, the method further comprises: The first device receives data according to the buffer space corresponding to the first credit constraint.

16. The method of any one of claims 1-15, wherein, The first device sends first indication information to the second device, comprising: The first device sends a link layer discovery protocol (LLDP) message to the second device, and the LLDP message carries the first indication information. Alternatively, the first device sends an ordered set (O) code to the second device, and the O code carries the first indication information.

17. A credit update method characterized by comprising: The method comprises: The second device receives first indication information sent by the first device, and the first indication information indicates that the second device updates a credit constraint of the second device according to a first credit constraint, and the first credit constraint indicates a constraint of an updated allowed received data amount of the first device; The second device updates a second credit constraint of the second device according to the first credit constraint according to the first indication information, and the second credit constraint indicates a constraint of an updated allowed sent data amount of the second device.

18. The method of claim 17, wherein, The first indication information indicates that the second device updates an overall credit constraint of a plurality of second virtual queues on the second device according to an overall credit constraint of a plurality of first virtual queues on the first device, and the plurality of second virtual queues correspond to the plurality of first virtual queues; The second device updates the second credit constraint of the second device according to the first credit constraint according to the first indication information, comprising: The second device updates, according to the first indication information, an overall credit constraint of a plurality of second virtual queues on the second device according to an overall credit constraint of the plurality of first virtual queues, the overall credit constraint of the plurality of second virtual queues indicating a constraint on an amount of data allowed to be sent by the plurality of second virtual queues.

19. The method of claim 18, wherein, The first indication information further indicates that the credit constraint of the second device is switched from a credit constraint corresponding to a second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues, and the method further comprises: The second device switches, according to the first indication information, the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues.

20. The method of claim 18, wherein, The method further comprises: The second device receives second indication information sent by the second device, the second indication information indicating that the credit constraint of the second device is switched from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues; The second device switches, according to the second indication information, the second credit constraint from the credit constraint corresponding to the second virtual queue on the second device to the overall credit constraint of the plurality of second virtual queues.

21. The method of any one of claims 18-20, wherein, The method further comprises: The second device updates, according to the updated overall credit constraint of the plurality of second virtual queues, a credit constraint of any second virtual queue in the plurality of second virtual queues, the credit constraint of the any second virtual queue indicating a constraint on an amount of data allowed to be sent by the any second virtual queue.

22. The method of claim 17, wherein, The first indication information indicates that the second device updates a credit constraint corresponding to a second virtual queue on the second device according to a credit constraint corresponding to a first virtual queue on the first device, the first virtual queue corresponding to the second virtual queue; The second device updates, according to the first indication information, a second credit constraint of the second device according to the first credit constraint, comprising: The second device updates, according to the first indication information, a credit constraint corresponding to the second virtual queue according to a credit constraint corresponding to the first virtual queue, the credit constraint corresponding to the second virtual queue indicating a constraint on an amount of data allowed to be sent by the second virtual queue.

23. The method of claim 22, wherein, The first indication information further indicates that the credit constraint of the second device is switched from an overall credit constraint of a plurality of second virtual queues on the second device to a credit constraint corresponding to the second virtual queue, and the method further comprises: The second device switches, according to the first indication information, the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue.

24. The method of claim 22, wherein, The method further comprises: The second device receives third indication information sent by the second device, the third indication information indicating that the credit constraint of the second device is switched from an overall credit constraint of a plurality of second virtual queues on the second device to a credit constraint corresponding to the second virtual queue; The second device switches, according to the third indication information, the second credit constraint from the overall credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue. The second device switches the second credit constraint from the total credit constraint of the plurality of second virtual queues on the second device to the credit constraint corresponding to the second virtual queue according to the third indication information.

25. The method of any one of claims 22-24, wherein, The first indication information further indicates that the second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues on the first device, the plurality of first virtual queues corresponding to the plurality of second virtual queues; The second device updates the second credit constraint of the second device according to the first credit constraint according to the first indication information, and the method further includes: The second device updates the total credit constraint of the plurality of second virtual queues on the second device according to the total credit constraint of the plurality of first virtual queues according to the first indication information, the total credit constraint of the plurality of second virtual queues indicating the constraint of the updated allowed sending data amount of the plurality of second virtual queues.

26. The method of any one of claims 18-21, 25, wherein, Before the total credit constraint of the plurality of second virtual queues on the second device is updated according to the total credit constraint of the plurality of first virtual queues, the method further includes: The second device receives the total credit constraint of the plurality of first virtual queues sent by the first device.

27. The method of any one of claims 22-25, wherein, Before the credit constraint corresponding to the second virtual queue is updated according to the credit constraint corresponding to the first virtual queue, the method further includes: The second device receives the credit constraint corresponding to the first virtual queue sent by the first device.

28. The method of any one of claims 19, 20, 23, and 24, wherein, The method further includes: The second device sends a response of the credit configuration mode switching to the first device.

29. The method of any one of claims 17-28, wherein, The method further includes: The second device sends a response of the credit constraint update to the first device.

30. The method of any one of claims 17-29, wherein, The method further includes: The second device sends a data stream to the first device while updating the second credit constraint.

31. The method of any one of claims 1 to 30, wherein, The first device and the second device are directly connected upstream and downstream devices, or are non-directly connected upstream and downstream devices, or are end point devices at two ends of a network.

32. A credit updating apparatus characterized by comprising: The device includes a transceiver module and a processing module; The transceiver module is configured to perform the receiving and / or sending related operations performed by the first device in the method of any one of claims 1-16 and 31, and the processing module is configured to perform other operations in addition to the receiving and / or sending related operations performed by the first device in the method of any one of claims 1-16 and 31. Alternatively, the transceiver module is configured to perform the receiving and / or sending related operations performed by the second device in the method of any one of claims 17-31, and the processing module is configured to perform other operations in addition to the receiving and / or sending related operations performed by the second device in the method of any one of claims 17-31.

33. A network device, comprising: The network device includes a processor configured to load and execute at least one program instruction or code to enable the network device to implement the credit update method of any one of claims 1-31.

34. A credit updating system, characterized by The credit update system includes a first device and a second device; The first device is configured to perform the method of any one of claims 1-17, 31, and the second device is configured to perform the method of any one of claims 17-31.

35. A computer readable storage medium, characterized in that, The computer storage medium stores at least one instruction, which is loaded and executed by the processor, so that the computer implements the credit updating method of any one of claims 1-31.

36. A computer program product, characterised in that, The computer program product comprises computer program code, which is loaded and executed by the computer, so that the computer implements the credit updating method of any one of claims 1-31.

37. A chip, characterized by The chip comprises a processor, which is configured to call and run instructions stored in a memory, so that a communication device installed with the chip implements the credit updating method of any one of claims 1-31.

Images