Semiconductor chip, method and system for implementing aggregate flow detection and management

Abstract

The present application relates to centralized aggregate long flow detection and management. A semiconductor chip for implementing aggregate flow detection and management includes a plurality of pipelines, wherein each pipeline is coupled to a portion of a port on the semiconductor chip for receiving data packets. Logic is coupled to the pipelines and is used to detect and manage long flows. The long flow detection and management logic includes a flow table and a byte counter.

Description

Technical Field

[0001] The present description relates generally to Ethernet communications, and in particular, to centralized aggregate long flow detection and management. Background Art

[0002] A small amount of streams carries most of the Internet business, while a large amount of streams carries relatively few Internet business. A stream that carries a large amount of Internet business and consumes routing resources at a much higher rate via a network link is called a long stream. Long streams significantly affect the Internet business flow through the network by causing packet loss and increasing delay. Effective detection, analysis and management of these streams can help reduce congestion, packet loss and tail delay. When the stream changes the inbound port (for various reasons, such as load balancing, ports are closed due to maintenance, etc.) and when it falls on different processing pipelines, the existing implementation scheme cannot analyze and detect the stream across multiple pipelines. The cost of the implementation scheme is copied by pipeline and can be significant (in terms of chip area and power consumption) for a device with 16 or 32 pipelines. In other words, the existing solution does not support aggregation across multiple pipelines, and its long stream detection is based only on the number of bytes in a given stream and is not based on corresponding outbound queue / port load and / or congestion. In addition, all accounting is only performed on the start of packet (SOP), thereby being limited to supporting the stream with data packet byte count information available at the SOP. Summary of the invention

[0003] On the one hand, the present application relates to a semiconductor chip for implementing aggregate flow detection and management, the semiconductor chip comprising: a plurality of pipelines, each pipeline coupled to a portion of a port on the semiconductor chip configured to receive data packets; and logic coupled to the plurality of pipelines and configured to detect and manage long flows, wherein the logic includes a flow table and a byte counter.

[0004] In another aspect, the present application relates to a method for detecting and managing aggregate flows, the method comprising: configuring a pipeline among a plurality of pipelines disposed on a semiconductor chip to receive data packets from a port among a plurality of ports of the semiconductor chip; coupling logic to the plurality of pipelines; and configuring the logic to: receive real-time updates about flow information of the data packets from the plurality of ports; and detect and manage long flows based on at least the flow information.

[0005] In another aspect, the present application relates to a system comprising: a memory; and one or more processors coupled to the memory and configured to execute instructions to perform actions including: receiving data packets from multiple ports of the semiconductor chip by pipelines among multiple pipelines disposed on the semiconductor chip; receiving real-time updates about flow information about the data packets from the multiple ports by logic; and detecting and managing long flows based at least on the flow information, wherein the logic is coupled to the multiple pipelines. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Certain features of the technology are set forth in the appended claims. However, for illustrative purposes, several embodiments of the technology are set forth in the drawings.

[0007] Figure 1 is a block diagram illustrating an example of a switch and / or router chip within which the centralized aggregate long flow detection and management of the present technology is implemented.

[0008] Figure 2 is a block diagram illustrating limiting aspects of an example of an existing long flow detection system.

[0009] Figure 3 is a high-level block diagram illustrating an example of a converged long flow detection system in accordance with various aspects of the present technology.

[0010] Figure 4 is a block diagram illustrating an example of a converged long flow detection system in accordance with various aspects of the present technology.

[0011] Figure 5 is a diagram illustrating an example of flow management using load-aware equal-cost multi-path (ECMP) mapping.

[0012] Figure 6 is a flow chart illustrating an example of an aggregated long flow detection process according to some aspects of the present technology.

[0013] Figure 7 is a flow chart illustrating an example of a long flow management process in accordance with some aspects of the present technology.

[0014] Figure 8 An electronic system in which some aspects of the present technology may be implemented. DETAILED DESCRIPTION

[0015] The detailed description set forth below is intended as a description of various configurations of the present technology and is not intended to represent the only configuration in which the present technology may be practiced. The accompanying drawings are incorporated herein and form part of the detailed description, which includes specific details for providing a thorough understanding of the present technology. However, the present technology is not limited to the specific details set forth herein and may be practiced without one or more of the specific details. In some examples, structures and components are shown in block diagram form in order to avoid blurring the concepts of the present technology.

[0016] The present technology relates to methods and systems for centralized long flow detection and management. In communication networks, long flows refer to extremely large data flows through network links, which can occupy a disproportionate share (e.g., more than 1%) of the total bandwidth for a period of time. Long flows can significantly affect Internet traffic through network links by causing packet loss and increasing latency, and can consume routing resources at a much higher rate through network links.

[0017] The present technology can detect, analyze and manage long flows to reduce traffic congestion, packet loss and tail latency.For each data packet passing through, each pipeline can provide information related to several subjects to the central long flow detection module, as described in more detail herein.

[0018] Detected long flows are reported to implement changes to their quality of service. Detected long flows may also be separated or distributed across desired paths using a load-aware ECMP structure. The load-aware ECMP structure may dynamically map modified paths through network routers using a central state machine, as described in U.S. Patent Application No. 17 / 230,940 filed on April 14, 2021, which is incorporated herein by reference.

[0019] The disclosed solution has several advantageous features. For example, using the disclosed technology, long flow detection and management logic is implemented only once, regardless of the number of pipelines on a semiconductor chip (hereinafter chip), which results in a fraction of the cost of existing implementations. Moreover, the disclosed solution is aggregated across all pipelines of the chip and is agnostic to changes in the flow of the inbound port on a given router. In addition, the long flow detection and management logic of the present technology supports any protocol, regardless of whether the data packet length is available at the SOP, and can be enabled to track the flow hash (e.g., 16-bit flow hash) only when the corresponding outbound port is congested and / or loaded to a certain threshold within a time interval threshold.

[0020] Figure 11 is a block diagram illustrating an example of a switch / router chip 100 in which the centralized aggregate long flow detection and management logic of the present technology is implemented. The example switch / router chip 100 includes a block 110, which includes a plurality of inbound media access control (MAC) layers and port interfaces (hereinafter inbound MAC and interface blocks 110), a plurality of inbound packet processing pipelines 120, a memory management and crossbar switch unit 130, a plurality of outbound packet processing pipelines 140, and a plurality of outbound MAC and port interfaces 150 (hereinafter outbound MAC and interface blocks 150). Each port interface of the inbound MAC and interface block 110 is connected to an input (inbound) port of the input port 102 and receives input data to be passed to the MAC layer. The MAC layer can perform known functions such as frame delimitation and identification, addressing of the destination station, communication of source station addressing information, transparent data transfer of information in the Ethernet sublayer, error prevention, and access control to the physical transmission medium. The inbound packet processing pipeline 120 may include several processing pipelines, each connected to the MAC layer of the inbound MAC and interface block 110 and the memory management and crossbar unit 130. In some implementations, the flow detection and management of the present technique may be implemented only once, regardless of the number of pipelines on a chip, such as within the memory management and crossbar unit 130. In other implementations, the flow detection and management of the present technique may replace the memory management and crossbar unit 130. The output packets from the memory management and crossbar unit 130 are processed by the outbound packet processing pipeline 140 and passed to the output port 104 through the outbound MAC and interface block 150.

[0021] Figure 2is a block diagram illustrating limiting aspects of an example of an existing long flow detection system 200. In the existing long flow detection system 200, a first host A (e.g., located in San Jose, California) is connected to a first router R1, which in turn is connected to routers R2, R3, R4, and R5. Routers R2 and R3 are connected to ports P1 and P27 of router R6, and routers R4 and R5 are connected to router R7. Routers R6 and R7 are connected to a second host B (e.g., located in Seattle, Washington). The router contains information about the queue loading of the port and / or only its own port. For the case where the flow from host A to host B passes through a path composed of routers R1, R2, and R6, port P1 of router R6 falls within pipeline 0 of router R6, and router R6 may include 16 pipelines each having, for example, 16 ports (e.g., P1 to P16). Therefore, the long flow detection and management logic associated with port 0 of router R6 will analyze the flow in router R6. In another case, if for some reason the flow from host A changes path and continues to host B through routers R1, R3, R6, then the long flow detection and management logic in pipeline 0 of router R6 will no longer see that flow because port 27 falls within pipeline 2 of router R6. Therefore, pipeline 0 will not be able to detect that flow, which illustrates the limitation of existing long flow detection methods.

[0022] Figure 3 1 is a high-level block diagram illustrating an example of an aggregated long flow detection system 300 in accordance with various aspects of the present technology. The example aggregated long flow detection system 300 includes, but is not limited to, four pipelines—Pipeline 0, Pipeline 1, Pipeline 2, and Pipeline 3—implemented on a semiconductor chip. Each of Pipeline 0, Pipeline 1, Pipeline 2, and Pipeline 3 is connected to a quarter of the ports on the semiconductor chip, for example, to the first quarter, the second quarter, the third quarter, and the fourth quarter of the ports, respectively. A central long flow detection and management logic 302 is connected to the pipelines (Pipeline 0, Pipeline 1, Pipeline 2, and Pipeline 3) and receives data from (for example, Figure 1 The inbound MAC and interface block 110) port interface and MMU (e.g. Figure 1130) receives status and loading information. The central long flow detection and management logic 302 uses the information received from the port interface and the MMU to analyze and manage long flows in order to reduce traffic congestion, packet loss, and tail latency. For each data packet that passes through one or more of pipeline 0, pipeline 1, pipeline 2, and pipeline 3, each of the pipelines may provide information related to several subjects to the central long flow detection and management logic 302. The information may, for example, be related to the number of bytes in the data packet at the flow (e.g., 5-tuple), the inbound port, the outbound port, and / or the end of packet (EOP), which is tracked across the chip by the long flow detection logic.

[0023] In some embodiments, each pipeline (Pipeline 0, Pipeline 1, Pipeline 2, and Pipeline 3) may also compare the accumulated byte count per flow to a configurable byte count and time period threshold to detect long flows, report detected long flows, and support aging of detected long flows at configurable intervals. In one or more embodiments, the long flow detection and management logic 302 supports any protocol regardless of whether the data packet length is available at the SOP, and may be enabled to track flow hashes (e.g., 16-bit flow hashes) only when the corresponding egress port is congested and / or loaded to a certain threshold within a time interval threshold. In some embodiments, each pipeline may report detected long flows to software using first-in-first-out (FIFO) direct memory access (DMA), and may utilize the tracked flow hashes to separate or distribute detected long flows using a load-aware ECMP structure.

[0024] Figure 4 4 is a block diagram illustrating an example of an aggregated long flow detection system 400 according to various aspects of the present technology. The aggregated long flow detection system 400 (hereinafter system 400) is Figure 3 4 is an example implementation of an aggregate long flow detection system 300. System 400 includes a flow table 410, a number of byte counters 412, and flow aging and / or eviction logic 420. System 400 may further use a configuration (config) space 430, port loading information (info) 440, and load-aware ECMP structures and / or next hop (NH) information 450. System 400 receives input data 402 and 404 and provides output 460. Input data 402 may include (but is not limited to) from each pipeline (e.g., Figure 3 The flow information may also include counts (e.g., a 5-tuple) corresponding to different values ​​of a transmission control protocol (e.g., Transmission Control Protocol / Internet Protocol (TCP / IP)), a source port address, a destination port address, and an associated transmission protocol.

[0025] The byte count consists of the number of bytes in each data packet at the EOP, which enables long flow detection to support any protocol regardless of whether the data packet length is available at the SOP. Input data 404 may include, but is not limited to, inbound ports (e.g. Figure 1 102) and outbound ports (such as Figure 1 104) and / or from the MMU from each pipeline (e.g. Figure 1 130) and port interfaces (e.g. Figure 1 110 and 150) of the associated queues and loading information. The flow information and aggregate byte counts from all pipelines are stored in the flow table 410 and the byte counter 412, respectively, and are used by the flow aging / evicting logic 420 to manage the flows by detecting and managing any long flows. In some embodiments, the flow aging / evicting logic 420 tracks flows across the chip by comparing the byte count accumulated per flow with a configurable byte count and time period threshold to detect long flows, report detected long flows, and support aging of detected long flows at configurable intervals. The flow aging / evicting logic 420 is agnostic to flows that change the inbound port of a given router.

[0026] The centralized aggregated long flow detection and management logic of the present technology as implemented by system 400 includes several advantageous features. For example, detected long flows can be reported to enable their quality of service to be changed by software (S / W), and detected long flows can also be separated or distributed across desired paths using a load-aware ECMP structure without changing the service class (COS) of the data packet. Flow detection logic (e.g., flow aging / eviction logic 420) can be implemented only once at a fraction of the cost of current implementations, regardless of the number of pipelines on the chip. The long flow detection and management of the present technology is agnostic to changes in the flow of the inbound port on a given router. According to the nature of the implementation, the disclosed long flow detection and management is aggregated across all pipelines. Once the corresponding outbound port is congested / loaded to a certain threshold level for the duration of the time interval threshold, the present long flow detection logic can be configured to start tracking flow hashes.

[0027] Figure 5 5 is a diagram illustrating an example of a flow management scheme 500 using load-aware ECMP mapping. The flow management scheme 500 uses an ECMP group table 510, which provides group base value and size information 512 to ECMP members and a hit bit table 520. Information 512 identifies a group base value 522 and a group size of four, which includes NH2, NH1, NH2, and NH1. The central state machine can consider the instantaneous load on the ports and / or queues corresponding to the NHs and any bias / weight / vector programmed into the parameters beyond this hop, and then select the optimal NH for each entry and the secondary and tertiary NHs. Protection switch logic can be applied to optimally select the secondary and tertiary NHs.

[0028] Figure 6 6 is a flow chart illustrating an example of an aggregate long flow detection process 600 according to some aspects of the present technology. The aggregate long flow detection process 600 is implemented in three parallel routes 610, 620, and 630. Route 610 includes operation blocks 612 and 614. At operation block 612, the long flow detection logic (e.g., Figure 3 303) receives real-time updates for each data packet, including flow information, inbound port, outbound port, and number of bytes. At operation block 614, the long flow detection logic checks each data packet from a given pipeline to determine if an associated flow entry exists. If not, then a flow entry is created and the corresponding counter(s) are updated. If the flow entry exists, then any changes to the inbound / outbound ports and corresponding counter(s) are updated. Optionally, the long flow detection logic (e.g., Figure 4 420) can be configurably enabled to track flow hashes.

[0029] Routing 620 includes operation blocks 622 and 624. At operation block 622, the long flow detection logic compares the accumulated byte count per flow to a configurable byte count and time period threshold. Next, at operation block 624, the corresponding inbound pipeline is notified of the detected long flow so that it can take programmed actions (e.g., update service class, etc.) and / or send flow information to the S / W. In some implementations, the byte counts for a given flow from all pipelines and different filters are aggregated.

[0030] Routing 630 includes operation blocks 632 and 634. At operation block 632, the long flow detection logic proceeds entry by entry and aggregates the counts for a given flow from all pipelines and different filters. At operation block 634, if there are no updates for a given flow or the byte count is below the corresponding programmed threshold for a programmed duration or congestion on the outbound port is relieved (if this mode is enabled), the flow is aged / evicted to save table space. At operation block 636, the corresponding inbound pipeline is notified of the aged or evicted long flow to take programmed actions and / or send the flow to software, and then control is passed to operation block 632. In some embodiments, individual pipelines may be configured to automatically increment or decrement the priority level of data packets in detected long flows.

[0031] Figure 77 is a flow chart illustrating an example of a long flow management process 700 in accordance with some aspects of the present technology. The aggregate long flow management process 700 begins at operation block 710, where the long flow detection logic already has information about the long flow and the corresponding flow hash. The long flow detection logic collects additional information about the ECMP group size and the corresponding next hop. Next, at operation block 720, the long flow detection logic uses the information (information about the long flow, the corresponding flow hash, and the additional information about the ECMP group size and the corresponding next hop) to automatically derive the desired destination port (and in turn automatically derive the next hop) to separate or distribute the long flow (if configurably enabled to do so). The desired destination port corresponds to the location derived by the long flow hash ECMP group size.

[0032] Figure 8 800 in which some aspects of the present technology may be implemented. The electronic system 800 may be a network switch and / or a portion of a network switch for a data center or enterprise network. The electronic system 800 may include various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 800 includes a bus 808, one or more processing units 812, a system memory 804 (and / or buffers), a ROM 810, a permanent storage device 802, an input device interface 814, an output device interface 806, and one or more network interfaces 816, or subsets and variations thereof.

[0033] The bus 808 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 800. In one or more embodiments, the bus 808 communicatively connects the one or more processing units 812 with the ROM 810, the system memory 804, and the permanent storage device 802. The one or more processing units 812 retrieve instructions to be executed and data to be processed from these various memory units in order to perform the processes of the present disclosure. In different embodiments, the one or more processing units 812 can be a single processor or a multi-core processor. In one or more aspects, the one or more processing units 812 can represent Figure 3 The long flow detection and management logic 302 is used to implement Figure 6 and / or 7 processes.

[0034] ROM 810 stores static data and instructions required by one or more processing units 812 and other modules of the electronic system 800. On the other hand, permanent storage 802 can be a read-write memory device. Permanent storage 802 can be a non-volatile memory unit that stores instructions and data even when the electronic system 800 is turned off. In one or more implementations, a mass storage device (such as a magnetic or optical disk and its corresponding magnetic disk drive) can be used as permanent storage 802.

[0035] In one or more embodiments, a removable storage device (such as a floppy disk, a flash drive and its corresponding disk drive) may be used as the permanent storage device 802. Similar to the permanent storage device 802, the system memory 804 may be a read-write memory device. However, unlike the permanent storage device 802, the system memory 804 may be a volatile read-write memory, such as a random access memory (RAM). The system memory 804 may store any of the instructions and data that one or more processing units 812 may need when running. In one or more embodiments, the processes of the present disclosure are stored in the system memory 804, the permanent storage device 802, and / or the ROM 810. The one or more processing units 812 retrieve instructions to be executed and data to be processed from these various memory units in order to perform the processes of one or more embodiments.

[0036] The bus 808 is also connected to input and output device interfaces 814 and 806. The input device interface 814 enables a user to communicate information and selection commands to the electronic system 800. Input devices that can be used with the input device interface 814 can include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 806 can enable, for example, the display of images generated by the electronic system 800. Output devices that can be used with the output device interface 806 can include, for example, a printer and a display device, such as a liquid crystal display, a light emitting diode display, an organic light emitting diode display, a flexible display, a flat panel display, a solid-state display, a projector, or any other device for outputting information. One or more implementations may include a device that is used as both an input device and an output device, such as a touch screen. In these implementations, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user in any form (including acoustic, voice, or tactile input) can be received.

[0037] Finally, if Figure 8 8, bus 808 also couples electronic system 800 to one or more networks and / or one or more network nodes via one or more network interfaces 816. In this manner, electronic system 800 may be part of a computer network (e.g., a local area network, a wide area network, an intranet, or a network of networks, such as the Internet). Any or all components of electronic system 800 may be used in conjunction with the present disclosure.

[0038] Implementations within the scope of the present disclosure may be implemented in part or in whole using a tangible computer-readable storage medium (or multiple tangible computer-readable storage media of one or more types) encoding one or more instructions.The tangible computer-readable storage medium may also be non-transitory in nature.

[0039] Computer-readable storage media may be any storage media that can be read, written, or otherwise accessed by a general or special purpose computing device, including any processing electronics and / or processing circuitry capable of executing instructions. By way of example, and not limitation, computer-readable media may include any volatile semiconductor memory, such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM. Computer-readable media may also include any non-volatile semiconductor memory, such as ROM, PROM, EPROM, EEPROM, NVRAM, Flash, nvSRAM, FeRAM, FeTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, racetrack memory, FJG, and millipede memory.

[0040] Furthermore, the computer-readable storage medium may include any non-semiconductor memory, such as optical disk storage, magnetic disk storage, magnetic tape, other magnetic storage, or any other medium capable of storing one or more instructions. In one or more implementations, the tangible computer-readable storage medium may be directly coupled to the computing device, while in other implementations, the tangible computer-readable storage medium may be indirectly coupled to the computing device, for example, via one or more wired connections, one or more wireless connections, or any combination thereof.

[0041] Instructions may be directly executable or may be used to develop executable instructions. For example, instructions may be implemented as executable or non-executable machine code or instructions in a high-level language that may be compiled to generate executable or non-executable machine code. In addition, instructions may also be implemented as data or may include data. Computer executable instructions may also be organized in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, and functions, etc. As will be appreciated by those skilled in the art, the details including, but not limited to, the number, structure, sequence, and organization of instructions may vary significantly without changing the underlying logic, functionality, processing, and output.

[0042] Although the above discussion mainly involves a microprocessor or multi-core processor that executes software, one or more implementations are performed by one or more integrated circuits such as ASICs or FPGAs. In one or more implementations, this integrated circuit executes instructions stored on the circuit itself.

[0043] It should be understood by those skilled in the art that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms are generally described above in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Those skilled in the art may implement the described functionality in different ways for each specific application. The various components and blocks may be arranged differently (e.g., arranged in different orders or partitioned in different ways), all without departing from the scope of the present technology. In addition, the various functional blocks do not need to be directly connected (even if they are illustrated as such in the figure for convenience).

[0044] It should be understood that any specific order or hierarchy of blocks in the disclosed process is an illustration of an example method. Based on design preferences, it should be understood that the specific order or hierarchy of blocks in the process can be rearranged, or all blocks of the illustration can be executed. Any of the blocks can be executed simultaneously. In one or more embodiments, multitasking and parallel processing can be advantageous. In addition, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0045] As used in this specification and any claims of this application, the terms "base station", "receiver", "computer", "server", "processor" and "memory" all refer to electronic or other technical devices. These terms exclude people or groups of people. For the purposes of this specification, the term "display" or "displaying" means displaying on an electronic device.

[0046] As used herein, the phrase "at least one" preceding a series of items (where the terms "and" or "or" separate any of the items) modifies the entire list, rather than each member of the list (i.e., each item). The phrase "at least one of" does not require selection of each of each of the listed items; rather, the phrase allows for a meaning that includes at least one of any of the items and / or at least one of any combination of items and / or at least one of each of the items. By way of example, the phrase "at least one of A, B, and C" or "at least one of A, B, or C" each refers to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0047] The predicates "configured to," "operable to," and "programmed to" do not imply any specific tangible or intangible modification of the subject, but are intended to be used interchangeably. In one or more embodiments, a processor configured to monitor and control an operation or component also means that the processor is programmed to monitor and control the operation or the processor is operable to monitor and control the operation. Likewise, a processor configured to execute code may be constructed as a processor programmed to execute code or operable to execute code.

[0048] Phrases such as "on one hand," "the aspect," "on the other hand," "some aspects," "one or more aspects," "an embodiment," "the embodiment," "another embodiment," "some embodiments," "one or more embodiments," "an example," "the example," "another example," "some examples," "one or more examples," "a configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," "the present technology," "the disclosure / the present disclosure," and other variations and the like are for convenience and do not imply that the disclosure associated with such phrases is essential to the present technology or that the disclosure applies to all configurations of the present technology. The disclosure associated with such phrases may apply to all configurations or one or more configurations. The disclosure associated with such phrases may provide one or more examples. Phrases such as one hand or some aspects may refer to one or more aspects, and vice versa, and similarly apply to the other aforementioned phrases.

[0049] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, to the extent that the term "including," "having," or the like is used in the description or claims, this term is intended to be inclusive in a manner similar to the term "comprising," as "comprising" is interpreted when used as a transition word in a claim.

[0050] All structures and functions equivalent to the elements throughout the various aspects described in this disclosure that are known or later become known to one of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is expressly recited in the claims. A claim element will not be interpreted under 35 U.S.C. §112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”

[0051] The previous description is provided to enable those skilled in the art to practice the various aspects described herein. Those skilled in the art will readily appreciate the various modifications to these aspects, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but should conform to the full scope consistent with the language claims, wherein unless expressly stated, references to elements in the singular are not intended to mean "one and only one", but rather "one or more". Unless expressly stated otherwise, "some" refers to one or more. Positive pronouns (e.g., his) include negative and neutral (e.g., her and its), and vice versa. Titles and subtitles, if any, are used for convenience only and do not limit the present disclosure.

Claims

1. A semiconductor chip for implementing aggregate flow detection and management, the semiconductor chip comprising: a plurality of pipelines, each pipeline coupled to a portion of a port on the semiconductor chip configured to receive a data packet; and logic coupled to the plurality of pipelines and configured to detect and manage long flows, Wherein the logic comprises a flow table and a byte counter, wherein the logic is configured to: For each data packet, receiving flow information, an inbound port, and an outbound port in the data packet; receiving, from the port, real-time updates on flow information for the data packets; detecting and managing the long flow based at least on the flow information; In response to evicting the flow, notifying the corresponding inbound port to at least one of: take a programmed action or send the evicted flow into software. 2 . The semiconductor chip of claim 1 , wherein the logic is configured to receive, for each data packet, a count of bytes in the data packet. 3 . The semiconductor chip of claim 2 , wherein the flow information includes counts corresponding to different values ​​of a transmission control protocol, a source port address, a destination port address, and an associated transmission protocol.

4. The semiconductor chip of claim 2 , wherein the count of the bytes in the data packet is derived from an end-of-packet (EOP) and is used to enable flow detection support associated with a transport protocol regardless of the availability of the data packet length in a header byte of the transport protocol.

5. The semiconductor chip of claim 1, wherein the logic further comprises flow aging logic implemented on the semiconductor chip, wherein the entire logic is implemented once on the semiconductor chip regardless of pipeline count on the semiconductor chip and is aggregated across all pipelines on the semiconductor chip. 6 . The semiconductor chip of claim 5 , wherein the logic is configured to track flow across the semiconductor chip to detect the long flow.

7. The semiconductor chip of claim 6, wherein the logic is configured to track the flows across the semiconductor chip by comparing accumulated byte counts per flow to a configurable byte count and time period threshold to detect the long flows.

8. The semiconductor chip of claim 7 , wherein the logic is further configured to report the detected long flows and support aging of the detected long flows at configurable intervals, wherein the flow aging logic is configured to evict the flows if there are no updates to the flows, the accumulated byte count per flow is below a corresponding programmed threshold for a programmed duration, or traffic congestion on an egress port is alleviated.

9. The semiconductor chip of claim 7, wherein the logic is agnostic to long flows changing ingress ports of a given router. 10 . The semiconductor chip of claim 1 , wherein each pipeline of the plurality of pipelines is configured to provide a flow hash calculated with respect to the flow information.

11. The semiconductor chip of claim 10, wherein the logic is configured to track the flow hash when a corresponding egress port is congested and / or loaded to a certain threshold within a predefined time interval. 12 . The semiconductor chip according to claim 10 , wherein the flow table comprises a load-aware equal cost multi-path (ECMP) group table including group base value and size information.

13. A method for detecting and managing aggregated flows, the method comprising: configuring a pipeline of a plurality of pipelines disposed on a semiconductor chip to receive a data packet from a port of a plurality of ports of the semiconductor chip; coupling logic to the plurality of pipelines; and Configure the logic to: receiving real-time updates on flow information from the plurality of ports for the data packets; Detecting and managing long flows based on at least the flow information; When information about long flows and corresponding flow hashes exists, additional information about the ECMP group size and the corresponding next hop is collected; using information about the long flows and the corresponding flow hashes to automatically derive desired destinations to separate or distribute the long flows; as well as In response to evicting the flow, notifying the corresponding inbound port to at least one of: take a programmed action or send the evicted flow into software.

14. The method of claim 13, further comprising configuring the logic to receive real-time updates regarding counts of inbound ports, outbound ports, and bytes in the data packets.

15. The method of claim 14, further comprising configuring the logic to: deriving said count of said bytes in said data packet from an EOP, and Enables support for detection of transport protocols regardless of the availability of data packet length.

16. The method of claim 13, further comprising configuring the logic to: Check each data packet from a given pipeline to determine if there is an associated flow entry, and When the associated flow entry does not exist, a corresponding counter is created and updated.

17. A method for detecting and managing aggregated flows, the method comprising: configuring a pipeline of a plurality of pipelines disposed on a semiconductor chip to receive a data packet from a port of a plurality of ports in the semiconductor chip; coupling logic to the plurality of pipelines; as well as Configure the logic to: receiving real-time updates on flow information from the plurality of ports for the data packets; detecting and managing long flows based on at least the flow information; examining each data packet from a given pipeline to determine if an associated flow entry exists; When the associated flow entry does not exist, creating and updating a corresponding counter; When the associated flow entry exists, updating changes to the inbound port and / or outbound port and corresponding counters, Compares the accumulated byte count per flow to configurable byte count and time period thresholds, Notify the corresponding inbound pipeline to take programmed actions or send the flow information to the software, Aggregate byte counts for a given stream from all pipelines and different filters; and If there are no updates to the flow or the aggregated byte count is below the corresponding programmed threshold for a programmed duration or traffic congestion on the egress port is alleviated, the flow is evicted.

18. The method of claim 17, further comprising configuring the logic to: When information about long flows and corresponding flow hashes exists, additional information about the ECMP group size and the corresponding next hop is collected; Using information about the long flows and the corresponding flow hashes to automatically derive desired destinations to separate or distribute the long flows; and In response to evicting the flow, notifying the corresponding inbound port to at least one of: take the programmed action or send the evicted flow into software.

19. A system for implementing aggregate flow detection and management, comprising: Memory; and One or more processors coupled to the memory and configured to execute instructions to perform actions including: receiving data packets from a plurality of ports of the semiconductor chip by a pipeline of a plurality of pipelines disposed on the semiconductor chip; receiving, by logic, real-time updates regarding flow information regarding the data packets from the plurality of ports; and detecting and managing long flows based at least on the flow information, When information about long flows and corresponding flow hashes exists, additional information about the ECMP group size and the corresponding next hop is collected; using information about the long flows and the corresponding flow hashes to automatically derive desired destinations to separate or distribute the long flows; as well as In response to evicting the flow, notifying the corresponding inbound port to perform at least one of: taking a programmed action or sending the evicted flow to software; Wherein the logic is coupled to the plurality of pipelines.

20. A system for implementing aggregate flow detection and management, comprising: Memory; and One or more processors coupled to the memory and configured to execute instructions to perform actions including: receiving data packets from a plurality of ports of the semiconductor chip by a pipeline of a plurality of pipelines disposed on the semiconductor chip; receiving, by logic, real-time updates regarding flow information regarding the data packets from the plurality of ports; detecting and managing long flows based at least on the flow information, wherein the logic is coupled to the plurality of pipelines; as well as When data traffic congestion occurs at the corresponding egress port, tracking the flow hash; When a long flow is detected, notify the corresponding pipeline to record the complete flow information corresponding to the flow hash; configuring a separate pipeline to automatically increment or decrement the priority of data packets in a detected long flow; causing the corresponding pipeline to report the detected long flow to software using a first-in-first-out (FIFO) direct memory access (DMA); and The flow hashing is utilized to separate or distribute the detected long flows across a desired destination port or a selected set of destination ports using a load-aware ECMP structure.

Images