Machine room network bandwidth scheduling method and device, electronic equipment and storage medium

Abstract

The application provides a machine room network bandwidth scheduling method and device, electronic equipment and storage medium, and belongs to the technical field of network bandwidth scheduling. The method comprises the following steps: based on a tenant identifier and a priority, mapping an inbound data packet to a first queue or a second queue and performing normal scheduling; when the current depth of any second queue is greater than zero and the counter thereof reaches a preset stasis threshold value, triggering an interruption and extracting a corresponding victim tenant identifier, and positioning a first queue with an out-of-queue rate exceeding a preset rate threshold value as an encroaching queue; when the victim tenant identifier is inconsistent with an encroaching tenant identifier, obtaining the data length of the first data packet in the second queue triggering the interruption; deducting the out-of-queue quota of the encroaching queue, resetting the counter thereof and resuming normal scheduling. The machine room network bandwidth scheduling method and device, electronic equipment and storage medium provided by the application can accurately replace a single packet level token, and completely block a retransmission storm caused by cross-tenant control frame silence starvation.

Description

Technical Field

[0001] This application belongs to the technical field of network bandwidth scheduling, and more specifically, it relates to methods and devices for scheduling network bandwidth in computer rooms, electronic devices, and storage media. Background Technology

[0002] In a multi-tenant shared data center network communication environment, the underlying switching equipment needs to simultaneously handle large-scale data streams from different tenants and different service types. To meet diverse real-time transmission requirements, data center networks typically employ priority-based bandwidth scheduling mechanisms to ensure that data packets for core services or highly real-time sensitive services are prioritized for forwarding. With the development of cloud computing and distributed architectures, data center networks not only require efficient utilization of overall bandwidth but also need to maintain the stability of network connections and the continuity of protocol interactions between tenants under extreme traffic bursts. Under traditional strict priority or weight-based scheduling strategies, how to rationally allocate physical port dequeue resources and avoid resource crowding between queues of different priorities has always been a core application background of concern in the field of network bandwidth scheduling.

[0003] To address the issue of bandwidth allocation and utilization optimization, existing technologies have proposed several solutions, such as the invention patent with authorization announcement number CN113938435B entitled "Data Transmission Method, Apparatus, Electronic Device, Storage Medium, and Program Product." This prior art discloses a data transmission method based on priority to determine the corresponding token bucket set. Specifically, the logic involves determining the priority of the data to be transmitted and accordingly determining its corresponding token bucket set. This set contains unallocated token buckets with priorities lower than or equal to the priority of the data to be transmitted. Subsequently, the data to be transmitted obtains tokens from this set and performs data transmission. Simultaneously, the system continuously adds tokens to the unfilled token buckets through a token generator. This design allows high-priority data to obtain tokens from multiple token buckets, increasing the chances of obtaining tokens. This satisfies the priority transmission requirements of high-priority services while ensuring that the total bandwidth is fully utilized even in a single service scenario, effectively improving the utilization rate of the total network bandwidth.

[0004] However, in special scenarios involving multi-tenant sharing and highly complex network traffic, the aforementioned mechanism based on macro-level token pool sharing and high-priority backward compatibility for token acquisition is highly susceptible to cross-tenant silent starvation of underlying control frames, ultimately leading to global network congestion and collapse. Specifically, when a tenant's core business generates drastic micro-burst traffic within a very short period, these massive high-priority data packets not only rapidly deplete their own corresponding high-priority token buckets but also, by virtue of their authority to acquire tokens downwards, instantly plunder and squeeze out the remaining tokens in low-priority token buckets. At this time, if another tenant's queue is waiting to send critical control frames to maintain the survival of the underlying network protocol, these low-priority queues will completely lose the opportunity to acquire even a very small number of transmission tokens because their bound token buckets are continuously emptied by cross-tenant high-priority burst traffic. Existing technologies only consider macro-level throughput and overall rate proportions for token scheduling, completely ignoring the rigid temporal correlation between the physical stagnation state of queues and the underlying network protocol at the micro-timescale. Once the stagnation time of the underlying control frame caused by the physical squeezing of cross-tenant tokens exceeds the minimum retransmission timeout of the protocol, the sending end will misjudge the network as experiencing severe packet loss based on the underlying protocol logic, and thus instinctively trigger a massive number of retransmission packets. This retransmission storm that erupts at the critical point will quickly backfire on the network, exhausting the global shared buffer of the switch. Ultimately, it will not only fail to guarantee the transmission of high-priority services, but will also cause a precipitous drop in the overall network throughput of the data center, seriously undermining the fairness and stability of the network in a multi-tenant environment. Summary of the Invention

[0005] The purpose of this application is to provide a method and device for scheduling network bandwidth in a data center, electronic equipment, and storage media, which can completely block the retransmission storm caused by the silent starvation of cross-tenant control frames from the source through precise replacement of single-packet-level tokens.

[0006] A first aspect of this application provides a data center network bandwidth scheduling method, which includes: Based on the tenant identifier and priority of the inbound data packet, the inbound data packet is mapped to the first queue or the second queue with a lower priority than the first queue and regular scheduling is performed; Monitor the current depth and dequeue rate of the first and second queues, and record counters for consecutive periods in which no data packets are dequeued; When the current depth of any of the second queues is greater than zero and its counter reaches a preset stagnation threshold, an interruption is triggered and the corresponding victim tenant identifier is extracted. In response to the interruption, the normal scheduling is paused, the first queue whose dequeue rate exceeds a preset rate threshold is identified as an intrusion queue, and the corresponding intrusion tenant identifier is extracted. When the victim tenant identifier does not match the intruding tenant identifier, obtain the data length of the first data packet in the second queue that triggered the interruption; The quota compensation equal to the data length is deducted from the dequeue quota of the encroaching queue and applied to the second queue that triggered the interruption, driving it to output the first data packet, clearing its counter, and restoring the normal scheduling.

[0007] In one possible implementation, the monitoring of the current depth of the first queue and the second queue, the dequeue rate, and the counter that records consecutive periods during which no data packets are dequeued includes: Configure a state machine driven by a preset clock cycle; Within each preset clock cycle, the current depth of the first queue and the second queue is updated synchronously through the state machine, and the total number of dequeued bytes of the first queue and the second queue is accumulated synchronously. At each preset statistical period, based on the total number of dequeued bytes accumulated within the statistical period, the state machine calculates and updates the dequeue rates of the first queue and the second queue. When no data packet is dequeued in the second queue within any preset clock cycle, the state machine controls the corresponding counter to perform an accumulation operation.

[0008] In another possible implementation, the method for determining the preset stagnation threshold includes: Obtain the minimum retransmission timeout of the network protocol corresponding to the inbound data packet; The minimum retransmission timeout is multiplied by a preset proportional coefficient to generate the critical stall time; The ratio of the critical pause time to the preset clock period is determined as the preset pause threshold.

[0009] In another possible implementation, the step of deducting a quota compensation equal to the data length from the dequeue quota of the encroaching queue and transferring it to the second queue that triggers the interrupt, thereby driving it to output the first data packet, includes: Extract the byte length of the first data packet as the data length; Determine the hardware token buckets that correspond to the encroachment queue and the second queue that triggered the interrupt, respectively, and are used to manage the dequeue quota; The number of tokens equal to the data length is deducted from the hardware token bucket corresponding to the encroachment queue; The deducted tokens are used as compensation to inject the quota into the hardware token bucket corresponding to the second queue that triggered the interrupt, driving the second queue that triggered the interrupt to output only the first data packet to complete the single packet dequeue.

[0010] In another possible implementation, during the process of deducting a number of tokens equal to the data length and restoring the normal schedule: When the number of available tokens in the hardware token bucket corresponding to the encroachment queue is less than the data length, the hardware token bucket is authorized to enter a negative value state and the overdraft limit is recorded in order to perform deduction and quota compensation injection. After the second queue that triggered the interrupt completes the dequeueing of the single packet, the corresponding counter is cleared and reset. Resume the normal scheduling and use the newly added tokens in the encroachment queue to offset the overdraft limit in the subsequent preset clock cycle.

[0011] In another possible implementation, after the steps of suspending the regular scheduling in response to the interruption, identifying the first queue whose dequeue rate exceeds a preset rate threshold as an intruding queue, and extracting the corresponding intruding tenant identifier, the method further includes: When the victim tenant identifier matches the intruding tenant identifier, it is determined to be spontaneous congestion within a single tenant's internal business. Clear all currently buffered data packets in the second queue that triggered the interrupt, and generate an explicit congestion notification message at the tail of the second queue that triggered the interrupt; The explicit congestion notification message is sent back to the source device that sent the inbound data packet to instruct the source device to reduce the transmission rate, and then the corresponding counter is cleared and the normal scheduling is restored.

[0012] In another possible implementation, the steps of clearing all currently buffered data packets in the second queue that triggered the interrupt, generating an explicit congestion notification message at the tail of the second queue that triggered the interrupt, and feeding back the explicit congestion notification message to the source device that sent the inbound data packet include: Before clearing all currently cached data packets in the second queue that triggered the interrupt, the packet headers are parsed to extract the corresponding source device address; Based on the source device address, a reverse congestion notification control message is constructed as the explicit congestion notification message; After clearing all currently buffered data packets in the second queue that triggered the interrupt, the explicit congestion notification message is generated at the tail of the second queue that triggered the interrupt. The explicit congestion notification message is fed back to the source device to drive the source device to perform transmission rate attenuation according to a preset rate reduction ratio based on the explicit congestion notification message.

[0013] A second aspect of this application provides a data center network bandwidth scheduling device, the device comprising: The status maintenance module is configured to map the inbound data packets to a first queue or a second queue with a lower priority than the first queue based on the tenant identifier and priority of the inbound data packets and perform regular scheduling, as well as monitor the current depth, dequeue rate and counters of the first queue and the second queue and record consecutive periods in which no data packets have been dequeued. The critical detection module is configured to trigger an interrupt and extract the corresponding victim tenant identifier when the current depth of any second queue is greater than zero and its counter reaches a preset stagnation threshold. The logic comparison module is configured to pause the regular scheduling in response to the interruption, locate the first queue whose dequeue rate exceeds a preset rate threshold as an intrusion queue, extract the corresponding intrusion tenant identifier, and perform a consistency logic comparison between the victim tenant identifier and the intrusion tenant identifier. The control recovery module is configured to, when the victim tenant identifier is inconsistent with the intruding tenant identifier, obtain the data length of the first data packet in the second queue that triggered the interruption, deduct a quota compensation equal to the data length from the dequeue quota of the intruding queue and apply it to the second queue that triggered the interruption, so as to drive it to output the first data packet, and then clear its counter and restore the normal scheduling.

[0014] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described data center network bandwidth scheduling method.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described data center network bandwidth scheduling method.

[0016] The beneficial effects of the data center network bandwidth scheduling method and apparatus, electronic equipment, and storage medium provided in this application embodiment are as follows: 1. This application monitors the continuous stagnation time of low-priority queues in real time and triggers a hardware interrupt when the critical threshold corresponding to the minimum retransmission timeout time of the network protocol is reached. It accurately identifies the silent starvation state of control frames caused by cross-tenant high-priority traffic encroachment, and uses single-packet-level token replacement to compensate the first data packet of the victim queue from the quota of the encroaching queue. This completely blocks the global retransmission storm caused by control frame timeout retransmission from the source, effectively avoiding the precipitous drop in network throughput and congestion collapse in the data center.

[0017] 2. This application adopts a nanosecond-level queue status monitoring and single-packet-level precise token replacement mechanism based on a hardware state machine. It only needs to deduct a token equal to the length of the first data packet of the victim queue from the outgoing quota of the encroaching queue for compensation, drive the victim queue to output the first data packet, and use it as a key control frame. This achieves minimal intervention in network scheduling behavior, ensuring the continuity of tenant underlying protocol connections while avoiding continuous disturbance to the overall forwarding capability of physical ports and the normal services of other tenants.

[0018] 3. This application intelligently distinguishes between two scenarios: cross-tenant bandwidth encroachment and single-tenant internal self-congestion, by comparing tenant identifier consistency. For cross-tenant scenarios, token compensation is used to accurately resolve resource crowding. For single-tenant internal self-congestion scenarios, the source end is driven to slow down by clearing the queue and sending an explicit congestion notification message. This not only completely solves the problem of cross-tenant control frame starvation, but also quickly suppresses traffic when single-tenant experiences sudden congestion, thus balancing bandwidth fairness in multi-tenant environments with the stability of core business transmission. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating a data center network bandwidth scheduling method provided in an embodiment of this application; Figure 2 This is a structural block diagram of a data center network bandwidth scheduling device provided in an embodiment of this application; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application.

[0021] Reference numerals: 300, electronic device; 301, processor; 302, input device; 303, output device; 304, memory; 305, communication bus. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It is understood that in the embodiments of this application, data such as user information are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0024] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in sequences other than those illustrated or described herein.

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following description will be provided in conjunction with the accompanying drawings and specific embodiments.

[0026] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a data center network bandwidth scheduling method according to an embodiment of this application. The data center network bandwidth scheduling method provided in this embodiment can be executed by an electronic device, and the method may include: S1 inbound packet queue mapping and regular scheduling execution.

[0027] S11 inbound data packet parsing and identifier extraction.

[0028] The physical ports of the hardware switching equipment receive inbound data packets. The hardware switching equipment performs linear parsing of the Ethernet and IP headers of the inbound data packets. From the specified fields in the headers, the hardware switching equipment extracts two core identification pieces of information. The first core identification piece is the tenant identifier. The tenant identifier is a fixed-length binary identity code that uniquely identifies the tenant to which the data packet belongs. By default, the tenant identifier is carried in the VLAN tag extension field of the header; if the packet does not have a VLAN tag extension field, the source IP address segment in the IP header is used as the tenant identifier index to distinguish data flows from different tenants in a multi-tenant shared environment, avoiding confusion in cross-tenant resource scheduling. The second core identification piece is the priority tag. The priority tag is an identifier that marks the real-time level of the data packet service. By default, the priority tag is carried in the DSCP field of the IP header; if the packet does not have a DSCP field, it is marked according to the default priority rules pre-configured on the physical port. The hardware switching equipment is pre-configured with two levels of scheduling priorities: high priority and low priority. High priority is used to carry data streams for tenant's core business and low-latency sensitive business; low priority is used to carry data streams for tenant's underlying network protocol control frames and non-real-time business.

[0029] S12 packet queue mapping and enqueue buffer.

[0030] The hardware switching device configures two independent hardware queues for each tenant under each physical port. These two hardware queues are designated as Queue 1 and Queue 2. Queue 1 corresponds to high-priority scheduling permissions, and Queue 2 corresponds to low-priority scheduling permissions. The scheduling priority of Queue 1 is always higher than that of Queue 2. The hardware queues utilize the on-chip static random access memory (SRAM) of the hardware switching device for caching. Each hardware queue is configured with an independent maximum cache depth, which is configured in bytes.

[0031] The hardware switching equipment configures a unique hardware token bucket for each first queue and each second queue, each bound to a corresponding unit. The hardware token bucket manages the dequeue quota for its corresponding queue. The token generation rate of the token bucket is consistent with the preset rate threshold of the corresponding queue. The unit of the token is bytes (B), identical to the unit of data packet length, ensuring uniformity of measurement. During hardware token bucket initialization, the token generation rate is configured to match the preset rate threshold of the queue. The token bucket capacity is set to the number of bytes corresponding to the maximum buffer depth of the queue, and the initial number of tokens is set to 50% of the token bucket capacity. Specifically, the preset rate threshold for the first queue is the committed information rate corresponding to that queue, i.e., the maximum guaranteed bandwidth rate for high-priority services agreed upon by the tenant and the data center in the Service Level Agreement (SLA), in bits per second (bit / s). When converting to bytes, divide by 8. The preset rate threshold for the second queue is the maximum available bandwidth rate for low-priority services agreed upon by the tenant and the data center in the SLA, also in bits per second (bit / s). When converting to bytes, divide by 8.

[0032] The hardware switching device uses the tenant identifier extracted in step S11 as an index to match the two sets of hardware queues corresponding to the target tenant. Based on the priority tag extracted in step S11, the hardware switching device completes the target queue matching for data packets. The hardware switching device maps inbound data packets carrying high-priority tags to the first queue of the corresponding tenant; and maps inbound data packets carrying low-priority tags to the second queue of the corresponding tenant. After completing the mapping, the hardware switching device writes the data packets to the hardware buffer of the corresponding queue, completing the enqueue operation. Through the dual mapping rule of tenant identifier and priority tag, the hardware switching device achieves hardware-level isolation of multi-tenant data streams with different priorities, ensuring that the tenant affiliation and priority level of all data streams can be accurately traced during the scheduling process.

[0033] The S13 routine scheduling logic continues to be executed.

[0034] After the data packets are enqueued and buffered, the hardware switching equipment continues to execute routine scheduling logic within each preset clock cycle. The preset clock cycle adopts the 1ns clock cycle commonly used by data center hardware switching equipment, and the corresponding clock frequency is 1GHz. The preset clock cycle is completely synchronized with the data packet forwarding clock of the hardware switching equipment.

[0035] The conventional scheduling logic employs a strict priority scheduling mechanism, combined with hardware token buckets for dequeue permission verification. Within a single scheduling cycle, the hardware switch prioritizes scheduling data packets buffered in all first queues under the current physical port. A round-robin scheduling method is used among multi-tenant queues of the same priority to ensure fairness among tenants. Before a data packet is dequeued, it consumes tokens equal to the packet's byte length from the corresponding queue's hardware token bucket. If the number of tokens is insufficient, the queue suspends dequeue forwarding for the current scheduling cycle. The hardware switch only schedules data packets buffered in the second queue when all first queues under the current physical port have no buffered data packets to be forwarded, or when all first queues have no available dequeue tokens. The dequeue forwarding of the second queue also follows the token consumption rules and the same-priority round-robin scheduling mechanism. Through a priority-based forwarding mechanism and token bucket bandwidth control, the conventional scheduling logic ensures the real-time transmission of tenants' high-priority core services, matching the low-latency transmission requirements of the data center's core services.

[0036] Real-time hardware-level monitoring of S2 queue status and dequeue behavior.

[0037] S21 clock-driven hardware state machine configuration.

[0038] Based on all the first and second queues mapped and configured in step S1, the hardware switching device configures an independent hardware state machine for each queue. The hardware state machine is implemented using the arithmetic logic unit and independent register resources within the hardware switching device. These independent register resources are divided into dedicated status registers and count registers. The status register stores the queue's real-time operating parameters, while the count register stores the queue's continuous periodic statistical values. The hardware state machine is driven by a predetermined preset clock cycle from step S1. This preset clock cycle uses the 1ns clock cycle commonly used in data center hardware switching devices, corresponding to a clock frequency of 1GHz. This clock cycle is completely synchronized with the packet forwarding clock used in step S1. The hardware state machine triggers a full state refresh operation within each preset clock cycle, ensuring complete timing alignment between queue status monitoring and packet forwarding behavior, avoiding the monitoring lag problem caused by software statistics in existing technologies.

[0039] The core status parameters of the S22 queue are periodically updated synchronously.

[0040] Within each preset clock cycle, the hardware state machine corresponding to each queue synchronously updates two core state parameters of the queue. Both parameter updates are based on the packet enqueueing and dequeueing actions performed in step S1. The first core state parameter is the current depth, which is the total byte length of all packets to be forwarded cached by the corresponding queue within the current clock cycle. When a queue completes a packet enqueueing operation, the hardware state machine increments the byte length of the enqueued packet by the current depth value; when a queue completes a packet dequeueing operation, the hardware state machine decrements the byte length of the dequeued packet by the current depth value, thus achieving real-time updating of the current depth.

[0041] The second core status parameter is the dequeue rate, which is the total number of bytes of data packets forwarded by the corresponding queue within a unit statistical period. The statistical period is fixed at 1ms, corresponding to 1,000,000 preset clock cycles. This statistical period adapts to the bursty characteristics of data center network traffic and can accurately reflect the actual bandwidth usage of the queue. Within each preset clock cycle, the hardware state machine synchronously accumulates the total number of dequeued bytes of the queue within that cycle. Every 1ms statistical cycle, the hardware state machine completes a full calculation and update of the dequeue rate using the formula "total number of dequeued bytes in the statistical period × 8 / statistical period duration". The updated dequeue rate is in bits per second (bit / s), which is completely consistent with the unit of the queue's preset rate threshold, ensuring unit matching and avoiding errors in threshold judgment.

[0042] Counting statistics for zero dequeue cycles in queue S23.

[0043] Each second queue configured in step S1 is equipped with an independent counter in the hardware state machine. The initial value of the counter is 0, which is used to record the number of consecutive preset clock cycles in which no data packet dequeueing occurs in the corresponding second queue. Within each preset clock cycle, after the hardware state machine completes the state parameter update in step S22, it immediately judges the dequeueing behavior of the corresponding second queue. If no data packet dequeueing occurs in the second queue within the current preset clock cycle, the hardware state machine controls the corresponding counter to perform an accumulation operation, and the counter value is increased by 1; if any data packet dequeueing occurs in the second queue within the current preset clock cycle, the hardware state machine controls the corresponding counter to perform a reset operation, and the counter value is reset to 0. Through cycle-by-cycle counting statistics, the hardware state machine can accurately capture the continuous stagnation state of the second queue, providing nanosecond-level timing basis for subsequent critical state detection, and making up for the deficiency of existing technologies that cannot detect microscopic queue stagnation.

[0044] Detection and interruption triggering of the silent starvation critical state of the S3 low-priority queue.

[0045] Calibration and configuration of the S31 anti-starvation stagnation threshold.

[0046] Based on the preset clock cycle configured in step S2 and the counter corresponding to the second queue, the hardware switching device pre-configures a preset stagnation threshold. The stagnation threshold is the upper limit of the counter value that triggers a critical interrupt. Its calibration process is completely aligned with the counting rules of step S2 and is divided into three continuously executed stages.

[0047] In the first step, the hardware switching equipment obtains the minimum retransmission timeout for the network protocol corresponding to the inbound data packet. This solution is designed for the TCP / IP protocol suite. In the data center intranet environment, the general configuration value of the minimum retransmission timeout (RTO) for the Transmission Control Protocol (TCP) is 10ms. This value is the minimum timeout boundary to ensure the normal operation of the Transmission Control Protocol in the data center network architecture, and it is also the critical time point for the underlying protocol to trigger the retransmission mechanism. For connectionless protocols such as UDP, the minimum retransmission timeout adopts the minimum value of the corresponding protocol's session keep-alive timeout.

[0048] In the second stage, the hardware switching equipment multiplies the minimum retransmission timeout by a preset proportional coefficient to generate a critical pause time. The preset proportional coefficient is fixed at 0.8, corresponding to a critical pause time of 8ms. This preset proportional coefficient setting reserves a 20% minimum retransmission timeout window, ensuring that subsequent interrupt handling and scheduling interventions can be completed before the protocol retransmission mechanism is triggered. It also avoids frequent false interruptions caused by setting the threshold too low, thus balancing the timeliness of intervention with the stability of the forwarding service.

[0049] In the third step, the hardware switching device determines the preset stall threshold as the ratio of the critical stall time to the predetermined preset clock period in step S2. The specific calculation process is as follows: the critical stall time of 8ms is first converted to 8,000,000ns, then the ratio is calculated with the preset clock period of 1ns, ultimately yielding the preset stall threshold of 8,000,000ns. This threshold perfectly matches the cycle-by-cycle accumulation rule of the counter in step S2 and can be directly used as the triggering criterion for the counter.

[0050] Hardware-level parallel logic judgment of S32 critical state.

[0051] Within each preset clock cycle, after the hardware switching device completes the queue status parameter update and counter statistics operations in step S2, it performs parallel critical state logic judgments on all second queues under the physical port through built-in hardware logic gates. The critical state logic judgment simultaneously verifies two parallel judgment conditions, and the parameters of both conditions are directly taken from the synchronous update results of step S2, ensuring the real-time performance and accuracy of the judgment.

[0052] The first condition is that the current depth of the second queue is greater than zero. This parameter is directly taken from the queue status data updated synchronously in step S22. It is used to confirm that there are buffered data packets to be forwarded in the second queue, excluding invalid statistical scenarios where the queue is empty, and avoiding meaningless interruption triggers. The second condition is that the counter value corresponding to the second queue reaches a preset stagnation threshold. This counter value is directly taken from the statistical results updated periodically in step S23. It is used to confirm that the data packets to be forwarded in the second queue have not been dequeued for 8,000,000 consecutive preset clock cycles, and the corresponding stagnation time has reached 8ms, which is about to trigger the timeout retransmission mechanism of the transmission control protocol.

[0053] The hardware switching device determines that the second queue has entered a silent starvation critical state only when both judgment conditions are met simultaneously. Through hardware-level parallel judgment, the hardware switching device can complete the critical state verification of all second queues within a single clock cycle, without causing additional performance loss to the regular packet forwarding process, and also makes up for the latency defects caused by software statistical judgment in the prior art.

[0054] S33 critical interrupt triggering and victim tenant identifier extraction.

[0055] When the hardware switching device determines that any second queue has entered a silent starvation critical state, it immediately triggers a hardware-level silent starvation critical interrupt. Simultaneously, the hardware switching device locks the second queue that has entered the critical state, marking it as a critical queue. The locking operation only blocks dequeue scheduling and new data packet enqueue operations for this queue, preserving read-only access to the queue's cached data to prevent unexpected changes in the queue state during subsequent processing, while ensuring that data packet information within the queue can be read normally. The hardware switching device extracts the tenant identifier corresponding to the critical queue and marks it as a victim tenant identifier. This tenant identifier is completely consistent with the tenant identifier bound to the queue during data packet mapping in step S1, allowing for precise location of the tenant entity to which the queue belongs, completing the basic information collection after the interrupt is triggered.

[0056] S4 interrupt response and location identification of the encroaching queue.

[0057] S41 routine scheduling pause and interrupt response.

[0058] In response to the silent starvation critical interrupt triggered by step S33, the hardware switching device immediately suspends the normal scheduling logic of the current physical port. The hardware switching device stops the normal dequeue scheduling operations of all first and second queues, and simultaneously performs a snapshot freeze on the current state parameters of the hardware state machine corresponding to all queues in step S2. The frozen parameters include the current depth, dequeue rate, and counter value, and then enters the interrupt tracing process.

[0059] During interrupt handling, the hardware switching device only retains the data packet enqueue buffering operation of the non-locked queue in step S1. The enqueue operation only updates the real-time running parameters of the hardware state machine, and the parameter snapshot used for tracing remains unchanged. This ensures that the normal buffering of inbound data packets is not lost, and also blocks the modification of the tracing baseline data by the dequeue scheduling behavior and enqueue operation. It avoids the queue state changes in the regular scheduling process from interfering with the subsequent encroachment queue location results, and ensures the consistency and accuracy of all queue states during the tracing process.

[0060] Location of the S42 intrusion queue and extraction of intrusion tenant identifiers.

[0061] The hardware switching device traverses all first queues under the current physical port, sequentially reading the current outbound rate of each first queue after the snapshot freeze in step S41, and simultaneously retrieving the preset rate threshold pre-bound to each first queue. The preset rate threshold is the committed information rate corresponding to the first queue, that is, the maximum guaranteed bandwidth rate of the queue agreed upon by the tenant and the data center in the service level agreement. This value completely matches the configuration parameters of the tenant queue in step S1 and serves as the benchmark for distinguishing between legitimate bandwidth usage and excessive resource encroachment by the tenant.

[0062] The hardware switching device identifies the first queue whose outgoing rate exceeds a preset rate threshold as an encroaching queue. This type of queue monopolizes the outgoing scheduling opportunities of the physical port by continuously occupying bandwidth beyond the limit, and is the direct cause of the second queue being unable to obtain scheduling time slots and entering a silent starvation critical state. If there are multiple first queues exceeding the preset rate threshold, the first queue with the largest deviation from the preset rate threshold is identified as the unique encroaching queue. The hardware switching device extracts the tenant identifier corresponding to this encroaching queue and marks it as the encroaching tenant identifier. This tenant identifier is completely identical to the tenant identifier bound to the queue in step S1, which can accurately locate the single tenant entity that is over-occupying bandwidth resources, providing a unique logical parameter for subsequent consistency comparison.

[0063] S43 tenant identifier consistency logic comparison and scenario-based traffic splitting.

[0064] The hardware switching device performs a consistency comparison between the victim tenant identifier extracted and locked in step S33 and the trespassing tenant identifier extracted in step S42. Based on the comparison result, the hardware switching device performs hardware-level traffic splitting for the two scenarios. When the victim tenant identifier and the trespassing tenant identifier are inconsistent, the hardware switching device determines the current event as a cross-tenant physical bandwidth trespass scenario; when they are consistent, the hardware switching device determines the current event as a spontaneous congestion scenario within a single tenant's services. Through the consistency comparison of tenant identifiers, the hardware switching device can accurately distinguish the type of bandwidth trespass scenario, providing a clear basis for subsequent differentiated processing and avoiding service performance loss and scheduling logic oscillations caused by indiscriminate adjustments to scheduling strategies.

[0065] Single-packet-level token quota compensation scheduling for S5 cross-tenant bandwidth encroachment scenarios.

[0066] S51 Data Length Acquisition for Data Packets to be Forwarded

[0067] Based on the scenario determination results completed in step S43, when the hardware switching device determines that the current event is a cross-tenant physical bandwidth encroachment scenario, it retrieves the endangered queue locked in step S33. The hardware switching device reads the first data packet at the head of this endangered queue with read-only permissions, extracts the byte length of this first data packet, and determines it as the data length, with the unit being bytes (B). This data length is the sole measurement standard for this quota compensation. By using only the byte length of the first data packet at the head of the queue as the basis for compensation, the resource impact of this scheduling intervention can be minimized, and it will not cause continuous disturbance to the overall forwarding capacity of the physical port or the normal service transmission of other tenants.

[0068] S52 hardware token bucket quota precise replacement.

[0069] The hardware switching device identifies the hardware token buckets that correspond to the encroaching queue located in step S42 and the endangered queue locked in step S33, and are used to manage the queue dequeue quotas. It simultaneously locks the hardware token buckets corresponding to the encroaching queue and the endangered queue. During the locking period, the automatic token generation operation of the token bucket is suspended to ensure the accuracy of the token quantity during the quota replacement process.

[0070] When a hardware switching device performs a token quota replacement operation, it first determines whether the number of available tokens in the hardware token bucket corresponding to the encroaching queue is greater than or equal to the data length obtained in step S51. If the number of available tokens meets the requirement, the hardware switching device deducts a number of tokens equal to the data length obtained in step S51 from the hardware token bucket corresponding to the encroaching queue, and simultaneously injects the deducted tokens in full into the hardware token bucket corresponding to the endangered queue, completing a precise token quota replacement at the single-packet level. If the number of available tokens does not meet the requirement, the hardware switching device authorizes the hardware token bucket corresponding to the encroaching queue to enter a negative value state, records the corresponding overdraft limit, and then performs an equal amount of token deduction and injection operations to complete the quota replacement. Through point-to-point equal token replacement, the hardware switching device can provide precise dequeue permissions for endangered queues without adjusting the global scheduling weight and total port bandwidth quota, and will not have any additional impact on the normal service scheduling of other tenants.

[0071] S53 Single Packet Dequeue Drive and Scheduling Status Recovery.

[0072] After the token quota injection operation is completed, the hardware switching device releases the dequeue lock on the endangered queue, driving the endangered queue to output only the first data packet at the head of the queue, completing single-packet dequeue forwarding. This operation only allows the data waiting for the longest time in the endangered queue to be forwarded, which is usually a critical control frame for maintaining the underlying protocol connection. It can ensure the continuity of the tenant's underlying network protocol connection with minimal intervention and fundamentally block the triggering conditions of the protocol timeout retransmission mechanism.

[0073] After completing the single-packet outbound forwarding, the hardware switching device resets the counter corresponding to the endangered queue in step S2, simultaneously releasing the enqueue lock on the endangered queue and the operation lock on all hardware token buckets, and restoring the automatic token generation function of the token buckets. The hardware switching device also immediately resumes the normal scheduling logic that was suspended in step S41 for the current physical port, continuing to execute the strict priority scheduling mechanism to ensure that the normal forwarding of high-priority services is not continuously affected.

[0074] S54 token overdraft scenario credit limit deduction processing.

[0075] Regarding the token overdraft limit generated in step S52, after completing the single-packet dequeueing and normal scheduling logic restoration for the endangered queue, the hardware switching device will, in each subsequent preset clock cycle, prioritize using newly added tokens from the hardware token bucket corresponding to the encroaching queue to offset the recorded overdraft limit. The hardware switching device will only restore the normal token accumulation rules for the hardware token bucket after all overdraft limits have been offset, ensuring the long-term fairness of tenant bandwidth quotas and preventing the encroaching queue from occupying excessive bandwidth resources for extended periods.

[0076] Congestion control processing in S6 single-tenant internal self-congestion scenarios.

[0077] S61 Source Device Address Extraction and Explicit Congestion Notification Message Construction.

[0078] Based on the scenario determination results completed in step S43, when the hardware switching device determines that the current event is a spontaneous congestion scenario of internal services within a single tenant, it obtains the endangered queue locked in step S33. This queue and the encroaching queue located in step S42 belong to the same tenant. The root cause of the congestion is that the tenant's own high-priority service traffic continuously occupies the scheduling time slots of the physical port, causing the low-priority queues of the same tenant to be unable to obtain forwarding opportunities.

[0079] Before clearing all currently buffered packets in the second queue that triggered the interrupt, the hardware switching device parses the IP header of any buffered packet in the queue with read-only permissions to extract the corresponding source device address. The source device address is the IP address of the terminal device that sent the inbound packet, and it is completely consistent with the address field rules in the packet parsing in step S1. Based on the extracted source device address, the hardware switching device constructs a reverse congestion notification control message conforming to the TCP / IP protocol standard, and uses it as an explicit congestion notification message. The message type adopts the standard ICMP source suppression message or TCPECN explicit congestion notification message, and the message carries a preset rate reduction ratio parameter.

[0080] Release of queue cache in S62 self-congestion scenarios.

[0081] After completing the source device address extraction and packet construction, the hardware switching device triggers an active queue management mechanism to clear all currently buffered data packets in the second queue that triggered the interrupt, releasing the global shared cache resources occupied by this queue. This operation can clear invalid backlogged data caused by tenant's own traffic scheduling imbalance, prevent the switch's global cache resources from being invalidally occupied for a long time, and alleviate the overall congestion pressure on the ports.

[0082] S63 Explicit Congestion Notification Message Generation and Scheduling State Recovery.

[0083] After completing the queue clearing operation in step S62, the hardware switching device writes the explicit congestion notification message constructed in step S61 to the tail of the second queue that triggered the interrupt, generating the message, and simultaneously feeds it back to the corresponding source device through the inbound port. By writing and sending the message after clearing the queue, the critical congestion notification message is prevented from being self-destructed by the system, and the congestion control commands are ensured to be accurately delivered to the traffic sending end.

[0084] Upon receiving an explicit congestion notification message, the source device, based on the congestion indication and preset rate reduction ratio parameters carried in the message, performs transmission rate attenuation according to the preset rate reduction ratio. The preset rate reduction ratio is fixed at 50% by default. This ratio is set according to the general standard for data center network traffic control. It can quickly suppress sudden congestion of tenant's high-priority traffic and solve the scheduling and crowding problem of low-priority queues within the same tenant, without causing significant fluctuations in the transmission performance of the tenant's core services due to excessive rate reduction. It balances the effectiveness of congestion control with the continuity of service transmission. This ratio can be flexibly configured and adjusted according to the tenant's service level agreement.

[0085] After the hardware switching device completes the transmission of the explicit congestion notification message, it resets the counter corresponding to the second queue that triggered the interrupt in step S2, and simultaneously releases the lock on the endangered queue. The hardware switching device also immediately resumes the normal scheduling logic that was suspended in step S41 of the current physical port, continues to execute the strict priority scheduling mechanism, and completes the full process of handling this congestion event.

[0086] Based on the same inventive concept, this application also provides a data center network bandwidth scheduling device for implementing the aforementioned data center network bandwidth scheduling method. The solution provided by this system is similar to the implementation described in the above method; therefore, the specific limitations in the data center network bandwidth scheduling device embodiments provided below can be found in the limitations of the data center network bandwidth scheduling method described above, and will not be repeated here.

[0087] This application provides a data center network bandwidth scheduling device, such as... Figure 2 As shown, the data center network bandwidth scheduling device mainly includes the following core functional modules: The state maintenance module has its input connected to the physical port of the hardware switching device, and its output connected to the critical detection module and the logical comparison module, respectively. This module is used to execute all operations in steps S1 and S2 of the aforementioned method. On the one hand, based on the tenant identifier and priority of the inbound data packet, it completes packet parsing, queue mapping, enqueue buffering, and routine scheduling execution, realizing hardware-level isolation of data streams with different priorities among multiple tenants. On the other hand, through a hardware state machine driven by a preset clock cycle, it synchronously updates the current depth and dequeue rate of all first and second queues, and configures an independent counter for each second queue to record the number of consecutive cycles in which no data packets have been dequeued, providing real-time and accurate queue status data for subsequent risk detection and traffic tracing.

[0088] The critical detection module consists of an input state maintenance module and an output logic comparison module. This module executes all operations in step S3 of the aforementioned method. It pre-calibrates the stagnation threshold based on the minimum retransmission timeout of the network protocol corresponding to the inbound data packet. Within each clock cycle, it performs parallel logic checks on all second queues under the physical port. When it detects that the current depth of any second queue is greater than zero and the corresponding counter value reaches the preset stagnation threshold, it immediately triggers a hardware-level silent starvation critical interrupt, locks the corresponding endangered queue, and extracts the victim tenant identifier. This allows for accurate identification of the silent starvation critical risk of low-priority queues before TCP retransmission timeout, providing a pre-triggered basis for subsequent scheduling intervention.

[0089] The logic comparison module has inputs connected to the critical detection module and the state maintenance module, respectively, and an output connected to the control recovery module. This module executes all operations in step S4 of the aforementioned method. Upon responding to a critical interruption, it immediately suspends the normal scheduling logic of the physical port, freezes the state parameter snapshots of all queues, traverses all first queues under the current physical port, identifies the first queue whose dequeue rate exceeds a preset rate threshold as the intrusion queue, extracts the intrusion tenant identifier, and finally performs a consistency logic comparison between the victim tenant identifier and the intrusion tenant identifier. This completes hardware-level traffic splitting for both cross-tenant bandwidth intrusion and single-tenant internal self-congestion scenarios, providing a clear judgment result for subsequent differentiated handling.

[0090] The control and recovery module has its input connected to the logic comparison module, and its output connected to the physical port of the hardware switching device and the status maintenance module, respectively. This module executes all operations in steps S5 and S6 of the aforementioned method. For cross-tenant bandwidth encroachment scenarios, it obtains the data length of the first data packet at the head of the endangered queue, deducts an equivalent amount of quota compensation from the encroaching queue's outbound quota, drives the endangered queue to complete single-packet outbound forwarding, clears the corresponding counter, and restores normal scheduling. It also handles quota deduction in token overdraft scenarios. For spontaneous congestion scenarios within a single-tenant service, it first parses queue data packets to extract the source device address and constructs an explicit congestion notification message. Then, it clears the queue's cached data packets, generates the explicit congestion notification message at the tail of the queue, and sends it back to the source device, instructing the source device to reduce its transmission rate. Finally, it clears the corresponding counter and restores normal scheduling. This module blocks retransmission storms in cross-tenant scenarios from the source through precise single-packet token replacement, while simultaneously balancing service stability in single-tenant scenarios and bandwidth fairness in multi-tenant environments through a scenario-based congestion control mechanism.

[0091] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of each module are shown.

[0092] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0093] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.

[0094] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store device type information.

[0095] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation methods described in the embodiments of this application, or they can execute the implementation methods of the electronic devices described in the embodiments of this application, which will not be repeated here.

[0096] In another embodiment of this application, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to implement these processes. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0097] The computer-readable storage medium can be an internal storage unit of the electronic device in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, SmartMediaCard (SMC), Secure Digital (SD) card, FlashCard, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store computer programs and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

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

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the electronic devices and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0100] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules, units, or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces or modules / units, or it may be an electrical, mechanical, or other form of connection.

[0101] The modules / units described as separate components may or may not be physically separate. Similarly, the components shown as modules / units may or may not be physical modules / units; they may be located in one place or distributed across multiple network modules / units. Some or all of the modules / units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0102] Furthermore, the functional modules / units in the various embodiments of this application can be integrated into one processing module / unit, or each module / unit can exist physically separately, or two or more modules / units can be integrated into one module / unit. The integrated modules / units described above can be implemented in hardware or in the form of software functional modules / units.

[0103] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for scheduling network bandwidth in a computer room, characterized in that, include: Based on the tenant identifier and priority of the inbound data packet, the inbound data packet is mapped to the first queue or the second queue with a lower priority than the first queue and regular scheduling is performed; Monitor the current depth and dequeue rate of the first and second queues, and record counters for consecutive periods in which no data packets are dequeued; When the current depth of any of the second queues is greater than zero and its counter reaches a preset stagnation threshold, an interruption is triggered and the corresponding victim tenant identifier is extracted. In response to the interruption, the normal scheduling is paused, the first queue whose dequeue rate exceeds a preset rate threshold is identified as an intrusion queue, and the corresponding intrusion tenant identifier is extracted. When the victim tenant identifier does not match the intruding tenant identifier, obtain the data length of the first data packet in the second queue that triggered the interruption; The quota compensation equal to the data length is deducted from the dequeue quota of the encroaching queue and applied to the second queue that triggered the interruption, driving it to output the first data packet, clearing its counter, and restoring the normal scheduling.

2. The method according to claim 1, characterized in that, The monitoring of the current depth and dequeue rate of the first and second queues, as well as the counters that record consecutive periods during which no data packets are dequeued, includes: Configure a state machine driven by a preset clock cycle; Within each preset clock cycle, the current depth of the first queue and the second queue is updated synchronously through the state machine, and the total number of dequeued bytes of the first queue and the second queue is accumulated synchronously. At each preset statistical period, based on the total number of dequeued bytes accumulated within the statistical period, the state machine calculates and updates the dequeue rates of the first queue and the second queue. When no data packet is dequeued in the second queue within any preset clock cycle, the state machine controls the corresponding counter to perform an accumulation operation.

3. The method according to claim 2, characterized in that, The method for determining the preset stagnation threshold includes: Obtain the minimum retransmission timeout of the network protocol corresponding to the inbound data packet; The minimum retransmission timeout is multiplied by a preset proportional coefficient to generate the critical stall time; The ratio of the critical pause time to the preset clock period is determined as the preset pause threshold.

4. The method according to claim 3, characterized in that, The step of deducting a quota compensation equal to the data length from the dequeue quota of the encroaching queue and transferring it to the second queue that triggered the interruption, thereby driving it to output the first data packet, includes: Extract the byte length of the first data packet as the data length; Determine the hardware token buckets that correspond to the encroachment queue and the second queue that triggered the interrupt, respectively, and are used to manage the dequeue quota; The number of tokens equal to the data length is deducted from the hardware token bucket corresponding to the encroachment queue; The deducted tokens are used as compensation to inject the quota into the hardware token bucket corresponding to the second queue that triggered the interrupt, driving the second queue that triggered the interrupt to output only the first data packet to complete the single packet dequeue.

5. The method according to claim 4, characterized in that, During the process of deducting a number of tokens equal to the data length and restoring the normal scheduling: When the number of available tokens in the hardware token bucket corresponding to the encroachment queue is less than the data length, the hardware token bucket is authorized to enter a negative value state and the overdraft limit is recorded in order to perform deduction and quota compensation injection. After the second queue that triggered the interrupt completes the dequeueing of the single packet, the corresponding counter is cleared and reset. Resume the normal scheduling and use the newly added tokens in the encroachment queue to offset the overdraft limit in the subsequent preset clock cycle.

6. The method according to claim 1, characterized in that, After the steps of suspending the normal scheduling in response to the interruption, identifying the first queue whose dequeue rate exceeds a preset rate threshold as an intruding queue, and extracting the corresponding intruding tenant identifier, the method further includes: When the victim tenant identifier matches the intruding tenant identifier, it is determined to be spontaneous congestion within a single tenant's internal business. Clear all currently buffered data packets in the second queue that triggered the interrupt, and generate an explicit congestion notification message at the tail of the second queue that triggered the interrupt; The explicit congestion notification message is sent back to the source device that sent the inbound data packet to instruct the source device to reduce the transmission rate, and then the corresponding counter is cleared and the normal scheduling is restored.

7. The method according to claim 6, characterized in that, The steps of clearing all currently buffered data packets in the second queue that triggered the interrupt, generating an explicit congestion notification message at the tail of the second queue that triggered the interrupt, and feeding back the explicit congestion notification message to the source device that sent the inbound data packet include: Before clearing all currently cached data packets in the second queue that triggered the interrupt, the packet headers are parsed to extract the corresponding source device address; Based on the source device address, a reverse congestion notification control message is constructed as the explicit congestion notification message; After clearing all currently buffered data packets in the second queue that triggered the interrupt, the explicit congestion notification message is generated at the tail of the second queue that triggered the interrupt. The explicit congestion notification message is fed back to the source device to drive the source device to perform transmission rate attenuation according to a preset rate reduction ratio based on the explicit congestion notification message.

8. A data center network bandwidth scheduling device, used to implement the data center network bandwidth scheduling method according to any one of claims 1 to 7, characterized in that, The device includes: The status maintenance module is configured to map the inbound data packets to a first queue or a second queue with a lower priority than the first queue based on the tenant identifier and priority of the inbound data packets and perform regular scheduling, as well as monitor the current depth, dequeue rate and counters of the first queue and the second queue and record consecutive periods in which no data packets have been dequeued. The critical detection module is configured to trigger an interrupt and extract the corresponding victim tenant identifier when the current depth of any second queue is greater than zero and its counter reaches a preset stagnation threshold. The logic comparison module is configured to pause the regular scheduling in response to the interruption, locate the first queue whose dequeue rate exceeds a preset rate threshold as an intrusion queue, extract the corresponding intrusion tenant identifier, and perform a consistency logic comparison between the victim tenant identifier and the intrusion tenant identifier. The control recovery module is configured to, when the victim tenant identifier is inconsistent with the intruding tenant identifier, obtain the data length of the first data packet in the second queue that triggered the interruption, deduct a quota compensation equal to the data length from the dequeue quota of the intruding queue and apply it to the second queue that triggered the interruption, so as to drive it to output the first data packet, and then clear its counter and restore the normal scheduling.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the data center network bandwidth scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the data center network bandwidth scheduling method as described in any one of claims 1 to 7.

Images