Network switch with hybrid architecture

Abstract

The invention relates to a network switch with a hybrid architecture. A network switch has a packet pull architecture and also supports packet push. In an example embodiment, an apparatus includes: an output buffer; a data crossbar connected to the output buffer; an input buffer connected to the data crossbar; inputting a queue; a request crossbar connected to the input queue; and outputting the queue. The input queue is configured to transmit a packet from the input buffer to the output buffer through the data crossbar in response to the packet being suitable for packet push, and send a push request in parallel with transmitting the packet to the output buffer. The output queue is configured to receive a push request from the input queue by requesting the crossbar, and to control reading of packets from the output buffer in response to granting the push request.

Description

Background Art

[0001] Network switching is a fundamental concept in computer networking that involves the forwarding of data packets between devices within a network. Network switches analyze the destination of incoming packets and use that information to make forwarding decisions, thereby performing data transfer within a network. Network switches reduce network congestion and improve overall efficiency compared to older hub-based networks. Latency, the delay between sending and receiving data, is an important factor in network switching performance, as lower latency results in faster and more responsive communications between devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures.

[0003] Figure 1 is a schematic diagram of a network system according to some embodiments.

[0004] Figure 2 is a block diagram of a network switch according to some embodiments.

[0005] Figure 3A-3B is a block diagram of a network switch according to some embodiments.

[0006] Figure 4 is a schematic diagram of a packet forwarding method according to some implementations.

[0007] Figure 5 is a schematic diagram of a flow forwarding method according to some implementations.

[0008] Figure 6 is a block diagram of a network switch according to some embodiments.

[0009] Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated.The figures are drawn to clearly illustrate the relevant aspects of the disclosure and are not necessarily drawn to scale. DETAILED DESCRIPTION

[0010] The following disclosure provides many different examples for implementing different features. Specific examples of components and arrangements are described below to simplify the disclosure. Of course, these are merely examples and are not intended to be limiting.

[0011] Network switches are used for data packet forwarding in a local network. While network switches can typically operate at line rate under light load, they may have difficulty maintaining line rate under heavy load. One source of performance issues is head-of-line blocking, which is a phenomenon where one congested port of a network switch blocks packets from being transmitted to other non-congested ports of the network switch. Packet pull, such as virtual output queuing (VOQ), is an architectural technique that allows a network switch to maintain line rate under congestion by reducing head-of-line blocking. However, packet pull may increase the latency of the network switch. Therefore, while packet pull can improve the performance of a network switch under heavy load, it may reduce the performance of a network switch under light load. Increasing the clock speed is a basic method to reduce the latency of a network switch, but this approach may not be feasible as the performance requirements for network switches increase.

[0012] The present disclosure describes a network switch with a packet pull architecture that also supports packet push. Packets are pushed from an input buffer of an input port to an output buffer of an output port through a data crossbar switch. An input queue of an input port transmits packets from the input buffer to an output buffer. In parallel with the transmission, the input queue sends a push request to an output queue of an output port through a request crossbar switch. The output queue controls reading from the output buffer and controls reading packets from the output buffer by granting the push request. The output queue can also notify the input queue that the request is granted by granting the crossbar switch. Therefore, packets can be pushed from the input buffer to the output buffer without first negotiating a transmission grant.

[0013] In an example embodiment, packet push may be performed only in certain circumstances, such as when the network switch is lightly loaded. Under heavy load, packet pull (e.g., VOQ) may be performed instead of packet push. Thus, the network switch may have improved performance under both light load (result of packet push) and heavy load (result of packet pull). In addition, low latency may be maintained for short bursts of traffic and for low bandwidth packet flows. Dynamically performing packet push / pull based on the load of the network switch may be more efficient than performing packet push / pull only on itself.

[0014] Figure 11 is a schematic diagram of a network system 100 according to some embodiments. The network system 100 may be a high-performance network as part of a high-performance computing (HPC) environment. In the network system 100, client devices 102 act as sending nodes and access servers 104. The servers 104 interact with each other and may interact with storage devices 106. The servers 104 and / or storage devices 106 act as receiving nodes and provide software / services to the client devices 102. The servers 104 and / or storage devices 106 may be part of an HPC cluster. The servers 104 and storage devices 106 are merely examples of devices that the client devices 102 may access.

[0015] The client device 102 interacts with the server 104 via a network 108. The network 108 may be any wired or wireless network suitable for facilitating communication between the client device 102 and the server 104. The client device 102 and / or the server 104 include a network interface for accessing the network 108. For example, the client device 102 and / or the server 104 may include a network interface card (NIC), a wireless interface card, etc. The network 108 may include a controller, an access point, a switch, a router, etc. for forwarding services between the client device 102 and the server 104. The client device 102 may be any electronic device suitable for executing executable code. The server 104 may be a bare metal suitable for hosting cloud components (e.g., virtual machines, containers, etc.). The storage device 106 may be a network attached storage (NAS) device.

[0016] The servers 104 and storage devices 106 are interconnected via one or more network switches, including a network switch 110. The servers 104 and storage devices 106 communicate with each other via packets transmitted between a sending node and a receiving node. The servers 104 and storage devices 106 are just examples of devices that can be interconnected via a network switch 110. Other devices can be connected to the network switch 110. Packets can be routed by the network switch 110. The network switch 110 can have a high line rate, such as a line rate of 800Gbps, 1600Gbps, or higher. When the servers 104 and / or storage devices 106 are part of an HPC cluster, a high line rate may be required.

[0017] Figure 2 is a block diagram of a network switch 200 according to some embodiments. The network switch 200 is a block diagram of a network switch 200 according to some embodiments. Figure 1 An example of a network switch 110 is depicted. The network switch 200 includes ports 202 and a switch fabric 204. The ports 202 serve as connection points for nodes (eg, servers, storage devices, etc.). The switch fabric 204 manages and forwards data packets between the ports 202.

[0018] Each port 202 includes an input port 206 and an output port 208. The input port 206 is the entry point for packets to enter the network switch 200. The output port 208 is the exit point responsible for transmitting the packet to its designated destination. When a packet arrives at the input port 206, the network switch 200 checks the destination address of the packet to determine the appropriate output port 208 for transmission. This process is called switching or forwarding and includes performing a lookup in the forwarding table of the network switch 200 to find a forwarding path for the packet.

[0019] In a one-to-many configuration, each input port 206 receives packets from a node connected to the input port 206 and sends packets to an output port 208. The input port 206 controls how packets are sent to the output port 208. Similarly, in a many-to-one configuration, each output port 208 receives packets from an input port 206 and sends packets to a node connected to the output port 208. The output port 208 controls how packets are received from the input port 206.

[0020] The ports 202 (including input ports 206 and output ports 208) are interconnected via a switch fabric 204, which provides the necessary path for packets to move from the input ports 206 to the output ports 208. The switch fabric 204 links the input ports 206 and the output ports 208. Depending on the architecture of the network switch 200, the switch fabric 204 can be based on a crossbar switch matrix, a shared bus, a shared memory, etc. In one embodiment, the switch fabric 204 includes a plurality of crossbar switches for both control and data transmission between the input ports 206 and the output ports 208.

[0021] The components of the network switch 200 can be implemented as integrated circuits, such as in one or more integrated circuit dies and / or one or more integrated circuit packages. For example, the network switch 200 may include a processor, an application specific integrated circuit, a field programmable gate array, a memory, a combination thereof, and the like. One or more modules within the network switch 200 may be partially or fully embodied as software and / or hardware for performing any of the functions described herein. For example, each buffer, queue, crossbar switch, transmitter, receiver, structure, etc. described herein may be implemented as a logic block of an integrated circuit. In some embodiments, the components of the network switch 200 are implemented across multiple integrated circuit dies / packages, which may be assembled together in the same chassis.

[0022] As described in more detail subsequently, the network switch 200 has a hybrid architecture that integrates both packet push and packet pull technologies. The network switch 200 is adapted to perform packet push when the packet is suitable for packet push, and is adapted to perform packet pull when the packet is not suitable for packet push. The suitability of packet push can be based on factors such as the load of the network switch 200, the service class of the routed service, the availability of buffer space at the output port 208, etc. Although the use of packet pull can help the network switch 200 maintain line rate under heavy load, packet pull may also have increased latency compared to packet push. By utilizing a hybrid architecture, the network switch 200 can advantageously maintain line rate under heavy load (as a result of packet pull), but can also maintain low latency under light load (as a result of packet push).

[0023] Figure 3A-3B is a block diagram of a network switch 300 according to some embodiments. The network switch 300 is a block diagram of a network switch 300 according to some embodiments. Figure 2 An example of a network switch 200 is depicted. Components of a network switch 300 (including components of a switch fabric 304, input ports 306, and output ports 308) are shown. Figure 3A The logical flow during pulling a packet from input port 306 to output port 308 is shown, and Figure 3B The logical flow during pushing a packet from an input port 306 to an output port 308 is shown. Although packet forwarding from one input port 306 to one output port 308 will be described, it should be understood that each input port 306 can send packets to multiple output ports 308, and each output port 308 can receive packets from multiple input ports 306.

[0024] First reference Figure 3A-3B , the components of the network switch 300 will be described. The input port 306 includes a receiver 312, an input buffer 314, and an input queue 316. The receiver 312 receives packets on the physical line from the source node connected via the input port 306. The destination of these packets is the destination node connected via the output port 308. The source node and / or the destination node can be directly connected to the network switch 300, or there can be one or more network components (e.g., additional switches) between the network switch 300 and the source / destination node. The input buffer 314 is connected to the receiver 312. The received packets are stored in the input buffer 314.

[0025] The input queue 316 is connected to the input buffer 314 and the receiver 312. The input queue 316 is an input controller that controls the transmission of packets from the input buffer 314 to the output buffers of the respective output ports 308. The receiver 312 queues requests to send packets to the respective output ports 308 at the input queue 316. The input queue 316 arbitrates among the requests in its queue and selects the request to be processed. The input queue 316 determines to which output port 308 the packet of the selected request should be forwarded. For example, an Ethernet lookup unit (not shown separately) can extract the appropriate headers from the packet and use them to perform address translation of the destination node of the packet. The input queue 316 can receive the lookup results from the Ethernet lookup unit.

[0026] The output port 308 includes an output queue 322, an output buffer 324, and a transmitter 326. The output queue 322 is an output controller that controls the reception of packets in the output buffer 324 from the input buffers of the respective input ports 306. Requests for receiving packets from the respective input ports 306 are queued in the output queue 322. The output queue 322 arbitrates among the requests in its queue and selects the request to be processed. The output buffer 324 is connected to the output queue 322. The received packets are stored in the output buffer 324. The transmitter 326 is connected to the output buffer 324. The transmitter 326 reads packets from the output buffer 324 and transmits the packets to the destination node by sending signals along the physical line. Therefore, by controlling the reception of packets in the output buffer 324, the output queue 322 effectively controls the transmitter 326 to read packets from the output buffer 324.

[0027] As previously described, the network switch 300 can support packet pull. Packet pull, such as virtual output queuing (VOQ), is an architectural technique that allows a network switch to maintain line rate in congested situations by reducing head-of-line blocking. The input queue 316 can maintain a virtual queue for each output port 308. As a result, if congestion occurs at an output port 308, the virtual queue of that output port 308 may be blocked, but the virtual queues of other output ports 308 may continue to be processed. Therefore, the network switch 300 can support congestion management and / or traffic shaping attributes.

[0028] The switch fabric 304 includes a plurality of crossbars that are different from each other. In this example, the switch fabric 304 includes a request crossbar 332, a grant crossbar 334, a data crossbar 336, and a credit crossbar 338. The request crossbar 332 and the grant crossbar 334 are connected to the input queue 316 of each input port 306 and the output queue 322 of each output port 308. As described in more detail later, a transfer request (e.g., a push / pull request) will be sent through the request crossbar 332, and a transfer grant (e.g., a push / pull grant) will be sent through the grant crossbar 334. The data crossbar 336 is connected to the input buffer 314 of the input port 306 and the output buffer 324 of the output port 308. The credit crossbar 338 is connected to the input queue 316 of the input port 306 and the output buffer 324 of the output port 308. As described in more detail later, a packet will be transferred through the data crossbar 336, and the credit for the packet push will be returned through the credit crossbar 338.

[0029] Reference now Figure 3A , the logical flow of pulling a packet from input port 306 to output port 308 will now be described. Receiver 312 receives the packet and stores the packet in input buffer 314. The request to transmit the packet is queued at input queue 316, which then selects the request for processing. Input queue 316 sends a pull request for the packet to output queue 322 via request crossbar 332. The pull request includes a description of the packet; for example, the request may include information from the packet header.

[0030] The pull request is queued at the output queue 322, which then selects the pull request for processing. The output queue 322 decides whether and when to grant the pull request. For example, the output queue 322 can decide which pull request to grant next based on the packet description of the pull request and based on the current state of the output buffer 324. In response to the pull request being granted, the output queue 322 sends the pull grant to the input queue 316 through the grant crossbar 334.

[0031] The pull grant is a notification that instructs the input queue 316 to move a packet from the input buffer 314 to the output buffer 324. In response to receiving the pull grant, the input queue 316 transmits the packet from the input buffer 314 to the output buffer 324 through the data crossbar switch 336. The output buffer 324 includes a pull buffer 342. The pull buffer 342 is dedicated to the output port 308 and can be shared between each input port 306. The packet is transmitted to the pull buffer 342 of the input port 306. The transmitter 326 then reads the packet from the output buffer 324 (e.g., from the pull buffer 342). Therefore, the output queue 322 controls the reading of the packet by the transmitter 326 (and thus determines which packets are sent via the transmitter 326) by granting the pull request.

[0032] Reference now Figure 3B , the logical flow of pushing a packet from input port 306 to output port 308 will now be described. Receiver 312 receives the packet and stores the packet in input buffer 314. The request to transmit the packet is queued at input queue 316, which then selects the request for processing. Input queue 316 determines that the request is a candidate for packet push. The criteria for whether a packet is suitable for packet push will be described later. In response to the packet not being suitable for packet push, the packet can be pulled via packet pull (as described above for Figure 3A The ) is sent to output port 308 instead of packet push.

[0033] In response to the packet being suitable for packet push, multiple operations are performed in parallel. Input queue 316 sends a push request for the packet to output queue 322 via request crossbar 332. The push request includes a description of the packet; for example, the request may include information from the packet header. At the same time, input queue 316 transmits the packet from input buffer 314 to output buffer 324 via data crossbar 336. Output buffer 324 includes a push buffer 344 dedicated to each input port 306. The packet is transmitted to the push buffer 344 of input port 306.

[0034] The push request is queued at the output queue 322, which then selects the push request for processing. The push request notifies the output port 308 that the packet is being / has been pushed to the push buffer 344 of the input port 306. The output queue 322 decides whether and when to grant the push request. For example, the output queue 322 can decide which push request to grant next based on the packet description of the push request and based on the current state of the output buffer 324. In response to the push request being granted, the output queue 322 sends a push grant to the output buffer 324.

[0035] The push grant is a notification that informs the output buffer 324 that the push request has been granted. The grant notification is processed locally at the output port 308. In response to the push request being granted, multiple operations are performed in parallel. The transmitter 326 reads the packet from the output buffer 324 (e.g., from the push buffer 344). Therefore, the output queue 322 controls the transmitter 326 to read the packet (and therefore determines which packets are sent via the transmitter 326) by granting the push request. At the same time, the output queue 322 also sends the push grant to the input queue 316 through the grant cross switch 334. The push grant reminds the input queue 316 to grant the push request. Because the push grant is sent in parallel with reading the packet from the output buffer 324, less traversal of the switching structure 304 can be performed before the push request is read by the transmitter 326 (compared with packet pull). Therefore, the packet forwarding latency can be reduced.

[0036] Each input port 306 manages its push buffer 344 at the output port 308. The push buffer 344 has a limited space. The use of the push buffer 344 by the input port 306 can be credited. The input port 306 can push packets to the output port 308 until it consumes its available credits at the output port 308. The input queue 316 tracks its available credits at the push buffer 344 of the output port 308. Transmitting packets from the input buffer 314 to the output buffer 324 reduces the credits of the push buffer 344. Reading packets from the output buffer 324 by the transmitter 326 increases the credits. When the transmitter 326 reads packets from the push buffer 344, the output buffer 324 returns credits to the input queue 316 through the credit crossbar 338, such as by sending a credit return notification to the input queue 316. The input queue 316 can track the available credits at the push buffer 344 of each output port 308. For example, the input queue 316 can maintain a credit counter for the push buffer 344 of each output port 308. When a packet is pushed to the push buffer 344, the input queue 316 may decrement the credit counter of the push buffer 344. When a credit return notification is received from the push buffer 344, the input queue 316 may increment the credit counter of the push buffer 344.

[0037] Additionally or alternatively, the use of the push buffer 344 by the input port 306 can be based on the traffic class of the packet. The input port 306 can use the push buffer 344 for some or all traffic classes. The traffic class of the packet can be indicated in the header of the packet. In some embodiments, the input port 306 only uses the push buffer 344 for packets of a specific traffic class. The push buffer 344 can be shared between specific traffic classes. In some embodiments, the input port 306 uses the push buffer 344 for packets of any traffic class.

[0038] Load information is collected at each output port 308 and distributed to the input port 306. The load information can be used to determine whether the output port 308 is lightly loaded or heavily loaded. The load of the output port 308 can be based on the load of its output queue 322, for example, based on the number of outstanding requests queued at the output queue 322. In some embodiments, the load monitor 346 at the output port 308 can collect the load information of the output port 308 and send the load information to the input queue 316 of the input port 306 through the switching structure 304. The load information can be sent through the crossbar switch of the switching structure 304. The load information may include the number of outstanding requests queued at the output queue 322, which may or may not be grouped by business class. The input queue 316 can track the load information of the output queue 322 and use it to determine whether to push the packet to the output port 308.

[0039] The criteria for determining whether a packet is suitable for packet push can be based on the load of the output port 308. Specifically, when determining whether a request is a candidate for packet push, the input queue 316 evaluates the load information received from the load monitor 346 of the output port 308. If the load information indicates that the output port 308 is lightly loaded, the packet may be suitable for packet push, and if the load information indicates that the output port 308 is heavily loaded, the packet may not be suitable for packet push. When the number of outstanding requests queued at the output queue 322 is below a predetermined threshold, the output port 308 may be lightly loaded. In some embodiments, when determining whether the output port 308 is heavily / lightly loaded, all types of outstanding requests queued at the output queue 322 are considered. In some embodiments, when determining whether the output port 308 is heavily / lightly loaded, only specific types of outstanding requests queued at the output queue 322 are considered. For example, when the number of outstanding requests at the output queue 322 is grouped by business class, only requests for packets of a particular business class may be considered for forwarding when determining whether the output port 308 is heavily / lightly loaded. In addition, the outstanding requests may include outstanding pull requests, or a combination of outstanding pull requests and outstanding push requests.

[0040] When the number of outstanding requests at the output queue 322 is grouped by traffic class, the load evaluation of the output port 308 can be specific to a particular traffic class. In other words, the output port 308 can be considered to be heavily loaded for one traffic class and lightly loaded for another traffic class. In such an embodiment, if a packet is part of the lightly loaded traffic class, it may be suitable for packet push, but if it is part of the heavily loaded traffic class, it may not be suitable for packet push.

[0041] The criteria for determining whether a packet is eligible for packet push is also based on whether credits are available at the output buffer 324 (e.g., push buffer 344) of the input queue 316. Available credits are considered in addition to the load information of the output port 308. Therefore, even if the output port 308 is lightly loaded, if the input queue 316 lacks available credits at the push buffer 344, the packet may still not be eligible for packet push.

[0042] The criteria for determining whether a packet is suitable for packet push can also be based on the traffic class of the packet. In addition to the available credits at the push buffer 344 and / or the load information of the output port 308, the traffic class of the packet can also be considered. Therefore, even if there are available credits and / or the output port 308 is lightly loaded, if the traffic class of the packet is not a specific traffic class, the packet may still not be suitable for packet push.

[0043] Some variations are contemplated. Additionally or alternatively, the traffic class of a packet may be considered independent of the load information of the output port 308. For example, packets of a particular traffic class may be suitable for packet push even when the output port 308 is heavily loaded. Pushing a particular class of traffic may also be advantageous even when the output port 308 is heavily loaded.

[0044] You can use group pull (as mentioned above for Figure 3A as described above) and group push (as described above for Figure 3B 308. In some embodiments, the present invention relates to a method for forwarding a packet stream from an input port 306 to an output port 308 using a combination of packet pull and packet forwarding. For example, depending on whether the packet is a candidate for packet push, a first packet of the packet stream may be forwarded using packet push, while a second packet of the packet stream may be forwarded using packet pull. A packet stream is an ordered sequence of packets. When forwarding a packet stream, the order of the packets in the packet stream should be maintained so that the transmitter 326 reads the packets of the packet stream from the output buffer 324 in the desired order. However, when forwarding packets of a packet stream using a combination of packet pull and push, since packet push has a lower latency than packet pull, the packets of the packet stream may arrive at the output port 308 out of order.

[0045] In some implementations, the output queue 322 assigns a sequence number to each packet of the packet flow based on the order of the packets in the packet flow. Specifically, the output queue 322 assigns sequence numbers to the transmission requests (e.g., push / pull requests) for the packets of the packet flow in the order in which the requests were received. When the output queue 322 grants a pull request (e.g., Figure 3A ), a pull grant sent to input queue 316 includes the sequence number of the packet of the request. When a packet is transferred from input buffer 314 to output buffer 324 (e.g., pull buffer 342), the sequence number of the packet is included with the packet. When output queue 322 grants a push request (e.g., Figure 3B 324), the push grant sent to the output buffer 324 is stored in the push buffer 344 along with the packet. In either case, both the packet and the sequence number of the packet are stored in the output buffer 324. The sender 326 reads the packets from the output buffer 324 in the order of their sequence numbers. For example, when the output buffer 324 contains both the first packet and the second packet of the packet stream, the packet with the lower sequence number can be read from the output buffer 324 before the packet with the higher sequence number. Thus, the sender 326 reads the packets of the packet stream from the output buffer 324 in the desired order, even if the packets are delivered to the output buffer 324 out of order.

[0046] Any suitable ordering technique may be used to assign sequence numbers. In some implementations, the output queue 322 has a sequencer (or counter) for each input port 306, and each time the output queue 322 grants a transmission request, it uses the value of the sequencer as the sequence number and increments the sequencer. In some implementations, the output queue 322 includes multiple sequencers for each input port 306, such as different sequencers for different traffic classes, and each time the output queue 322 grants a transmission request for a traffic class, it uses the value of the sequencer for that traffic class as the sequence number.

[0047] When forwarding a packet stream, the network switch 300 can switch from a first forwarding technique (e.g., packet pull / push) to a second forwarding technique (e.g., packet push / pull) midway through processing. The network switch 300 can switch between packet push and packet pull based on each stream. For example, a packet stream can be forwarded by using packet push to forward some packets, and then switching to using packet pull to forward other packets. In response to determining that the packet is the first packet in the packet stream, the packet can be forwarded using packet push. The packet stream can be converted from push to pull at any time, such as when the available credits at the push buffer 344 have been consumed. Similarly, the packet stream can be forwarded by using packet pull to forward some packets, and then switching to using packet push to forward other packets. The packet stream can be converted from pull to push based on one or more heuristics. In some embodiments, when there are no outstanding requests queued at the output queue 322, the packet stream can be converted from pull to push. In some embodiments, when the output port 308 is lightly loaded, for example, when the number of outstanding requests queued at the output queue 322 is low, such as below a predetermined threshold, the packet flow can be switched from pull to push. In some embodiments, when packets of the packet flow are detected as coming from a specific application or having a specific business pattern, the packet flow can be switched from pull to push. The packet forwarding technology can be switched to optimize for different applications or business patterns.

[0048] Figure 4 is a schematic diagram of a packet forwarding method 400 according to some embodiments. Figure 3A-3B A packet forwarding method 400 is described. The packet forwarding method 400 may be performed by the network switch 300 during forwarding of a packet from an input port 306 to an output port 308.

[0049] The network switch 300 optionally performs a step 402 of receiving load information for an output queue, the load information including the number of outstanding requests queued at the output queue. Specifically, the load information is for an output queue 322 of an output port 308. An input queue 316 of an input port 306 receives the load information. The load information indicates the load of the output port 308. For example, the load information may include the number of outstanding requests queued at the output queue 322. The number of outstanding requests may be grouped by business class.

[0050] The network switch 300 performs a step 404 of determining whether the packet is suitable for packet push. The determination can be performed by the input queue 316 of the input port 306. The suitability of the packet push of the packet can be based on the load of the output queue 322. Specifically, when the number of outstanding requests (e.g., pull requests or pull and push requests) queued at the output queue 322 is lower than a predetermined threshold, the packet may be suitable for packet push. The number of outstanding requests considered can be the total amount of outstanding requests, or the number of outstanding requests for a specific business category group. Additionally or alternatively, the suitability of the packet push of the packet can be based on other considerations. For example, determining whether the packet is suitable for packet push can be based on whether there is credit available at the output buffer 324 of the input queue 316. Similarly, determining whether the packet is suitable for packet push can be based on the business category of the packet. Similarly, determining whether the packet is suitable for packet push can be based on the fact that the packet is the first packet (e.g., initial packet) in the packet flow.

[0051] If the packet is suitable for packet push, a first set of operations is performed. The network switch 300 performs step 406 of sending a push request from the input queue to the output queue in response to the packet being suitable for packet push, the push request including a description of the packet. Specifically, in response to the packet being suitable for packet push, the push request is sent from the input queue 316 to the output queue 322. The push request can be sent through a request crossbar 332 connected to the input queue 316 and the output queue 322. The push request is queued at the output queue 322.

[0052] The network switch 300 performs step 408 of transferring the packet from the input buffer to the output buffer in parallel with sending the push request. Specifically, in parallel with sending the push request, the packet is transferred from the input buffer 314 of the input port 306 to the output buffer 324 of the output port 308. The packet is transferred to the output buffer 324 without waiting for the push request to be granted. Therefore, steps 406 and 408 can be performed simultaneously. The packet can be transferred through the data crossbar switch 336 connected to the input buffer 314 and the output buffer 324. Transferring the packet from the input buffer 314 to the output buffer 324 reduces the credits available to the input queue 316 at the output buffer 324.

[0053] The network switch 300 performs step 410 of granting the push request at the output queue based on the description of the packet. Specifically, the push request is granted at the output queue 322.

[0054] The network switch 300 performs a step 412 of reading packets from the output buffer in response to the push request being granted. Specifically, in response to the push request being granted, the packets are read from the output buffer 324. The reading may be performed by the transmitter 326 under the control of the output queue 322. Reading packets from the output buffer 324 increases the credit available at the output buffer 324 of the input queue 316.

[0055] The network switch 300 performs step 414 of sending a push grant from the output queue to the input queue in parallel with reading the packet from the output buffer. Specifically, the push grant is sent from the output queue 322 to the input queue 316 in parallel with reading the packet from the output buffer 324. Therefore, steps 412 and 414 can be performed simultaneously. The push grant can also be sent from the output queue 322 to the output buffer 324, which can trigger reading the packet from the output buffer 324. When the output queue 322 selects the push request from its queued requests for processing, the output queue 322 can grant the push request. The push grant can be sent through the grant crossbar 334 connected to the input queue 316 and the output queue 322. When the push request is granted, if the packet is part of a packet stream, the output queue 322 can assign a sequence number to the packet based on the order of the packet in the packet stream.

[0056] If the packet is not suitable for packet push, a second set of operations is performed. The network switch 300 performs step 416 of sending a pull request from the input queue to the output queue in response to the packet not being suitable for packet push. Specifically, in response to the packet not being suitable for packet push, a pull request is sent from the input queue 316 to the output queue 322. The pull request may be sent through a request crossbar 332 connected to the input queue 316 and the output queue 322. The pull request is queued at the output queue 322.

[0057] The network switch 300 performs a step 418 of transferring the packet from the input buffer to the output buffer in response to the pull request being granted. Specifically, in response to the pull request being granted, the packet is transferred from the input buffer 314 to the output buffer 324. When the output queue 322 selects the pull request from its queued requests for processing, the output queue 322 can grant the pull request. When the pull request is granted, if the packet is part of a packet stream, the output queue 322 can assign a sequence number to the packet based on the order of the packet in the packet stream. The output queue 322 then sends a pull grant (including the sequence number) to the input queue 316. The pull grant can be sent by the grant crossbar 334 connected to the input queue 316 and the output queue 322. In response to receiving the pull grant, the input queue 316 transfers the packet to the output buffer 324. After waiting for the pull request to be granted, the packet is transferred to the output buffer 324. Therefore, steps 416 and 418 can be performed continuously.

[0058] Figure 5 is a schematic diagram of a stream forwarding method 500 according to some embodiments. Figure 3A-3B Flow forwarding method 500 is described. Flow forwarding method 500 may be performed by network switch 300 (particularly input queue 316) during forwarding of a packet flow from input port 306 to output port 308.

[0059] The network switch 300 performs step 502 of sending a push request for a first packet of a packet flow to an output queue. Specifically, the push request for the first packet of the packet flow is sent to an output queue 322 of an output port 308. The output queue 322 is configured to control receiving packets from an input buffer 314 of an input port 306 in an output buffer 324 of the output port 308. The push request may be sent in response to a first packet having a particular traffic class and / or in response to credits available at the output buffer 324.

[0060] The network switch 300 performs step 504 of transferring the first packet from the input buffer to the output buffer before the output queue grants the push request. Specifically, before the output queue 322 grants the push request, the first packet is transferred from the input buffer 314 to the output buffer 324. Therefore, the first packet is transferred to the output buffer 324 without waiting for the push request to be granted.

[0061] The network switch 300 performs step 506 of sending a pull request for the second packet of the packet flow to the output queue. Specifically, the pull request for the second packet of the packet flow is sent to the output queue 322. The pull request may be sent in response to unavailability of credit at the output buffer 324 or excessive load of the output queue 322.

[0062] The network switch 300 performs step 508 of transferring the second packet from the input buffer to the output buffer after the output queue grants the pull request. Specifically, after the output queue 322 grants the pull request, the second packet is transferred from the input buffer 314 to the output buffer 324. Therefore, after waiting for the pull request to be granted, the second packet is transferred to the output buffer 324.

[0063] When the push request and the pull request are granted, the output queue 322 assigns a sequence number to the first packet and the second packet. The sequence number is based on the order of the first packet and the second packet in the packet stream. Subsequently, the transmitter 326 reads the first packet and the second packet from the output buffer in the order of the sequence number.

[0064] The techniques of the present disclosure can achieve benefits. By utilizing a hybrid architecture that integrates both packet push and packet pull techniques, the network switch 300 can advantageously maintain line rate under heavy load (as a result of packet pull), but can also maintain low latency under light load (as a result of packet push). The network switch 300 can thus maintain the congestion management and shaping properties of VOQ while providing low latency under light load, bursty traffic, and low bandwidth packet flows.

[0065] Figure 6 is a block diagram of a network switch 600 according to some embodiments. The network switch 600 is a block diagram of a network switch 600 according to some embodiments. Figure 2 An example of a network switch 200 is described. The network switch 600 may include a processor 602 and a memory 604. The memory 604 may be a non-transitory computer-readable medium storing a program executed by the processor. In this embodiment, one or more modules within the network switch 600 may be partially or fully embodied as software for performing any of the functions described herein.

[0066] In an example embodiment, a device includes: an output buffer; a data crossbar connected to the output buffer; an input buffer connected to the data crossbar; an input queue configured to transfer the packet from the input buffer to the output buffer through the data crossbar in response to the packet being suitable for packet push, and send a push request in parallel with transferring the packet to the output buffer; a request crossbar connected to the input queue; and an output queue configured to receive the push request from the input queue through the request crossbar, and control reading the packet from the output buffer in response to granting the push request. In some embodiments, the device further includes: a grant crossbar connected to the output queue and the input queue, the output queue further configured to send a push grant from the output queue to the input queue through the grant crossbar in parallel with controlling the reading of the packet. In some embodiments of the device, the packet is suitable for packet push when credit is available at the output buffer for the input queue. In some embodiments of the device, the packet is suitable for packet push when the packet belongs to a specific service class. In some embodiments of the device, the packet is suitable for packet push when the number of outstanding requests queued at the output queue is below a predetermined threshold. In some embodiments of the apparatus, the output queue is further configured to assign sequence numbers to the packets based on an order of the packets in the packet flow.

[0067] In an example embodiment, a device includes: an input buffer; an output buffer connected to the input buffer; an output queue connected to the output buffer, the output queue being configured to control receiving packets from the input buffer in the output buffer; and an input queue connected to the output queue and the input buffer, the input queue being configured to: send a push request for a first packet of a packet flow to the output queue; before the output queue grants the push request, transfer the first packet from the input buffer to the output buffer; send a pull request for a second packet of the packet flow to the output queue; and after the output queue grants the pull request, transfer the second packet from the input buffer to the output buffer. In some embodiments of the device, the output queue is further configured to assign sequence numbers to the first packet and the second packet based on the order of the first packet and the second packet in the packet flow. In some embodiments, the device also includes: a transmitter configured to read the first packet and the second packet from the output buffer in the order of the sequence numbers. In some embodiments of the device, the input queue is configured to send the push request in response to credits available at the output queue and in response to a first packet with a specific service class. In some implementations, the device further includes: a credit crossbar switch connected to the input queue and the output buffer, the output buffer being further configured to return credits to the input queue through the credit crossbar switch.

[0068] In an example embodiment, a method includes: determining whether a packet is suitable for packet push; in response to the packet being suitable for packet push, sending a push request from an input queue to an output queue, the push request including a description of the packet; transferring the packet from an input buffer to an output buffer in parallel with sending the push request; granting the push request at the output queue based on the description of the packet; in response to the push request being granted, reading the packet from the output buffer; and sending the push grant from the output queue to the input queue in parallel with reading the packet from the output buffer. In some embodiments of the method, determining whether the packet is suitable for packet push is based on whether credit is available at the output buffer for the input queue, transferring the packet from the input buffer to the output buffer decreases the credit, and reading the packet from the output buffer increases the credit. In some embodiments of the method, determining whether the packet is suitable for packet push is based on a traffic class of the packet. In some embodiments of the method, determining whether the packet is suitable for packet push is based on a load of the output queue. In some embodiments, the method further includes: receiving load information of the output queue, the load information including a number of outstanding requests queued at the output queue, wherein the packet is suitable for packet push when the number of outstanding requests queued at the output queue is below a predetermined threshold. In some embodiments of the method, the number of outstanding requests is grouped by business class, and the load of the output queue is based on a specific business class. In some embodiments, the method also includes: in response to the packet being not suitable for packet push, sending a pull request from the input queue to the output queue; and in response to the pull request being granted, transferring the packet from the input buffer to the output buffer. In some embodiments, the method also includes: assigning a sequence number to the packet based on the order of the packet in the packet flow, wherein determining whether the packet is suitable for packet push is based on the packet being first in the packet flow. In some embodiments of the method, the push request is sent through a request crossbar switch connected to the input queue and the output queue, the push grant is sent through a grant crossbar switch connected to the input queue and the output queue, and the packet is transferred through a data crossbar switch connected to the input buffer and the output buffer. The method can be implemented as instructions stored on a non-transitory computer-readable medium.

[0069] The foregoing summarizes the features of several examples so that those skilled in the art can better understand the aspects of the present disclosure. Various modifications and combinations of reference descriptions, illustrative examples, and other examples will be apparent to those skilled in the art. Therefore, the appended claims are intended to include any such modifications.

Claims

1. A device comprising: Output buffer; a data crossbar switch connected to the output buffer; an input buffer connected to the data crossbar switch; an input queue configured to, in response to a packet being eligible for packet push, transfer the packet from the input buffer to the output buffer through the data crossbar switch, and to send a push request in parallel with transferring the packet to the output buffer; a request crossbar switch connected to the input queue; as well as An output queue is configured to receive the push request from the input queue through the request crossbar switch, and control reading of the packet from the output buffer in response to granting the push request.

2. The device according to claim 1, further comprising: A grant crossbar is connected to the output queue and to the input queue, the output queue being further configured to send a push grant from the output queue to the input queue through the grant crossbar in parallel with controlling reading of the packet.

3. The device according to claim 1, wherein: The packet is eligible for packet push when credit is available at the output buffer for the input queue.

4. The device according to claim 1, wherein: When the packet belongs to a specific service category, the packet is suitable for packet pushing.

5. The device according to claim 1, wherein: The packet is eligible for packet pushing when the number of outstanding requests queued at the output queue is below a predetermined threshold.

6. The device according to claim 1, wherein: The output queue is further configured to assign sequence numbers to the packets based on an order of the packets in the packet flow.

7. A device comprising: Input buffer; an output buffer connected to the input buffer; an output queue connected to the output buffer, the output queue being configured to control receiving packets from the input buffer in the output buffer; as well as An input queue, connected to the output queue and the input buffer, the input queue being configured as: sending a push request for a first packet of a packet flow to the output queue; before the output queue grants the push request, transferring the first packet from the input buffer to the output buffer; sending a pull request for a second packet of the packet flow to the output queue; as well as After the output queue grants the pull request, the second packet is transferred from the input buffer to the output buffer.

8. The device according to claim 7, wherein: The output queue is further configured to assign sequence numbers to the first packet and the second packet based on an order of the first packet and the second packet in the packet flow.

9. The device according to claim 8, further comprising: A transmitter is configured to read the first packet and the second packet from the output buffer in the order of the sequence numbers.

10. The device according to claim 7, wherein: The input queue is configured to send the push request in response to credit being available at the output queue and in response to the first packet having a particular traffic class.

11. The device according to claim 10, further comprising: A credit crossbar is connected to the input queue and to the output buffer, the output buffer being further configured to return credits to the input queue through the credit crossbar.

12. A method comprising: Determine whether the group is suitable for group push; In response to the packet being suitable for packet push, sending a push request from the input queue to the output queue, the push request including a description of the packet; transferring the packet from an input buffer to an output buffer in parallel with sending the push request; granting the push request at the output queue based on the description of the packet; In response to the push request being granted, reading the packet from the output buffer; as well as A push grant is sent from the output queue to the input queue in parallel with reading the packet from the output buffer.

13. The method according to claim 12, wherein: Determining whether the packet is eligible for packet push is based on whether credit is available at the output buffer for the input queue, transferring the packet from the input buffer to the output buffer decrements the credit, and reading the packet from the output buffer increases the credit.

14. The method according to claim 12, wherein: Determining whether the packet is suitable for packet pushing is based on the traffic class of the packet.

15. The method according to claim 12, wherein: Determining whether the packet is suitable for packet pushing is based on the load of the output queue.

16. The method according to claim 15, further comprising: receiving load information of the output queue, the load information comprising a number of outstanding requests queued at the output queue, Wherein, when the number of outstanding requests queued at the output queue is lower than a predetermined threshold, the packet is suitable for packet pushing.

17. The method according to claim 16, wherein: The number of outstanding requests is grouped by traffic class, and the load of the output queue is based on the specific traffic class.

18. The method according to claim 12, further comprising: In response to the packet being unsuitable for packet push, sending a pull request from the input queue to the output queue; as well as In response to the pull request being granted, the packet is transferred from the input buffer to the output buffer.

19. The method according to claim 12, further comprising: The packet is assigned a sequence number based on an order of the packet in a packet stream, wherein determining whether the packet is suitable for packet pushing is based on the packet being first in the packet stream.

20. The method according to claim 12, wherein: The push request is sent through a request crossbar switch connected to the input queue and to the output queue, the push grant is sent through a grant crossbar switch connected to the input queue and to the output queue, and the packet is transmitted through a data crossbar switch connected to the input buffer and to the output buffer.

Images