Scalable method for internal package generation

Abstract

The embodiment of the invention relates to a scalable method for internal package generation. An apparatus for scalable interior package generation is provided. The apparatus includes one or more entry points, one or more internal packet sources configured to generate one or more second packets, and a memory management unit. The memory management unit includes an internal queuing engine and merge function logic. The internal queuing engine is configured to obtain the one or more second packets from one or more internal packet sources and queue each of the one or more second packets in a respective one of the one or more first queues. Arbitration logic is configured to determine an order in which the one or more second packets are dequeued from the one or more first queues. Merging function logic is configured to combine the one or more second packets with one or more first packets from the internal queuing engine.

Description

[0001] Copyright Notice

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. TECHNICAL FIELD

[0003] The present disclosure relates generally to methods, systems, and apparatuses for internal packet generation in network switches. BACKGROUND

[0004] In addition to externally-arriving packets, various sources of internally-generated packets can also be enqueued and routed according to some known queuing scheme. The average traffic rate of internally-generated packets is typically much lower than its instantaneous bandwidth, which is on the same order as the switch bandwidth. A brute-force approach to enqueuing packets results in a doubling of the enqueuing bandwidth, which is expensive in terms of both area and power.

[0005] Accordingly, a scalable internal packet generation scheme is provided. SUMMARY

[0006] One embodiment of the present disclosure provides an apparatus comprising one or more ingress points configured to receive one or more first packets from one or more external sources; one or more internal packet sources configured to generate one or more second packets; and a memory management unit comprising an internal queuing engine coupled to the one or more internal packet sources. The internal queuing engine comprises one or more first queues, wherein the internal queuing engine is configured to obtain the one or more second packets from the one or more internal packet sources and enqueue each of the one or more second packets in a respective first queue of the one or more first queues; and arbitration logic configured to determine an order in which the one or more second packets are to be dequeued from the one or more first queues based at least in part on an arbitration scheme. The apparatus further comprises merge function logic configured to combine the one or more second packets from the internal queuing engine with the one or more first packets.

[0007] Another embodiment of the present disclosure provides a network device comprising: one or more ingress points configured to receive one or more external packets from one or more external sources; one or more internal packet sources configured to generate one or more internal generated packets; and a memory management unit comprising: a traffic manager configured to receive the one or more external packets and the one or more internal generated packets. The traffic manager comprises: an internal queuing engine coupled to the one or more internal packet sources, the internal queuing engine comprising: one or more internal packet queues, wherein the internal queuing engine is configured to obtain the one or more internal generated packets from the one or more internal packet sources and enqueue each of the one or more internal generated packets in a respective internal packet queue of the one or more internal packet queues; and arbitration logic configured to determine an order in which the one or more internal generated packets are to be dequeued from the one or more internal packet queues based at least in part on an arbitration scheme. The network device further comprises merge function logic configured to combine the internal generated packets from the internal queuing engine with the external packets.

[0008] Yet another embodiment of the present disclosure provides a memory management unit comprising: a traffic manager configured to receive one or more external packets and one or more internal generated packets, wherein the traffic manager comprises: an internal queuing engine coupled to one or more internal packet sources. The internal queuing engine comprises: one or more internal packet queues, wherein the internal queuing engine is configured to obtain the one or more internal generated packets from the one or more internal packet sources and enqueue each of the one or more internal generated packets in a respective internal packet queue of the one or more internal packet queues; arbitration logic configured to determine an order in which the one or more internal generated packets are to be dequeued from the one or more internal packet queues based at least in part on an arbitration scheme; and merge function logic configured to combine the internal generated packets from the internal queuing engine with the external packets received from the one or more external sources. BRIEF DESCRIPTION OF DRAWINGS

[0009] A further understanding of the nature and advantages of certain embodiments can be realized by reference to the remaining portions of the specification and the drawings, wherein like reference numerals are used throughout. In some instances, sub-labels are associated with reference numerals to denote one of multiple similar components. When reference is made to a reference numeral without indication of an existing sub-label, it is intended to refer to all such multiple possible similar components.

[0010] Figure 1 is a schematic block diagram of a network switch according to various embodiments;

[0011] Figure 2 is a schematic block diagram of a traffic manager of a network switch according to various embodiments;

[0012] Figure 3 is a schematic block diagram of an architecture for an internal packet queuing engine according to various embodiments; and

[0013] Figure 4 is a hardware block diagram of a computer system for a network switch having an internal packet queuing engine according to various embodiments. DETAILED DESCRIPTION

[0014] Various embodiments set forth a framework for enqueued and internally generated packets.

[0015] In some embodiments, an apparatus for scalable internal packet generation is provided. The apparatus includes one or more ingress points configured to receive one or more first packets from one or more external sources, one or more internal packet sources configured to generate one or more second packets, and a memory management unit. The memory management unit includes an internal queuing engine coupled to the one or more internal packet sources, and merge function logic. The internal queuing engine includes one or more first queues, where the internal queuing engine is configured to obtain the one or more second packets from the one or more internal packet sources and enqueue each of the one or more second packets in a respective first queue of the one or more first queues, and arbitration logic configured to determine an order in which to dequeue the one or more second packets from the one or more first queues based at least in part on an arbitration scheme. The merge function logic can be configured to combine the one or more second packets from the internal queuing engine with the one or more first packets.

[0016] In other embodiments, a network device having an internal packet queuing engine is provided. The network device includes one or more ingress points configured to receive one or more external packets from one or more external sources, one or more internal packet sources configured to generate one or more internally generated packets, and a memory management unit. The memory management unit includes a traffic manager configured to receive one or more external packets and the one or more internally generated packets. The traffic manager includes an internal queuing engine coupled to the one or more internal packet sources, and merge function logic. The internal queuing engine includes one or more internal packet queues, where the internal queuing engine is configured to obtain the one or more internally generated packets from the one or more internal packet sources and enqueue each of the one or more internally generated packets in a respective internal packet queue of the one or more internal packet queues, and arbitration logic configured to determine an order in which to dequeue the one or more internally generated packets from the one or more internal packet queues based at least in part on an arbitration scheme. The merge function logic is configured to combine the internally generated packets from the internal queuing engine with the external packets.

[0017] In other embodiments, a memory management unit for scalable internal packet generation is provided. The memory management unit includes a traffic manager configured to receive one or more external packets and one or more internally generated packets. The traffic manager includes an internal queuing engine coupled to one or more internal packet sources, and merge function logic. The internal queuing engine includes one or more internal packet queues, wherein the internal queuing engine is configured to obtain the one or more internally generated packets from the one or more internal packet sources and enqueue each of the one or more internally generated packets in a respective internal packet queue of the one or more internal packet queues, and arbitration logic configured to determine an order in which the one or more internally generated packets are to be dequeued from the one or more internal packet queues based at least in part on an arbitration scheme. The merge function logic is configured to combine the internally generated packets from the internal queuing engine with the external packets received from the one or more external sources.

[0018] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described. It will be apparent, however, to one skilled in the art that other embodiments can be practiced without some of these details. Numerous embodiments are described herein, and although the various features of the embodiments can be focused on one embodiment, the features of one embodiment can also be combined with the features of another embodiment. However, for the same reason, no single feature or several features of any described embodiment should be considered essential to every embodiment of the application, as other embodiments of the application can omit such features.

[0019] When an element is referred to as being "connected" or "coupled" to another element, it is understood that the element can be directly connected or coupled to the other element, or intervening elements can be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, it is understood that no intervening elements are present. The use of "directly" to describe the connection or coupling does not exclude the presence of intervening elements, however.

[0020] When an element is referred to as being "disposed" in some relationship to another element (e.g., disposed on, disposed between, disposed under, disposed adjacent to, or disposed in some other relative position to another element), it will be understood that the element can be directly disposed in the relative position (e.g., directly disposed on the other element), or intervening elements can be present between the elements. In contrast, when an element is referred to as being "directly disposed" in some relationship to another element, it will be understood that no intervening elements are present in the "direct" instance. The presence of the directly disposed instance does not exclude other instances in which intervening elements can be present, however.

[0021] Furthermore, the terms left, right, front, back, top, bottom, forward, rearward, clockwise and counterclockwise are used in this description only to explain the orientation of the items and / or components and are not limited to any fixed direction or orientation.

[0022] Furthermore, the methods and processes described herein can be described in a particular, sequential order. However, it should be understood that unless otherwise specifically stated, the intermediate processes can occur simultaneously with, or in different order than, the processes described. Further, various processes could be reordered, added, or omitted.

[0023] Unless otherwise indicated, all numbers expressing quantities, dimensions, and so forth used herein are to be understood as approximations based upon the nature of the items reported. In this application, the use of singulars "a," "an," and "the" include the plural unless otherwise stated. Also, the use of "and," "or," and "and / or" shall not be limited to a logical "and," or "or," unless such usage is specifically stated. Furthermore, the use of terms like "including," "including the," and "having," as well as other forms, such as "includes," "included," "has," "haves," and "had," is meant to be inclusive in a manner similar to the term "comprising" and "comprises" as an open transition term without precluding the possibility of other elements being present. Also, the use of the terms "a," "an," and "the" are inclusive of both singular and plural unless otherwise indicated.

[0024] As used herein, the phrase "at least one of a list of items" followed by the conjunction "and / or" refers to the options of either one or more than one of the items in the list of items. The phrase "at least one of a list of items" followed by the conjunction "and / or" does not mean "at least one of each member of the list of items" (i.e., each item individually) unless specifically stated otherwise. The phrase "at least one of a list of items" followed by the conjunction "and / or" allows for the selection of at least one of each member of the list of items individually, as well as the selection of any combination of the items in the list of items. For example, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" each mean A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together. In other words, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" each mean one or more of A, B, or C.

[0025] The bandwidth of a network switch is bounded by the amount of externally-arriving traffic that it can switch to respective outputs. In addition to switching external traffic, a network switch also enqueues and routes some internally-generated traffic (e.g., traffic generated by or within the network switch). Some examples of different packet types are replicated multicast packets (also referred to as multicast replicated packets), notification packets (e.g., to detect drops or congestion to support higher-layer end-to-end congestion management protocols), and network instrumentation packets. These internally-generated packets typically have very low average rates, but can be generated in bursts that can consume almost the full device bandwidth.

[0026] If the queuing logic attempts to provide full enqueuing bandwidth for both externally-arriving traffic and transient internally-generated traffic, the solution becomes very expensive in terms of area and power. Accordingly, a scalable internally-packet generation scheme is provided. In particular, a network switch is set forth below that includes an internal queuing engine (IQE) and arbitration logic. By exploiting the characteristics of internally-generated packets, the IQE can be utilized to enqueue internally-generated packets to final output queues. For example, the IQE can be configured to provide burst absorption points to group traffic into one or more IQE queues, and to arbitrate different types of traffic, and to rate limit internally-generated traffic.

[0027] Figure 1 is a schematic block diagram of a network switch 100 according to various embodiments. The network switch 100 (hereinafter simply "switch") includes one or more ingress points IP a - IP n , ingress packet processing 105, a memory management unit (MMU) 110, a traffic manager 115, an IQE 120, and egress packet processing 125 that can output traffic to one or more egress points. It is noted that the various elements of the switch 100 are schematically illustrated in Figure 1 , and modifications to the various components and other arrangements of the switch 100 can be possible and according to various embodiments.

[0028] In various embodiments, switch 100 is a network device configured to receive packets and forward packets to one or more respective destination nodes. In other embodiments, different network devices configured to provide switching functionality can be utilized, such as routers, hubs, gateways (e.g., residential gateways (RGs)), or access points (APs). Thus, as used herein, a network device can refer to a device on a computer network through which communication between devices (e.g., host devices and destination devices) is facilitated. While "switch" and "switching" are used herein when referring to packet switching functionality, it should be understood that in various embodiments, the terms "switch" and "switching" can further include "router" and "routing" functionality. As previously described, switching can generally refer to the process of receiving packets and forwarding those packets to respective destinations. For example, a network switch can forward traffic based on layer 2 addresses (e.g., media access controller (MAC) addresses). In various examples, a router can function as a network switch. Further, a router can route packets based on layer 3 addresses (e.g., Internet Protocol (IP) addresses) and according to a routing table. Further, while various examples refer to packets, it should be understood that in other embodiments, other types of protocol data units (PDUs) can be utilized, such as, but not limited to, cells, frames, datagrams, bridge PDUs, MAC PDUs, slices, bits, symbols, etc.

[0029] In various examples, switch 100 can include one or more ingress points IP a to IP n where IP a is a first ingress point and IP n is an nth ingress point of switch 100 (where n is an integer). As used herein, an ingress point refers to a location at which external data (e.g., external packets) enters a network device (e.g., switch 100). In some examples, an ingress point can be associated with a respective port of the switch. In some examples, each ingress point can be further associated with (e.g., mapped to) a respective MAC address from which external packets originate (e.g., a respective device having the respective MAC address). Similarly, switch 100 can include one or more egress points EP a to EP n where EP a is a first egress point and EP n is an nth egress point. As used herein, an egress point refers to a location at which data exits a network device (e.g., switch 100). Like ingress points, in some examples, an egress point can be associated with a respective port of the switch. In some examples, each ingress / egress point can share a respective port of the switch. For example, in some embodiments, first ingress point IP a is associated with first egress point EP athe same respective port of the shareable switch 100, and so on until the nth ingress point IP n and the nth egress point EP n .

[0030] In various examples, the switch 100 can include one or more processors, DSPs, application specific ICs (ASICs), FPGAs, or other programmable logic, or other processing circuitry configured to process and implement packet switching functions according to logic such as ingress packet processing 105, traffic manager 115, IQE 120, and / or egress packet processing 125, for example, such as MMU 110.

[0031] Traffic can be received by the switch 100 via one or more ingress points IP a to IP n In some examples, traffic received at one or more ingress points IP a to IP n may be combined into a common data stream for processing via ingress packet processing 105 and / or by MMU 110. For example, MMU 110 can process received traffic and store it in memory (external or internal), such as a buffer, and further retrieve data stored in memory for transmission. Ingress packet processing 105 can be configured to process ingress traffic for further processing by MMU. Thus, in various examples, ingress packet processing 105 can include logic configured to process traffic received from one or more ingress points IP a to IP n .

[0032] As used herein, logic can be implemented in hardware, software, or a combination of hardware and software, including firmware. Suitable hardware can include one or more processors, digital signal processors (DSPs), custom integrated circuits (ICs), programmable logic, such as field programmable gate arrays (FPGAs), and / or discrete logic.

[0033] Thus, in various examples, ingress packet processing 105 can be implemented as software executed on hardware of the switch 100, such as a processor, DSP, application specific IC (ASIC), FPGA, or in some other examples by MMU 110. In various embodiments, ingress packet processing 105 can include processing packets for later transmission. For example, ingress packet processing 105 can include determining an egress point EP a to EP nor corresponding port of switch 100. This can include parsing header information to determine a MAC address (or other address, such as an IP address), and determining a respective port through which data is to be transmitted. In some examples, determining a respective port through which data is to be transmitted includes looking up address information (e.g., MAC address, IP address, etc.) in a switching and / or routing table.

[0034] In some other examples, ingress packet processing 105 can further include reading and / or modifying packets, classifying packets, changing packet behavior, modifying or adding header information (e.g., packet headers, frame headers, etc.), encapsulating packets for transmission, duplicating packets, changing packet types, storing packets in buffers, or other modifications to packets.

[0035] In various examples, received ingress packets can be further processed for storage in memory by MMU 110. Thus, processed ingress packets output by ingress packet processing 105 can be obtained by MMU 110 for further processing. In various embodiments, MMU 110 includes a traffic manager 115 that further includes IQE 120. As previously described, MMU 110 can include hardware, such as a processor or other circuitry configured to handle memory storage operations (e.g., access, read, and / or write operations to memory), manage ingress data buffers, egress data buffers, admission control, queuing, and scheduling, as described below with respect to Figure 2 Traffic manager 115 is described in greater detail.

[0036] Traffic manager 115 can include logic within MMU 110 that is configured to handle memory access and storage of ingress traffic, storage of data within buffers including buffer access control, enqueuing of received packet data into respective logical queues, and dequeuing of packet data, among other features. Thus, traffic manager 115 can serve various functions for managing how ingress data and control data are stored / retrieved. In various embodiments, traffic manager 115 can include respective logic for handling packets received by switch 100. For example, in some embodiments, traffic manager 115 can include IQE 120, merge function logic, admission control logic, queuing logic, scheduling logic, etc. Traffic manager 115 can further include ingress and / or egress buffers for storing packets.

[0037] In various embodiments, the IQEs 120 are logic configured to process internally generated packets. For example, in various embodiments, the IQEs 120 can provide burst absorption points at which internally generated packets (or bursts of internally generated packets) can be received and stored in respective IQE buffers (interchangeably referred to as "IQE queues"). Thus, the IQEs 120 can sort internally generated packets into respective queues for storage. The IQEs 120 can further arbitrate internally generated packets stored in the IQE queues for output. Arbitration of internally generated packets can include determining an order of output packets according to arbitration logic. In some examples, packets can be arbitrated according to packet type and / or traffic class.

[0038] As used herein, a traffic class can refer to a type of traffic to which traffic is classified according to various parameters or characteristics of the traffic. For example, a packet (e.g., an internally generated packet) can belong to a traffic class such as, but not limited to, network instrumentation generated traffic (e.g., network instrumentation traffic / packets, telemetry traffic / packets, etc.), multicast traffic (e.g., multicast replication traffic / packets), notification traffic (e.g., notification traffic / packets such as congestion notifications, etc.), control plane traffic, management traffic, address resolution protocol (ARP) traffic, virtual local area network (VLAN) traffic, switch fabric traffic, quality of service (QoS) traffic, etc. Thus, in some examples, a traffic class can be defined based on a source address (e.g., MAC, IP, etc.), a destination address, a source application or originating network instrument, a priority assigned to the traffic (e.g., high priority traffic, real-time traffic, etc.), or other such classifications. In some examples, a traffic class can be determined based on a traffic classification identification (ID).

[0039] Thus, IQE data can be processed and classified into appropriate IQE queues based on traffic class. In some other examples, internally generated packets can be enqueued into respective IQE queues based on characteristics of the packets. In some examples, characteristics of the packets can include determining a packet type (e.g., replicated multicast packets, notification packets, network instrumentation packets, spanning tree protocol (STP) packets, ARP packets, link layer discovery protocol (LLDP) packets, Internet Control Message Protocol (ICMP) packets, Simple Network Management Protocol (SNMP) packets, etc.), a packet size, a packet priority, or a payload of the packet (e.g., real-time data or other low-latency data).

[0040] In some instances, the IQE queues for latency-sensitive protocol messages can be assigned as higher priority queues. For example, in some embodiments, instrumentation applications or proprietary end-to-end mechanisms can be more sensitive to latency. In other instances, control messages and congestion control protocol packets can similarly have higher priority based on response time expectations. Accordingly, corresponding internally generated packet types can be assigned higher priority. Conversely, in some instances, packets associated with telemetry applications, in-band telemetry, loss mirroring, etc. can be assigned to lower priority queues.

[0041] Accordingly, dequeuing refers to the process of removing packets stored in a respective queue (or buffer) for transmission by the switch to a destination (via a respective egress point / port). For example, dequeuing further ensures that packets are transmitted in the correct order, as described above.

[0042] The IQE 120 can further be configured to rate limit (e.g., limit the data rate) of internally generated packets that have been enqueued and dequeued and output by the IQE 120. For example, the IQE 120 can be configured to control the rate of internally generated packet output to the merge function logic of the traffic manager 115 based at least in part on the amount of ingress packets received by the switch 100. In other instances, the rate at which the IQE 120 outputs packets can be determined based at least in part on the bandwidth (e.g., instantaneous data rate, average data rate, etc.) of the switch 100. Furthermore, the order in which one or more IQE queues are dequeued can be controlled by the IQE 120. For example, in some embodiments, the dequeuing of one or more IQE queues can occur according to an arbitration scheme. Details regarding the arbitration scheme are described below with respect to Figure 3 Details of the IQE 120 are described in greater detail.

[0043] The packets can then be retrieved from the storage area by the MMU 110 (e.g., the traffic manager 115) and placed in egress buffers for further processing by the egress packet processing 125 and output by the switch 100. Like the ingress packet processing 105, the egress packet processing 125 can include logic to read and / or modify packets, classify packets, change packet behavior, modify or add header information (e.g., packet headers, frame headers, etc.), encapsulate packets for transmission, duplicate packets, change packet types, store packets in buffers, or other modifications to packets for downstream output.

[0044] Figure 2 is a schematic block diagram of an architecture of a traffic manager 200 for a MMU in accordance with various embodiments. The traffic manager 200 includes an IQE 205, a merge function logic 210, an admission control logic 215, and a queuing logic 220. It should be noted that the various elements of the traffic manager 200 are schematically illustrated in Figure 2In particular embodiments, and other modifications to the various components and other arrangements of the traffic manager 200 can be possible and in accordance with various embodiments.

[0045] In various embodiments, the traffic manager 200 can be logic executed, for example, by a MMU of a switch, such as the MMU 110 of the switch 100. The traffic manager 200 can include other logical blocks, such as the IQE 205, the merge function logic 210, the admission control logic 215, and the queuing logic 220. As previously described, the IQE 205 can be configured to manage internally generated packets and output the internally generated packets for queuing by the traffic manager.

[0046] In particular, the merge function logic 210 can be configured to combine (or merge) externally generated packets (e.g., traffic received at the ingress point IP a to the IP n point IP . Thus, in some instances, the merge function logic 210 can be configured to receive a stream of externally generated packets and internally generated packets and combine the externally generated packets with the internally generated packets into the same stream. In some instances, the merge function 210 can combine the externally generated packets with the internally generated packets via a multiplexer (e.g., time division multiplexing (TDM), space division multiplexing (SDM), etc.). In some instances, the internally generated packets can be inserted into the stream of externally generated packets. Thus, the output of the merge function can then be placed into a buffer (e.g., a packet buffer or an ingress buffer) for further processing by the traffic manager 200 / admission control logic 215.

[0047] The admission control logic 215 can be configured to determine whether a packet should be admitted into a packet buffer (or discarded) based on factors such as, for example, the fullness of the buffer (e.g., the fullness of an egress packet buffer) and the sharing of ports and / or queues (e.g., egress queues). Thus, the admission control logic 215 can allow a packet to be placed into a buffer.

[0048] Data admitted by the admission control logic 215 can then be enqueued via the queuing logic 220. The queuing logic 220 can be configured to enqueue data in the packet buffer into one or more output queues (also referred to as "logical queues"). For example, in some embodiments, packets in the packet buffer can be linked together into an output queue for a given port. For example, each port (or respective egress point) can have one or more logical queues. Packets can be enqueued by the queuing logic 220 into respective ones of the one or more logical queues. The queuing logic 220 can be further configured to dequeue packets from the respective one or more logical queues based on an arbitration scheme such as, but not limited to, strict priority, round robin (including weighted round robin), etc. Thus, in various instances, the queuing logic 220 can be configured to enqueue packets from the packet buffer into respective logical queues, and dequeue packets from the one or more logical queues for output. As used herein, a logical queue refers to a queue categorized based on a logical property (e.g., priority), order of arrival, address (or range of addresses), multicast or unicast requirements, destination or source, etc.

[0049] Figure 3 is a schematic block diagram of an architecture for an IQE 300 in accordance with various embodiments. The IQE 300 includes a multiplexer 305, one or more IQE queues 310a-310n, and arbitration logic 315. It should be noted that various elements of the IQE 300 are schematically illustrated in Figure 3 and modifications to various components and other arrangements of the IQE 300 can be possible and in accordance with various embodiments.

[0050] A switch (such as the switch 100) can be configured such that all sources of internally generated packets (also referred to as "internal packet sources") are enqueued into the IQE 300 at maximum capacity. For example, internally generated packets received via an IQE source can be coupled to the multiplexer 305, which can then output the packets to respective ones of the one or more IQE queues 310a-310n for storage. In particular, the multiplexer can include a first number of inputs, each respective input coupled to a respective internal packet source. The multiplexer can then include a second number of outputs, with each output coupled to a respective IQE queue. As used herein, an internal packet source refers to a source of internally generated packets (e.g., a component or process that generates the internally generated packets). For example, internal packet sources can include, but are not limited to, a control plane, a management plane, a switch fabric, a protocol handler, and other components of the switch 100.

[0051] Therefore, packets generated internally by the IQE can be processed and categorized into the appropriate IQE queue. As used herein, an IQE queue can refer to a queue used to store internally generated packets within the IQE (e.g., an "internal packet queue"). In some instances, internally generated packets may be queued into the appropriate IQE queue based on packet characteristics (e.g., the service category to which the packet belongs). In some instances, packet characteristics may include determining the packet type (e.g., replication multicast packets, notification packets, and network instrumentation packets), packet size, packet priority, or packet payload (e.g., real-time data or other low-latency data).

[0052] In some instances, IQE queues for waiting time-sensitive protocol messages can be assigned to higher-priority queues. For example, in some embodiments, instrumentation applications or dedicated end-to-end mechanisms may be more sensitive to latency. In other instances, control messages and congestion control protocol packets may similarly have higher priority based on expected response times. Therefore, the corresponding internally generated packet types can be assigned higher priority. Conversely, in some instances, packets associated with telemetry applications, in-band telemetry, packet loss mirroring, etc., may be assigned to lower-priority queues.

[0053] Therefore, in various embodiments, the switch (e.g.) Figure 1 The switch 100 can be configured such that all sources of internally generated packets are input to IQE 120 at maximum capacity. All sources of internally generated packets in the device can input their packets to IQE 300 at maximum capacity, which can absorb internally generated packets at its full data rate and store them in the corresponding IQE queues 310a to 310n. As previously described, one or more IQE queues 310a to 310n may contain separate queues for different types of services. For example, multicast replication packets and congestion packets may be stored in separate IQE queues.

[0054] Enqueued packets (on one or more IQE queues 310a to 310n) may be read out (e.g., dequeued) at a much lower rate relative to their enqueue rate. In some embodiments, the dequeue rate may be determined at least in part based on the average rate of internally generated packets (e.g., as a function of the average rate of internally generated packets). In contrast, the enqueue rate (e.g., the size of the burst absorption) may be determined by the traffic category and end-to-end analysis of these flows.

[0055] Arbitration logic 315 can be configured to determine which of the one or more IQE queues 310a-310n should be dequeued. In various embodiments, different types of arbitration schemes can be used to select the IQE queue to be dequeued. For example, arbitration schemes can include, but are not limited to, strict priority (e.g., based on packet characteristics or type of queue), round robin (or weighted round robin) of the one or more IQE queues 310a-310n, or other suitable arbitration schemes. By utilizing IQE 300, the footprint area and power consumption is lower than conventional brute force approaches. Moreover, by being able to add additional sources of internally generated packets and additional traffic (e.g., internally generated packets) that can be handled by IQE 300, IQE 300 has scaling capabilities.

[0056] Figure 4 A schematic illustration of one embodiment of a computer system 400 (e.g., switch 100) or a subsystem thereof (e.g., MMU 110, traffic manager 115, 200, and IQE 120, 205, 300), or a combination thereof, is provided which can perform the methods described herein provided by various other embodiments. It should be noted that, Figure 4 Only a generalized illustration of the various components is provided, with each of the components utilizing one or more of the components as necessary. Accordingly, Figure 4 The broadest possible implementation of how individual system elements can be implemented in a relatively separate or relatively more integrated manner is illustrated.

[0057] Computer system 400 includes a plurality of hardware elements that can be electrically coupled (or otherwise in communication) via bus 405. The hardware elements can include one or more processors 410, including but not limited to one or more general-purpose processors and / or one or more special-purpose processors (e.g., microprocessors, digital signal processing chips, graphics acceleration processors, and microcontrollers), one or more input devices 415, including but not limited to a mouse, a keyboard, one or more sensors, and / or the like, and one or more output devices 420, which can include but are not limited to a display device, and / or the like.

[0058] Computer system 400 can further include (and / or be in communication with) one or more storage devices 425, which can comprise, without limitation, local and / or network accessible storage, and / or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device such as a random access memory ("RAM") and / or a read-only memory ("ROM"), and / or a

[0059] Computer system 400 can also include a communication subsystem 430, which can include without limitation a modem, a network card (wireless or wired), an IR communication device, a wireless communication device, and / or chipset (such as a Bluetooth device, an 802.11 device, a WiFi device, a WiMax device, a WWAN device, a Z-wave device, a ZigBee device, cellular communication facilities, etc.) and / or LP wireless device, as previously described. Communication subsystem 430 can permit data to be exchanged with a network (such as the network described below, to name one example), with other computer systems or hardware systems, between data centers or different cloud platforms, and / or with any of the other devices described herein. In many embodiments, computer system 400 further includes a working memory 435, which can include a RAM or ROM device, as previously described.

[0060] Computer system 400 can also include software elements, shown as being currently located within working memory 435, including an operating system 440, device drivers, executable libraries, and / or

[0061] The set of instructions and / or code might be encoded and / or stored on a non-transitory computer-readable storage medium, such as storage device 425 described above. In some cases, the storage medium might be incorporated within a computer system, such as system 400. In other embodiments, the storage medium might be separate from a computer system (i.e., a removable medium, such as a flash memory, etc.), and / or provided in an installation package, such that the storage medium can be used to program, configure and / or adapt a general purpose computer with the instructions / code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 400 and / or might take the form of source code, which, upon compilation and / or installation on the computer system 400 (e.g., using any of a variety of generally available compilers, installation programs, compression / decompression utilities, etc.), then takes the form of executable code.

[0062] As will be evident to one of ordinary skill in the art, substantial variations can be made in accordance with specific requirements. For example, customized hardware (e.g., a programmable logic controller, a single-board computer, an FPGA, an ASIC, and a SoC) can also be used, and / or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input / output devices can be employed.

[0063] As mentioned above, in one aspect, some embodiments can employ a computer or hardware system (e.g., computer system 400) to perform methods according to various embodiments of the application. According to a set of embodiments, some or all of the procedures of such methods are performed by computer system 400 in response to processor 410 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 440 and / or other code, such as an application program 445) contained in the working memory 435. Such instructions can be read into the working memory 435 from another computer readable medium, such as one or more of the storage device(s) 425. The reader will recognize that the instructions that execute the sequences of instructions described herein can be written in any variety of programming languages. The instructions might be written in any programming language, including C, C++, Java, Visual Basic, Python, JavaScript, Flash or other languages. The machine executable instructions might be written as 32-bit or 64-bit instructions, according to one set of embodiments. Alternatively, various virtualization layers and / or virtual machines can be employed to execute the sequences of instructions written in a high-level language and therefore accessible which a variety of hardware platforms.

[0064] In embodiments implemented using the computer system 400, various computer- readable media might be involved in providing instructions / code to processor 410 for execution and / or might be used to store and / or transport such instructions / code (e.g., as a signal). In many implementations, a computer-readable medium is a physical and / or tangible storage medium. In some embodiments, a computer-readable medium might be an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system, apparatus, or device. More specific examples (a non- exhaustive list) of computer-readable media include nonvolatile, hard-coded and / or unalterable media (e.g., optical and / or magnetic disks, and the like), volatile media (e.g., memory, including dynamic and / or static random access memory), cache, and / or the like. In some embodiments, computer-readable media might include transmission media, such as coaxial cables, copper wire, and fiber optics, including the wires that comprise the bus 405, as well as the various components of the communication subsystem 430 (and / or the media used to provide those connections). In an alternative set of embodiments, functional

[0065] Various forms of computer-readable media can be involved in carrying one or more sequences of one or more instructions to the processor(s) 410 for execution. Merely by way of example, the instructions can initially be carried on a magnetic disk and / or optical disc of a remote computer. A remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and / or executed by the computer system 400. These signals, which might be in the form of electromagnetic signals, acoustic signals, optical signals, and / or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with the various embodiments of the present application.

[0066] The communication subsystem 430 (and / or components thereof) generally receives signals, and the bus 405 then carries the signals (and / or data, instructions, and / or the like carried by the signals) to the working memory 435, from which the processor(s) 410 retrieves and executes the instructions. The instructions received by the working memory 435 can optionally be stored on a storage device 425 either before or after execution by the processor(s) 410.

[0067] While certain features and aspects have been described with respect to embodiments, one skilled in the art will recognize that modifications are possible. For example, while various methods and processes described herein can be described with respect to particular architectures and / or functional components, the methods provided by various embodiments are not limited to any particular structural and / or functional architecture, but instead can be implemented on any suitable hardware configuration. Similarly, while some functionality is ascribed to one or more system components, unless the context demands otherwise, this functionality can be distributed among different components in accordance with various embodiments.

[0068] Moreover, while the procedures of the methods and processes described herein are described in a particular order for ease of explanation, unless the context demands otherwise, various procedures can be reordered, added, and / or omitted in accordance with various embodiments. Moreover, the procedures described with respect to one method or process can be incorporated into other described methods or processes; likewise, system components described with respect to one system can be organized in alternative structural architectures and / or incorporated into other described systems. Thus, while the foregoing descriptions set forth embodiments with or without certain features for the purpose of illustration and description, the various components and / or features of the described embodiments are not limited to the embodiments described herein, but can be substituted for one another, added, and / or omitted in various embodiments. Accordingly, although specific embodiments have been described herein, these are not intended to limit the scope of the present application, as described in the following claims.

Claims

1. An apparatus comprising: one or more ingress points configured to receive one or more first packets from one or more external sources; one or more internal packet sources configured to generate one or more second packets; a memory management unit comprising: an internal queuing engine coupled to the one or more internal packet sources, the internal queuing engine comprising: one or more first queues, wherein the internal queuing engine is configured to obtain the one or more second packets from the one or more internal packet sources and enqueue each of the one or more second packets in a respective first queue of the one or more first queues; arbitration logic configured to determine an order in which the one or more second packets are to be dequeued from the one or more first queues based at least in part on an arbitration scheme; and merge function logic configured to combine the one or more second packets from the internal queuing engine with the one or more first packets.

2. The apparatus of claim 1, wherein each respective first queue of the one or more first queues is configured to store second packets of a respective traffic class, wherein enqueuing the one or more second packets comprises enqueuing the one or more second packets based at least in part on the respective traffic class of each of the one or more second packets.

3. The apparatus of claim 2, wherein a first queue of the one or more first queues is configured to store one or more second packets of a first traffic class.

4. The apparatus of claim 1, wherein the respective traffic class is one of network instrumentation traffic, multicast traffic, or notification traffic.

5. The apparatus of claim 1, wherein the arbitration scheme includes strict priority or weighted round robin.

6. The apparatus of claim 1, wherein the internal queuing engine further comprises a multiplexer, the multiplexer comprising: a first number of inputs, each input of the first number of inputs coupled to a respective internal packet source of the one or more internal packet sources; and a second number of outputs, each output of the second number of outputs coupled to a respective first queue of the one or more first queues.

7. The apparatus of claim 1, wherein internal queuing engine is configured to rate limit the output of the one or more second packets from the one or more first queues based at least in part on an amount of first packets received at the one or more ingress points.

8. A network device comprising: one or more ingress points configured to receive one or more external packets from one or more external sources; one or more internal packet sources configured to generate one or more internally generated packets; a memory management unit comprising: a traffic manager configured to receive one or more external packets and the one or more internally generated packets, wherein the traffic manager comprises: an internal queuing engine coupled to the one or more internal packet sources, the internal queuing engine comprising: one or more internal packet queues, wherein the internal queuing engine is configured to obtain the one or more internally generated packets from the one or more internal packet sources and enqueue each of the one or more internally generated packets in a respective internal packet queue of the one or more internal packet queues; arbitration logic configured to determine an order in which to dequeue the one or more internally generated packets from the one or more internal packet queues based at least in part on an arbitration scheme; and merge function logic configured to combine the internally generated packets from the internal queuing engine with the external packets.

9. The network device of claim 8, wherein each respective internal packet queue of the one or more internal packet queues is configured to store internally generated packets of a respective traffic class, wherein enqueuing the one or more internally generated packets comprises enqueuing the one or more internally generated packets based at least in part on the respective traffic class of each of the one or more internally generated packets.

10. The network device of claim 9, wherein a first internal packet queue of the one or more internal packet queues is configured to store internally generated packets of a first traffic class.

11. The network device of claim 9, wherein the respective traffic class is one of network instrumentation traffic, multicast traffic, or notification traffic.

12. The network device of claim 8, wherein the arbitration scheme includes strict priority or weighted round robin.

13. The network device of claim 8, wherein internal queuing engine is configured to rate limit output of the one or more internally generated packets from the one or more internal packet queues.

14. The network device of claim 13, wherein a rate at which the internal queuing engine dequeues the one or more internally generated packets from the one or more internal packet queues is based at least in part on an amount of external packets received at the one or more ingress points.

15. The network device of claim 8, wherein the traffic manager further comprises admission control logic configured to determine whether to allow placement of the combined one or more internally generated packets output by the merge function logic with respective ones of one or more external packets into a packet buffer.

16. The network device of claim 15, wherein the traffic manager further comprises queuing logic configured to enqueue packets from the packet buffer into respective output queues of one or more logical queues.

17. A memory management unit, comprising: a traffic manager configured to receive one or more external packets and one or more internally generated packets, wherein the traffic manager comprises: an internal queuing engine coupled to one or more internal packet sources, the internal queuing engine comprising: one or more internal packet queues, wherein the internal queuing engine is configured to obtain the one or more internally generated packets from the one or more internal packet sources and enqueue each of the one or more internally generated packets in a respective internal packet queue of the one or more internal packet queues; arbitration logic configured to determine an order in which to dequeue the one or more internally generated packets from the one or more internal packet queues based at least in part on an arbitration scheme; and merge function logic configured to combine the internally generated packets from the internal queuing engine with the external packets. merge function logic configured to combine the internally generated packets from the internal queuing engine with the external packets received from the one or more external sources.

18. The memory management unit of claim 17, wherein each respective internal packet queue of the one or more internal packet queues is configured to store internally generated packets of a respective traffic class, wherein enqueuing the one or more internally generated packets comprises enqueuing the one or more internally generated packets based at least in part on the respective traffic class of each internally generated packet of the one or more internally generated packets.

19. The memory management unit of claim 17, wherein the arbitration scheme includes strict priority or weighted round robin.

20. The memory management unit of claim 17, wherein the internal queuing engine is configured to rate limit the output of the one or more internally generated packets from the one or more internal packet queues, wherein the rate at which the internal queuing engine dequeues the one or more internally generated packets from the one or more internal packet queues is based at least in part on an amount of external packets received at the one or more entry points.

Images