Accelerating network security monitoring

Abstract

This invention relates to accelerating network security monitoring. Generally discussed herein are systems, apparatuses, and methods for network security monitoring (NSM). A hardware queue manager (HQM) can include an input interface to receive first data from at least a first worker thread, a queue replication circuit to generate a copy of at least a portion of the first data to create first copy data, and an output interface to (a) provide the first copy data to a second worker thread and / or (b) provide at least a portion of the first data to a third worker thread.

Description

TECHNICAL FIELD

[0001] Embodiments relate generally to monitoring networks such as for security. One or more embodiments relate to network security monitoring in a telecommunications (e.g., Third Generation Partnership Project (3GPP), Long Term Evolution (LTE), etc.) network or other network. BACKGROUND

[0002] Some currently widely used mechanisms for traffic monitoring / telemetry include using established protocols such as sFlow from the sFlow.org consortium, Netflow from Cisco Systems® Corporation of San Jose, California, USA, etc. for collecting telemetry data and transporting the collected telemetry data to an analysis system. The analysis system can perform network security analytics on the telemetry data. Traffic data is typically collected by physical switches using port mirroring, basic filtering / statistics aggregation using dedicated hardware engines within physical switches / routers, or through dedicated traffic replication hardware.

[0003] Currently, the inventors are not aware of known solutions that provide line-rate, secure network security monitoring capabilities at high packet processing rates on a general purpose communication platform and without significant impact on the workloads in question. BRIEF DESCRIPTION OF DRAWINGS

[0004] In the drawings, which are not necessarily drawn to scale, like numerals can describe similar components in different views. Like numerals having different letter Figure One The various embodiments discussed herein are illustrated schematically in the figures.

[0005] Figure 1 A diagram is shown, by way of example, of an embodiment of a system for secure monitoring using only software mechanisms along with a connection line.

[0006] Figure 2 A diagram is shown, by way of example, of an embodiment of a system including hardware acceleration.

[0007] Figure 3 A diagram is shown, by way of example, of an embodiment of a system for hardware acceleration.

[0008] Figure 4 A diagram is shown, by way of example, of an exploded view of a smaller system forming part of a larger system shown in Figure 3

[0009] Figure 5 A diagram is shown, by way of example, of an embodiment of a system.

[0010] ​Figure 6 A diagram illustrating an embodiment of a system is shown by way of example.

[0011] Figure 7 A diagram illustrating an embodiment of a method for hardware acceleration of network security monitoring (NSM) is shown by way of example.

[0012] Figure 8 A block diagram illustrating an embodiment of a system is shown by way of example. DETAILED DESCRIPTION

[0013] Discussed herein are systems and methods related to accelerating NSM. One or more embodiments include hardware solutions to improve such acceleration, such as a hardware queue manager (HQM). Embodiments can help deliver platform capabilities (communications platform core, component blocks, CSME / ME / IE), enhancements for secure deployment of NSM, and advanced non-intrusive debugging capabilities within a scalable operator network.

[0014] A communications platform can be optimized for single flow processing from a network interface controller (NIC) / switch. However, operational security mechanisms such as network security monitoring (NSM), secure delivery of platform external telemetry data, maintaining SLA sensitivity while enforcing network monitoring, and the like are tasks that can help network function virtualization (NFV), LTE, 3GPP, virtual evolved packet core (vEPC), and / or virtual customer premises equipment (vCPE) network visibility. Thus, addressing these issues can help reduce workload on the platform.

[0015] Embodiments discussed herein can help address such workload and visibility gaps by providing a general mechanism that can address one or more of these gaps. One or more embodiments can securely bind platform trusted elements such as a converged security and manageability engine (CSME), a management engine (ME), an IE, and a software guard extensions (SGX) with security and compression processing based on electrical or electronic components (e.g., HQM, cache controller, crypto processor, and the like) / field programmable gate arrays (FPGAs).

[0016] When switching functionality extends to servers between virtual machines (VMs) such as using Open vSwitch (OvS®) or router software from the Apache® Software Foundation of Forest Hill, Maryland, the same action is very inefficient to implement in software and causes platform packet processing to degrade. This degradation can be significant to, for example, tenants (e.g., infrastructure as a service (IaaS) tenants) or service consumers. Using a switch port analyzer (SPAN) and / or a terminal access point (TAP) and then using NSM traffic protection (e.g., encryption, source authentication, etc.) with current communication platform pure software mechanisms to implement port mirroring across many cores consumes many compute cycles and increases core-to-core communication. Given the increasing packet processing rates on modem servers (over 100 gigabits per second (Gbps) per second and projected to 400 Gbps by 2020), this is unsustainable.

[0017] Without hardware acceleration, current performance levels for clear text traffic ingress to traffic egress are disrupted and performance degradation that can impact overall platform performance limits scalability and constrains tenant load capacity (e.g., bandwidth) or results in poor service level agreement (SLA) delivery.

[0018] By offloading these capabilities in a carefully designed software framework and by modification to existing HQM, secure network monitoring and debugging capabilities can be constructed with minimal communication platform software cycles spent, HQM offload leveraged, and improved customer value via improved system performance. Furthermore, communication platform security technologies such as SGX and CSME can be used to securely provision HQM traffic policies and memory regions for forking (e.g., "teeing") of replicated traffic. SGX and VM-based memory encryption technologies can provide some measure of confidence, but do not protect policy paths and policy processing from other VMs / virtual network functions (VNFs), system administrators, NFV infrastructure managers, and so on. NFV generally decouples software implementations of network functions from hardware implementations of network functions used to operate the software.

[0019] NSM can be a useful security provider in existing 3GPP / LTE networks. NSM can include the ability to securely monitor network telemetry for security threats such as malware intrusion, anomalies, and zero-day attacks, among others. As existing LTE / 3GPP systems move to NFV and software defined systems (SDS), NSM can be provided while maintaining the same line rates and same functionality as in existing systems.

[0020] As the number of cores on the platform increases, it is expected that all telecom infrastructure such as vEPC or vCPE will run on the same platform. Therefore, it can be useful to monitor vEPC and vCPE networks on the platform. Currently, on at least some platforms, this entire process is invisible on the physical network outside the platform. Therefore, adding a component such as NSM on the platform can help increase security. In other words, in an environment where VNFs (VMs that perform specific network functions) are chained into a service function chain (SFC), the ability to inspect and debug traffic between each stage can help improve security for full-scale deployments. One or more of these problems can be addressed by one or more embodiments.

[0021] To save compute (e.g., central processing unit (CPU)) cycles, it can help to speed up operations in a general purpose manner without taking cycles away from higher level compute jobs or packet processing workloads. Embodiments can help achieve these goals by using the techniques described in the following sections.

[0022] Some requirements and issues that should be addressed for NFV / SDN systems other than existing physical network functions / systems can be summarized as follows. These security and performance requirements are taken from European Telecommunications Standards Institute (ETSI) NFV specifications (e.g., ETSI NFV SEC013, SEC012, SEC001) developed by operators for NFV / SDN deployments on communication platforms:

[0023] 1. NFV workloads can migrate across platforms. This means that NSM capabilities can be replicated / migrated along with the workloads. Therefore, NSM can consistently exist on every platform to which the workloads can migrate.

[0024] 2. NFV / SDN platforms support heterogeneous workloads (e.g., including vEPC, vCPE, video, network, tenant applications, etc.). In addition, NFV control and data planes are on completely different platforms. These conditions together can degrade NSM performance, impacting SLAs and traffic, and make it useful to implement NSM in a deterministic manner on all platforms, supporting SLAs with low jitter.

[0025] 3. Security requirements for NSM (from ETSI NFV SEC013 standard specification) need to leverage platform trust capabilities in order to be able to securely deliver and implement NSM policies.

[0026] Embodiments can function by collecting telemetry data such as from dynamic, virtual networks overlaid onto physical networks. One or more embodiments integrate a policy engine from an open virtual switch / router into a communications platform. One or more embodiments can additionally or alternatively use packet offloading (sometimes referred to in the art as "T-splitting") capabilities in an HQM device to provide these functions. Such embodiments can help conserve CPU cycles and enable additional NSM capabilities, improving overall system processing speed. Traffic split into multiple flows can include, for example, division of traffic after decryption, de-encapsulation, and processing, prior to re-encryption or compression.

[0027] Currently, the inventors are not aware of known solutions that provide line-rate, secure NSM capabilities at high packet processing rates on a general-purpose communications platform, such as without significant impact on the workloads at issue. Current communications platforms are optimized for single-flow processing from NICs / switches. Operational security mechanisms such as secure transport of NSM, platform-external telemetry data, maintaining SLA sensitivity, while performing NSM, are tasks that would help secure NFV / LTE vEPC, vCPE, network visibility.

[0028] Figure 1 An example diagram of an embodiment of a system 100 for secure monitoring along with system connections is illustrated. In some embodiments, only software mechanisms are used. The system 100 does not necessarily use hardware acceleration for performing secure monitoring. The illustrated system 100 includes an NFV infrastructure 102, an orchestrator 104, an operations support system (OSS) / business support system (BSS) 106, a VNF manager (VNFM) 108, a virtualization infrastructure manager (VIM) 110, and a network analytics tool 112.

[0029] The NFV infrastructure 102 virtualizes network node functions that can be chained together to create, for example, a communications service. The illustrated NFV infrastructure 102 includes virtual network functions (VNFs) 116A, 116B, 116C, and 116D, a switch / router 118, and an operator infrastructure 120.

[0030] The VNFs 116A-116D are virtualized tasks that were previously performed by dedicated hardware. The VNFs 116A-116D move these operations previously performed by dedicated hardware to software instantiation. The VNFs 116A-116D operate by virtue of the hardware and / or software programming of the hosts 122.

[0031] Switches / routers 118 provide communication capabilities between platforms 126A-126B and / or VNFs 116A-116D. Switches connect computers or other network devices. Routers connect a first network to a second network, such as by connecting a network to the Internet. Routers generally manage the path of data (e.g., requests, messages, or responses) provided to another network.

[0032] Carrier infrastructure 120 hosts other carriers' VNFs and includes a host 122 (e.g., an operating system (OS), a cloud OS, and / or a hypervisor), a firmware interface 124 (e.g., a Unified Extensible Firmware Interface (UEFI) or a Basic Input / Output System (BIOS)), a plurality of platforms 126A and 126B (e.g.), and interconnection circuitry 128 (e.g., input / output (I / O) ports, network interface controllers (NICs), switches, host fabric interfaces (HFI), and so forth).

[0033] Host 122 can include hardware or software for providing resources used by VNFs 116A-116D to carry out their operations. The host can include an OS, a cloud OS, a hypervisor, and so forth, on which the VNFs can operate.

[0034] Firmware interface 124 can include a UEFI, a BIOS, and so forth. Firmware interface 124 defines a software interface between host 122 and firmware (e.g., VNFs 116A-116D).

[0035] Platforms 126A-126B provide communication functionality for devices connected to a communication network. Examples of functionality provided by platforms 126A-126B include voice lines and Internet access, as well as operations to support voice and Internet access, among others. Platform 126A includes memory 130 (so does platform 126B, but the memory is not shown to avoid obscuring the view of system 100). Platforms 126A-126B can be communicatively coupled by interconnection circuitry 128.

[0036] Orchestrator 104 carries out resource and / or network service orchestration. Orchestrator 104 binds functionality provided by VNFs 116A-116D to create services in otherwise dispersed NFV environments. Orchestrator 104 can help ensure that sufficient computing resources, storage resources, and / or other network resources are available to provide network services. Orchestrator 104 can authorize, coordinate, release, and apportion VNFs 116A-116D that share infrastructure 102 resources.

[0037] OSS / BSS 106 is a computer system used by telecommunication service providers to manage their networks. OSS / BSS 106 can support network inventory, configuration, fault management, and / or service provisioning.

[0038] Virtual Network Function Manager (VNFM) 108 works with orchestrator 104 and VIM 110 to provide VNF capabilities. VNFM 108 can instantiate VNFs 116A-116D, scale VNFs 116A-116D, update and / or upgrade VNFs 116A-116D, and / or terminate VNFs 116A-116D. VNFM 108 can manage a single VNF or multiple VNFs. VNFM 108 maintains virtualized resources that support VNFs 116A-116D.

[0039] VIM 110, as illustrated, includes SDN controller 114. VIM 110 controls and manages compute, storage, and other network resources of infrastructure 102. VIM 110 can handle infrastructure such as can include one or more infrastructures of infrastructure 102. VIM 110 can maintain a list of which virtual resources are assigned to which physical resources, manage security group policies (for access control), manage repositories of NFV hardware and software resources to help improve and optimize the use of system resources.

[0040] SDN controller 114 is an application such as manages traffic control within a network. SDN controller 114 allows a server or other network resource to choose a switch packet destination, thereby instructing a switch where to send a packet. SDN controller 114 can take control plane of network hardware and operate it as software. SDN controller 114 can assign monitoring policies.

[0041] Network analytics tool 112 can provide functionality for analyzing telemetry data such as NSM functionality. Network analytics tool 112 can include vEPC, vCPE NFV analytics, data storage, network anomaly monitoring, and / or malware detection, among others.

[0042] Network security monitoring (NSM) services are indicated by arrows 132, 134, 136, and 138. The flow of this NSM service can be "accelerated" by the embodiments discussed herein. The SDN controller 114 of VIM 110 can provide policies to VNF 116D (e.g., a security monitoring (SecMon) VNF), as indicated by the combination of arrows 138 and 132. Services provided to VNF 116D can be securely terminated. VNF 116D can monitor services (e.g., all services) on switch / router 118 (as indicated by arrow 132). VNF 116D can provide monitoring policies to service applications. Based on this monitoring policy, VNF 116D provides the monitored services to interconnect circuit 128 (as indicated by arrow 134 or arrows 140 and 138). Interconnect circuit 128 provides the monitored services to network analysis tool 112, as indicated by arrow 136. Network analysis tool 112 may include a security and networking analysis system, a metadata collector, network profile settings, a monitoring system by tenant and / or by traffic, and / or a monitoring system on a tenant basis.

[0043] Figure 1 The NSM scheme results in significant overall platform degradation because valuable CPU cycles are consumed by VNF 116D, which is responsible for monitoring packets from switch / router 118, reformatting packets to conform to telemetry protocols, and securely binding and delivering the packets to external systems. Such NSM operations may consume 25 percent (or more) of the available computing resources of platform(s)126A-B.

[0044] Other arrows (in) Figure 1 (Not labeled in the attached diagram) can indicate data, signaling control services, and services from the physical network to the virtual network on or between VNFs / VMs on the platform.

[0045] Figure 1 An example of a virtual switch supporting VM-to-VM communication running on the platform is provided. Figure 1In the example of FIG. 1, VMs are software entities that can potentially provide introspection capabilities via, for example, packet-based software copies. It is contemplated that VNF 116A and VNF 116B are communicating, and the communication between the two is to be debugged. For example, VNF 116A can be a packet gateway, and VNF 116B can be a service gateway. A software copy of the packet is in between VNFs 116A-B, but the software copy has several issues in that the switch / router 118 itself is often slow in performing such copies. Thus, such copies can degrade the throughput of system 100. Another issue is that adding such debugging capabilities can add extra burden to system 100. In contrast, an HQM with such capabilities can offload the copy from system 100 to be managed by the HQM's queues, saving compute cycles and power. Moreover, the introspection capabilities of a traditional virtual switch can be maintained without necessarily resorting to running all copies in software. Using an HQM is one way to pull this functionality (in particular, traffic queuing and / or copying) into hardware. Thus, queue management can be offloaded to hardware, while still using traffic in the queues to maintain debugging visibility.

[0046] Consider a complex environment, such as Figure 1 an environment that does not include all VMs deployed on a single machine, but rather a chain of, say, 10 VMs that communicate with each other, deployed across different racks and different nodes within a data center. Thus, to be able to inspect traffic between, say, VM7 and VM8, their locations should be known. It is desirable to split traffic from VM7 and feed it to a monitoring VM, and deliver it to VM8. Such an operation can also include a scheduler tie-in to the locations of the VMs to copy and split such traffic.

[0047] Figure 2 An example diagram illustrating an embodiment of a system 200 including hardware acceleration is shown. System 200 is illustrated with system flow lines for an NSM using hardware acceleration. Some data flow lines in Figure 2 are not provided in Figure 1 to avoid obscuring the view of the data flow lines in Figure 2 . System 200 includes all the same components as illustrated in Figure 1 (notice that firmware interface 124 is not shown in Figure 2 to avoid obscuring the view of the data flow lines in Figure 2 ​The platform 126A, with some additional components, is shown in FIG. 2. The additional components are part of the platform 126A and include a security circuit 210, a memory queue 214, a queue policy register 216, a core 218, and a cache 220.

[0048] Using the system 200, the NSM can include providing monitoring policies to the VNF 116D and the security circuit 210, as indicated by arrows 138 and 132, respectively, and 202 or 204. In one or more embodiments, the security circuit 210 can monitor all traffic on the switch / router 118, thereby offloading CPU work from the host 122.

[0049] The platform security circuit 210 (e.g., SGX, ME, IE, etc.) can have a secure off-chip or on-package or in-structure channel(s) that can be used to deliver policies from the security circuit to various VNFs operating on the processor or chipset. The security circuit 210 can receive policies from the SDN controller 114 and translate them into specific configuration commands on the processor blocks (e.g., cache, three-dimensional x-point (3DXP) or other memory, NIC, switch(es), storage, etc.) and send different commands to different component blocks.

[0050] Each component (including those mentioned above) can include one or more queues 208. A queue is a logically and configurable set of resources provided by each component. Thus, a cache can serve multiple queues and be allocated to one or more VNFs / VMs. The same arrangement can be implemented for memory, NICs, ports, etc. The SDN controller 114 and / or the security circuit 210 can configure these queues 208 at the beginning of the platform and, optionally, while the platform 126A-126B is executing one or more VNFs 116A-116D.

[0051] Using the queues 208, the platform component resources can thus be "sliced" into a set of platform resource buckets that can be assigned to each VNF. One allocation criterion is the planned or agreed SLA delivery. The platform sliced resources can be allocated per tenant, per traffic, and / or per payment subscription model.

[0052] The queues 208 can process data (including network traffic). The queue 214 can be replicated into one or more other queues per policy. In other words, per policy delivered from the security circuit 210 into the component blocks, the component blocks can all replicate the entire queue onto other queues that support or belong to and / or are dedicated to the NSM.

[0053] The VNF 116D can read the queues 214 for configurable (e.g., software configurable) additional processing and analysis (e.g., using the VNF 116D as a front-end software processor such as for profiling). In other embodiments, the queue(s) 214 can be flushed directly onto an external network (e.g., per policy) for external analysis and monitoring by the analysis tool 112. In still other embodiments, the VNF 116D can be a part that can perform front-end software processing and then perform the analysis tool 112.

[0054] In one or more embodiments, the interconnect circuitry 128 can be designed to write to two replicated / mirrored descriptor tables instead of a single table used in the system 100. One of the tables can be used for general I / O tasks, and the other can be used by the VNF 116D to review based on related policies. With very small overhead in the network device or in the software stack processing, full line-rate secure monitoring can be achieved by modifying the design of both hardware and / or software. Similar approaches can be made available for storage or other applications.

[0055] The queue policy register 216 includes data that indicates which queues (of the memory queues 208) provide data to which cores 218. The queue policy register 216 can be read to determine which replicated traffic and other traffic is to be provided to the cores.

[0056] The cores 218 are processing cores, such as can include processing cores and / or debug cores. The cores 218 can implement the VNFs 116A-116D. The memory queues 208. The cache 220 can store instructions and / or data to be used by the cores 218 in performing their operations.

[0057] The system 200 provides a way to build interfaces in which a data center level administrator (or other entity) can debug, monitor, or otherwise view data in complex service chains. This is a convenient way to be able to go from the orchestrator 104 into the SDN controller 114, and, for example, monitor traffic between VM7 and VM8, and determine whether their traffic patterns are normal, or whether there is a misconfiguration in the system 100.

[0058] The secure circuitry 210, for example, can replicate traffic flow between a pair of VMs. Such a configuration can provide the ability to do such debugging without necessarily having to build a custom interface for each of the software segments that need to operate on the system.

[0059] System 200 can provide a work around for software versioning issues that can be problematic. Consider an OSS that supports a certain version of an interface that is changed in the next version of the interface, creating havoc in the monitoring software system. Encryption functionality (e.g., SGX) can help keep the VM encrypted and still provide visibility. So, at that point, secure circuit 210 can be trusted to perform the replication.

[0060] In one or more embodiments, interconnect circuit 128 can create a replicated descriptor table. Such replication of the descriptor table can be one way that can help perform debugging, monitoring, etc. without the presence of a HQM. This is one way in which, for example, a NIC can be used to replicate traffic flows.

[0061] Figure 3 An example diagram illustrating an embodiment of a system 300 for hardware accelerated NSM is shown. As illustrated, system 300 includes a NIC 302; a producer 304; a first HQM 306; workers 308A, 308B, 308C, and 308D; a second HQM 310 (the same or different than HQM 306); workers 308E, 308F, 308G, 308H, and 308I; a third HQM 312 (the same or different than HQM 306 and / or 310); a consumer 314; another NIC 316 (the same or different than NIC 302); and a cache 318 (e.g., L3 cache).

[0062] NIC 302 connects a computing device such as platform 126A-126B to a network. The NIC can include a HFI in one or more embodiments. NIC 302 receives data to be processed as indicated by data 301. Data 301 can be provided by NIC 302 to cache 318 and producer 304. Producer 304 converts data 301 to a format compatible with workers 308A-308I. Producer 304 can add descriptors to the data to indicate what operations are to be performed on the data. The converted data can be provided to HQM 306 such as on line 307.

[0063] HQM 306, 310, and 312 include queues 320, 322, and 324. HQM 306, 310, and 312 manage communication requests and can aggregate data between cores without relying on software routines. HQM 306, 310, and 312 can manage replication and distribution of NSM data to workers 308A-308I. HQM 306, 310, and 312 can replicate and T-split data such as for debugging and / or detection (or other NSM) purposes. As will be seen later,Figure 4 Figure illustrates a diagram of the HQM 310. The HQM 306 is considered a first level HQM. The HQM 310 is a second level HQM. The HQM 312 is a third level HQM.

[0064] The HQMs 306, 310, and 312 form an offload acceleration engine to enable a CPU core to send packets by using instructions to create 16-bit descriptors and send data. The HQMs 306, 310, and 312 can then perform up to two operations: (1) split a stream from one source into two output queues; and (2) gather performance metrics and logging. One or both operations can be performed without interfering with core operations. The split output queues are then read by any other core (to be emitted, effectively a version of port mirroring, with the HQMs 306, 310, and 312 involved to hardware-accelerate the introspection) or read to an IE to be emitted over a management interface (e.g., SDN controller or other interface). The HQMs 306, 310, and 312 can offload queue management, and can help split traffic (e.g., "T-split") for debugging, security monitoring (for NFV standard ETSI NFV SEC013), network performance monitoring (ETSI NFV specification PER001), traffic engineering, and so on. Splitting is receiving data on a first connection and providing at least a portion of the received data to at least two other components through components coupled to the first connection. Similarly, statistics can, for example, help detect dropped packets without requiring duplication of the entire traffic flow. Many statistics can already be maintained in the HQMs 306, 310, and 312; new performance counters for queue entry numbers can be split across queues. In one or more embodiments, statistics and / or other counters can be accessible only to the OS / VMM for security reasons and not accessible to the guest. Applicable, existing protocols can include Simple Network Management Protocol (SNMP), Reliable Event Logging (RLOG), Netflow, Internet Protocol Flow Information Export (IPFIX), sFlow, Internet Engineering Task Force (IETF) standards, and so on.

[0065] Workers 308A-308D are cores 218. Workers 308A-308D are first stage workers. Workers 308A-308D receive data from queue 320, as indicated by line 309. Operations performed by workers 308A-308D can include, for example, per-packet work, such as can include decryption, encapsulation, decapsulation, firewall, encryption, decryption, compression, and / or decompression, among others. Results of the operations performed by workers 308A-308D are provided to second stage HQM 310, as indicated by line 311. Queue 320 temporarily stores the results and HQM 310 provides the results to second stage workers 308E-308I. Second stage workers 308E-308H can perform packet inspection (e.g., deep packet inspection), network address translation, intrusion detection, advertisement insertion, routing, and the like. Results from second stage workers 308E-308H can be provided to third stage HQM 312, as indicated by line 317. Threads can be associated with individual workers, such that the worker is responsible for execution of the thread.

[0066] In one or more embodiments, such as for debugging purposes, results from workers 308A-308D can be provided to worker 308I, such as indicated by line 315. It can be difficult to debug cores, such as with traditional software-based virtual switch (vswitch) solutions (e.g., system 100), at high speed, in case there is a functional bug in the first stage of the core. To debug a network service function chain (SFC) in which multiple sets of complex multi-core VMs are chained together, hardware-supported debugging capabilities can be important in order to verify that the operations being performed are the expected operations. The HQM 310 modification can be modified with hardware extensions to enable debugging - in Figure 4 more detail is provided in

[0067] HQM 312 provides data to consumer 314, as indicated by line 319. Consumer 314 converts data from workers 308E-308H into a form that is compatible with a receiver. Consumer 314 provides the converted data to NIC 316, as indicated by line 333.

[0068] Workers 308A-308D can provide data to cache 318, as indicated by line 321. Workers 308A-308D can receive data from cache 318, as indicated by line 323. Workers 308E-308H can provide data to cache 318, as indicated by line 327. Workers 308E-308H can receive data from cache 318, as indicated by line 325. NIC 316 can receive data from cache 318 for transmission (on line 331) to a device on a network supported by system 300.

[0069] Figure 4 A smaller system 400, which forms part of the larger system 300 shown in Figure 3 An exploded view of smaller system 400, which forms part of the larger system 300 shown in Figure 3

[0070] Queue entry replication circuit 402 can help ensure that the data pointed to by the pointer in the entry does not change when the data is provided to worker 308I. Queue entry replication circuit 402 and data copy circuit 404 can retrieve the entry pointed to by the pointer and provide replicated traffic 406 to worker 308I. Copy circuit 404 can be part of HQM 306, 310, or 312, or external to HQM 306, 310, or 312.

[0071] Figure 5 ​A diagram illustrating an embodiment of system 500 is shown by way of example. System 500 can include HQM 504 to help reduce the amount of time and / or compute cycles for NSM. HQM 504 can help provide security and / or debugging functionality for VNF operations, such as can be carried out by cores 218A-218E. System 500 as illustrated includes cores 218A-218E, security circuit 210, memory 130, input queue 506, HQM 504, output queue 512, and configuration interface 514.

[0072] Cores 218A-218E receive instructions and carry out operations based on the instructions. A set of instructions, when executed by one of processor cores 218A-218E, can allow a software program to carry out a particular function via the physical actions of cores 218A-218E. Workers 308A-308D can include respective cores 218A-218C. Input queue 506 includes queues 506A, 506B, 506C, and 506D. Input queue 506 can be part of queue 320.

[0073] HQM 504 as illustrated includes sequencer circuit 508, control circuit, copy circuit 402, and copy circuit 404. Items of HQM 504 can be part of HQM 310. Sequencer circuit 508 generates addresses to step through a program. Addresses generated by sequencer circuit 508 can be generated based on a counter, a field from an instruction, or other data from input queue 506. Control circuit 510 manages operation of a program. Control circuit 510 can be responsive to control commands and data, such as from a user and / or sequencer circuit 508.

[0074] Output queue 512 can include 512A, 512B, 512C, and 512D. Output queue 512 can be part of queue 322. Output queue 512 manages data flow to processing core 218D and debugging core 218E (among other cores). Debugging core 218E can include worker 3081. Processing core 218D can include workers 308E-308H.

[0075] The configuration interface 514, as illustrated, includes configuration registers and queue routing control circuitry 518. The configuration registers 516 include data that indicates which data from the input queues 506 is to be provided for NSM operations, such as to the debug core 218E. The queue routing control circuitry 518 can be configured to control the sequencer and cause the sequencer circuitry 508 to provide data to be debugged to the output queue 512D. Data to be debugged can be provided to one of the output queues 512A-512C and the output queue 512D in order to provide data to the processing core 218D and the debug core 218E. Data that is not to be debugged can be provided to the processing core 218D without providing the data to the debug core 218E. The configuration registers 516 and the queue routing control circuitry 518 allow for reconfiguration by software or by hardware (e.g., out-of-band) and allow a particular queue that was set to route traffic from a first core to a second core (e.g., a first VM to a second VM) to now be set to route traffic from the first core to the second core and to a third core, for example, to enable debugging or other monitoring.

[0076] The HQM 504 can act as a memory-mapped IO device that routes queue entries from the input queues 506 through sequencing by the sequencer circuitry 508, optional atomic flow management (e.g., by the control circuitry 510 and / or the replication circuitry 402), arbitration, and / or optional reordering, and then to the output queues 512. The queue entries in the output queues 512 can be delivered to platform threads, such as can be executed by the processing core 218D and the debug core 218E. Such a system 500 can offload queue management and eliminate shared-memory-based queue structures for inter-thread data exchange, reducing overhead and improving performance. Specific changes to support flow replication (including the configuration registers 516), such as can be used to enable replication of the sequencer circuitry 508 (e.g., via a T-split mode), change to the queue sequencer circuitry 508 and new logic to copy queue entries to replicate packets (e.g., the replication circuitry 402, which can copy pointers of one or more of the input queues 506). Optionally, the copy circuitry 404 (internal or external to the HQM 504) can be used to copy the packets themselves rather than just the pointers, as can be done by the replication circuitry 402, so the debug core 218E can consume the packets later without risk of content changes that can lead to incorrect debugging results.

[0077] Figure 6A diagram illustrating an embodiment of the system 600 is shown by way of example. The system 600 as illustrated includes a software configuration flow. An administrator can use privileged software 604 (e.g., an OS, a VMM, an administrative SGX Enclave, or a VM / VNF that encrypts the VM's memory) to configure the HQM configuration register 516 to cause packets (or pointers) to be duplicated, such as by the duplication circuit 402 or the copy circuit 404. Alternatively, the administrator can grant privileged rights to a tenant to set security monitoring policies for the tenant's SGX-enabled (or VM memory encrypted) VM-TMEs. The guest then uses the HQM as usual without modification - this is valuable because changing the VM can be complex and can change the nature of the bugs exposed, especially timing race conditions or synchronization issues for multi-threaded programs. In this way, different points in a service function chain can also be checked without difficult reconfiguration of multiple stages of the pipeline.

[0078] Figure 6 A possible modification flow for the register 516 is illustrated. To set the register 516, the privileged software 604 can modify the HQM configuration register 516 to duplicate a selected traffic flow. Then, depending on what kind of monitoring is to be performed on the duplicated data, the data itself can be duplicated or only pointers can be duplicated. Depending on the configuration of the register 516, personnel can analyze the data and determine, for example, whether the data is configured as expected or flows as expected. A copy of the data flow can be provided for post-processing after a period of time. If, for example, the data is a high-bandwidth flow, or the data is a flow in which the VM that created the data can not necessarily be controlled, a full duplication of the flow can be more valuable.

[0079] Figure 6 Some interface options are shown in FIG. 18. The debug core 218E (see Figure 5 ) can operate, for example, to egress through a debug API (e.g., part of the OS) or directly from user space, such as indicated by line 601. In such embodiments, at least a portion of the HQM 306, 310, and 312 can be mapped directly into user space.

[0080] Current ARM and millions of instructions per second (MIPS) systems can help to implement physical network functions, and use dedicated fixed-function component engines for traffic separation. As platform architects begin to work on dynamic, migration-driven, and heterogeneous NFV / SDN workloads and systems, such as software-driven cloud portable NFV systems, general-purpose ARM systems or other systems can be used to implement embodiments discussed herein.

[0081] One or more embodiments discussed herein can be used in a 5G / mobile edge cloud (MEC) environment such as for a wireless base station consumer. SoCs including HQM as discussed herein can be useful in SGX or other security-enabled environments.

[0082] Elements of the present invention can enable an interface architecture or other communication platform to be operationally prepared for NFV and SDN deployment. As the number of cores on an interface architecture (IA) platform increases, multiple heterogeneous VNFs / VMs can be deployed on the same platform. The NSM provides the operational visibility component to the operator network deployment. Embodiments herein can help ensure that the IA provides line-rate and secure network traffic metrics and traffic elements for in-platform or on-platform monitoring.

[0083] To help explain the advantages of some embodiments, some people use the example provided herein. Consider multiple computing devices (e.g., box A, box B, and box C) connected via a standard Ethernet switch. Box A communicates with box B, and box B communicates with box C, and then to the rest of the network. However, when the functionality of boxes A-C is consolidated onto a server as VMs or VNFs, there are only a few different options for how to connect the functionality. One is via raw shared memory, which has security issues and robust operation issues. Another is a virtual switch, which is slower. A third is to use hardware acceleration, such as the HQM discussed herein. However, when using the HQM, there is typically visibility into the programmatic errors in the functionality of boxes A-C. Assume that box B is in the middle of a service function chain (i.e., the functionality of boxes A-C connected together), and box B is misconfigured and thus discarding packets.

[0084] Visibility in a typical configuration would be at the input to box A and at the output from box C. Such a configuration makes it difficult to determine which of boxes A-C is misconfigured or malfunctioning, which makes it difficult to tell which box to debug in more detail. With one or more embodiments, data (e.g., packet flow) can be split into a debug flow. The packet flow between box A and box B can be examined, for example, to see that those packets are being routed correctly, or that box A is operating correctly. Additionally or alternatively, a test point can be inserted between box B and box C. Using one or more embodiments, the operation of box B can be debugged. Worker 8 can operate in embodiments of Figure 3 and Figure 4 determine whether the operations being performed are the requested operations, whether one or more data flows are being processed and passed on for further processing, whether packets are being discarded, and so on.

[0085] Figure 7An example diagram illustrates embodiments of a method 700 for NSM such as can include hardware acceleration. The illustrated method 700 includes: at operation 702, receiving (at the HQM) first data from at least a first worker thread; at operation 704, generating (at a copy circuit or replication circuit of the HQM) a copy of at least a portion of the first data to create first copy data; and at operation 706, (a) providing the first copy data to a second worker thread to perform network security monitoring, and / or (b) providing the first data to a third worker thread. The method 700 can further include: wherein the second worker thread is a debugging thread and the third worker thread can include packet inspection, network address translation, intrusion detection, advertisement insertion, and / or routing.

[0086] The method 700 can further include: wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core, and the third worker thread executes on a third processing core, the first, second, and third processing cores comprising separate processing cores. The method 700 can further include: wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine, and the third worker thread executes on a third virtual machine, the first, second, and third processing virtual machines comprising separate virtual machines.

[0087] The method 700 can further include: wherein operation 704 includes copying a pointer to the first data. The method 700 can further include routing the first data and the first copy data to respective output queues coupled between the second and third processing cores and the hardware queue manager. The method 700 can further include receiving indication information to indicate data to be copied from a plurality of input queues, and providing the data to be copied to a data replication circuit.

[0088] "Circuitry," as used herein, refers to electrical and / or electronic hardware that can include one or more transistors, resistors, capacitors, inductors, diodes, logic gates, multiplexers, oscillators, buffers, modulators, regulators, amplifiers, demodulators, radios (e.g., transmitting or receiving radios or transceivers), sensors (e.g., transducers that convert one form of energy (e.g., optical, thermal, electrical, mechanical, or other energy) into another form of energy), and / or the like.

[0089] Figure 8A block diagram illustrating an embodiment of system 800 is shown by way of example. In one or more embodiments, system 800 includes one or more components that can be included in NFV infrastructure 102, orchestrator 104, OSS / BSS 106, VNFM 108, VIM 110, SDN controller 114, network analysis tool 112, memory 130, switch / router 118, operator infrastructure 120, host 122, firmware interface 124, platform 126A-126B, security circuit 210, memory queue 208, queue policy register 216, core 218, cache 220, NIC 302, interconnect circuit 128, producer 304, HQM 306, 310, and / or 312, worker 308A-308I, consumer 314, NIC 316, cache 318, replication circuit 402, copy circuit 404, configuration interface 514, sequencer circuit 508, control circuit 510, core 218A-218E, input queue 506, output queue 512, HQM enqueue / dequeue register 608, or other components of the figures. In one or more embodiments, one or more of NFV infrastructure 102, orchestrator 104, OSS / BSS 106, VNFM 108, VIM 110, SDN controller 114, network analysis tool 112, memory 130, switch / router 118, operator infrastructure 120, host 122, firmware interface 124, platform 126A-126B, security circuit 210, memory queue 208, queue policy register 216, core 218, cache 220, NIC 302, interconnect circuit 128, producer 304, HQM 306, 310, and / or 312, worker 308A-308I, consumer 314, NIC 316, cache 318, replication circuit 402, copy circuit 404, configuration interface 514, sequencer circuit 508, control circuit 510, core 218A-218E, input queue 506, output queue 512, HQM enqueue / dequeue register 608, or other components of the figures can be implemented, at least in part, using one or more components of system 800. Figures 1-7

[0090] ​In one embodiment, the processor 810 has one or more processing cores 812 and 812N, where 812N represents an Nth processing core within the processor 810, where N is a positive integer. In one embodiment, the system 800 includes multiple processors including 810 and 805, where the processor 805 has similar or identical logic as the logic of the processor 810. In some embodiments, the processing core 812 includes, without limitation, pre-fetch logic to fetch instructions, decode logic to decode the instructions, execution logic to execute the instructions, etc. In some embodiments, the processor 810 has a cache memory 816 to cache instructions and / or data for the system 800. The cache memory 816 can be organized into a hierarchy of one or more levels of cache memory.

[0091] In some embodiments, the processor 810 includes a memory controller 814 that is operable to perform functions that enable the processor 810 to access and communicate with the memory 830, which includes a volatile memory 832 and / or a non-volatile memory 834. In some embodiments, the processor 810 is coupled with the memory 830 and the chipset 820. The processor 810 can also be coupled to a wireless antenna 878 to communicate with any device configured to transmit and / or receive wireless signals. In one embodiment, the wireless antenna interface 878 operates according to, but is not limited to, IEEE 802.11 standards and their related family, Home Plug AV (HPAV), Ultra Wide Band (UWB), Bluetooth, WiMax, or any form of wireless communication protocol.

[0092] In some embodiments, the volatile memory 832 includes, without limitation, synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 834 includes, without limitation, flash memory, phase change memory (PCM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), or any other type of non-volatile memory device.

[0093] The memory 830 stores information and instructions to be executed by the processor 810. In one embodiment, the memory 830 can also store temporary variables or other intermediate information during execution of instructions by the processor 810. The memory 830 is an example of a machine readable medium. While a machine readable medium can include a single medium, the term “machine readable medium” can also include multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store the same or multiple copies of the information.

[0094] The term "machine-readable medium" can include any medium that is capable of storing, encoding, or carrying instructions for execution by a machine (e.g., a circuit) and that cause the machine to perform any one or more of the techniques of the present disclosure. In other words, the circuitry discussed herein can include instructions, and can be referred to as a machine-readable medium. Other non-limiting examples of a machine- readable medium can include a solid-state memory, a magnetic medium such as a disk, optical medium, and the like. Specific examples of a machine-readable medium can include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0095] In the illustrated embodiment, chipset 820 connects with processor 810 via point-to-point (PtP or P-P) interfaces 817 and 822. Chipset 820 enables processor 810 to connect to other elements in system 800. In some embodiments of the present application, interfaces 817 and 822 operate in accordance with a PtP communication protocol such as Intel® QuickPath Interconnect (QPI) or the like. In other embodiments, a different interconnect can be used.

[0096] In some embodiments, chipset 820 is operable to communicate with processor 810, 805N, display device 840, and other devices. Chipset 820 can also be coupled to wireless antenna 878 to communicate with any device configured to transmit and / or receive wireless signals.

[0097] Chipset 820 connects to display device 840 via interface 826. Display device 840 can be, for example, a liquid crystal display (LCD), a plasma display, a cathode ray tube (CRT) display, or any other form of visual display device. In some embodiments of the present application, processor 810 and chipset 820 are incorporated into a single SOC. In addition, chipset 820 is connected to one or more buses 850 and 855 that interconnect various elements 874, 860, 862, 864, and 866. Buses 850 and 855 can be interconnected together via bus bridge 872. In one embodiment, chipset 820 is coupled with non-volatile memory 860, mass storage device(s) 862, keyboard / mouse 864, and network interface 866 via interfaces 824 and / or 804, among others.

[0098] In one embodiment, mass storage device 862 includes, but is not limited to, a solid state drive, a hard disk drive, a universal serial bus flash memory drive, or any other form of computer data storage media. In one embodiment, network interface 866 is implemented by any type of known network interface standard, including, but not limited to an Ethernet interface, a universal serial bus (USB) interface, a peripheral component interconnect (PCI) express interface, a wireless interface, and / or any other appropriate type of interface. In one embodiment, the wireless interface operates in accordance with, but is not limited to, the IEEE 802.11 standard and its related family of standards, home plug AV (HPAV), ultra wide band (UWB), Bluetooth, WiMax, or any form of wireless communication protocol.

[0099] Although Figure 8 The components illustrated in FIG. 8 are depicted as individual blocks within system 800, but the functionality of some of these blocks can be integrated within a single semiconductor circuit, or the functionality of two or more individual blocks can be implemented using two or more separate integrated circuits. For example, although cache memory 816 is depicted as a separate block within processor 810, cache memory 816 (or selected aspects of 816) can be incorporated into processor core 812.

[0100] Examples and Notes

[0101] The subject matter can be described as a number of examples.

[0102] Example 1 can include a hardware queue manager, comprising: an input interface coupled to a plurality of input queues, the input interface to receive first data from at least a first worker thread through an input queue of the plurality of input queues; a queue replication circuit to generate a copy of at least a portion of the first data to create first copy data; and an output interface coupled to a plurality of output queues, the output interface to (a) provide the first copy data to a second worker thread coupled to a first output queue of the plurality of output queues, and (b) provide at least a portion of the first data to a third worker thread coupled to a second output queue of the plurality of output queues.

[0103] In Example 2, Example 1 can further include, wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core, and the third worker thread executes on a third processing core, the first, second, and third processing cores comprising separate processing cores.

[0104] In Example 3, Example 2 can further include wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine, and the third worker thread executes on a third virtual machine, the first, second, and third processing virtual machines comprising separate virtual machines.

[0105] In Example 4, at least one of Examples 1-3 can further include wherein the queue replication circuit is to copy a pointer to the first data.

[0106] In Example 5, at least one of Examples 1-4 can further include a data copy circuit to copy the first data.

[0107] In Example 6, at least one of Examples 1-5 can further include a queue routing control circuit to route the first data and the first copy data to respective ones of a plurality of output queues coupled between the second and third processing cores and the hardware queue manager.

[0108] In Example 7, Example 6 can further include a sequencer circuit to receive indication information to indicate data to be copied from the plurality of input queues, and to provide the data to be copied to the third processing core, and to provide a copy of the data to be copied to the replication circuit.

[0109] Example 8 includes a non-transitory machine-readable medium including instructions that, when executed on a machine, cause the machine to perform operations including: receiving first data from at least a first worker thread from an input of a plurality of input queues coupled to a hardware queue manager; generating a copy of at least a portion of the first data to create first copy data; and (a) providing the first copy data to a second worker thread coupled to a first output queue of a plurality of output queues, and (b) providing at least a portion of the first data to a third worker thread coupled to a second output queue of the plurality of output queues.

[0110] In Example 9, Example 8 can further include wherein the second worker thread is a debug thread, and the third worker thread comprises packet inspection, network address translation, intrusion detection, advertisement insertion, or routing.

[0111] In Example 10, at least one of Examples 8-9 can further include wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core, and the third worker thread executes on a third processing core, the first, second, and third processing cores comprising separate processing cores.

[0112] In Example 11, at least one of Examples 8-9 can further include, wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine and the third worker thread executes on a third virtual machine, the first, second and third processing virtual machines comprising separate virtual machines.

[0113] In Example 12, at least one of Examples 8-11 can further include, wherein generating the copy of at least a portion of the first data comprises copying a pointer to the first data.

[0114] In Example 13, at least one of Examples 8-12 can further include, wherein the operations further comprise routing the first data and the first copy data to respective ones of a plurality of output queues coupled between the second and third processing cores and the hardware queue manager.

[0115] In Example 14, Example 13 can further include receiving indication information to indicate data to be copied from the plurality of input queues, and providing the data to be copied to the data replication circuit.

[0116] Example 15 includes a method for network security monitoring, the method comprising: receiving first data from a first worker thread at an input interface of a hardware queue manager and through an input queue of a plurality of input queues coupled to the hardware queue manager; generating a copy of at least a portion of the first data at the hardware queue manager to create first copy data; and (a) providing the first copy data to a second worker thread to perform network security monitoring, the second worker thread coupled to a first output queue of a plurality of output queues coupled to the hardware queue manager, and (b) providing at least a portion of the first data to a third worker thread through a second output queue of the plurality of output queues coupled to the hardware queue manager.

[0117] In Example 16, Example 15 can further include, wherein the second worker thread is a debugging thread, and the third worker thread comprises packet inspection, network address translation, intrusion detection, advertisement insertion or routing.

[0118] In Example 17, at least one of Examples 15-16 can further include, wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core and the third worker thread executes on a third processing core, the first, second and third processing cores comprising separate processing cores.

[0119] In Example 18, the example 15-16 can further include wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine, and the third worker thread executes on a third virtual machine, the first, second, and third processing virtual machines comprising separate virtual machines.

[0120] In Example 19, the example 15-18 can further include wherein generating the copy of at least a portion of the first data comprises copying a pointer to the first data.

[0121] In Example 20, the example 15-19 can further include wherein the operations further comprise routing the first data and the first copy data to respective ones of a plurality of output queues coupled between the second and third processing cores and the hardware queue manager.

[0122] In Example 21, the example 20 can further include receiving indication information to indicate data to be copied from the plurality of input queues, and providing the data to be copied to the data replication circuit.

[0123] Example 22 includes a system comprising: a network function virtualization infrastructure comprising a plurality of processing cores to perform operations of a virtual network function, and a security circuit to monitor and copy traffic of the processing cores; a controller coupled to the security circuit to provide a security policy that defines traffic to be monitored and that indicates whether the security circuit is to copy data or a pointer to the data; and a network analysis tool to determine when the copied traffic includes a program error, a dropped packet, or a security threat.

[0124] In Example 23, the example 22 can further include wherein the controller is further to determine which core of the plurality of processing cores performs a particular virtual network function of the plurality of virtual network functions, and wherein the security policy, when executed, is to indicate the determined core, and the security circuit is to copy traffic from the determined core.

[0125] In Example 24, the example 23 can further include a switch or router, and wherein the controller is further to provide the security policy to the security circuit through the switch or router.

[0126] In Example 25, the example 24 can further include a plurality of memory queues in a memory to receive the copied traffic from the security circuit, and to provide the copied traffic to a network analysis circuit.

[0127] Each of these non-limiting examples can exist independently, or can be combined in various permutations or combinations with one or more of the other examples. "Non-transitory" is merely intended to exclude a propagating signal per se. Per the standard use in the industry, a "computer-readable medium" can be any medium that can contain, store, or record the programs and / or data that are accessed by a computer (e.g., computer 1000 described below). Computer-readable media can include non-transitory computer- readable media, as well as tangible media.

[0128] The above detailed description includes references to the accompanying drawings, which form a part of this detailed description. The drawings show, by way of illustration, specific embodiments in which the methods, devices, and systems discussed herein can be practiced. These embodiments are also referred to as "examples." Such examples can include elements in addition to those shown or described. However, the present document is intended to include examples that are only partially illustrated or described. Moreover, the document also includes examples that are not specifically illustrated or described, but that would be understood by a person of ordinary skill in the art to be included in the examples described and illustrated. For example, the disclosure includes examples using any combination or permutation of the elements shown or described herein, or any other elements, in any permutation or arrangement.

[0129] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive "or," such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In this document, the terms "including" and "comprising" are used as the plain-English equivalents of the respective terms "including" and "comprising." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

[0130] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) can be used in combination with each other. Other embodiments can be used as will be apparent to those of ordinary skill in the art upon reviewing the above description. The Abstract is provided to allow a quick mere of the disclosure's teachings to the reader. It is submitted with the understanding that the Abstract is to be construed narrowly and is not intended to be limiting of the scope of the claims. Moreover, the various features of the specific embodiments illustrated can be combined or arranged in other ways, consisting of adding, omitting, and / or substituting the various features shown, except that the embodiments cannot consist of adding features that are not already recited in the claims. Therefore, the following claims are hereby in incorporated into this DETAILED DESCRIPTION by way of reference and applying to it as an addition to the description and drawings.

Claims

1. A hardware queue manager comprising: an input interface to receive first data from at least a first worker thread; a queue replication circuit to generate a copy of at least a portion of the first data to create first copy data; and an output interface to (a) provide the first copy data to a second worker thread, the second worker thread being a debug thread, and (b) provide the first data to a third worker thread, the third worker thread comprising packet inspection, network address translation, intrusion detection, advertisement insertion, or routing.

2. The hardware queue manager of claim 1, wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core, and the third worker thread executes on a third processing core, the first, second, and third processing cores comprising separate processing cores.

3. The hardware queue manager of claim 1, wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine, and the third worker thread executes on a third virtual machine, the first, second, and third processing virtual machines comprising separate virtual machines.

4. The hardware queue manager of claim 1, wherein the queue replication circuit is to copy a pointer to the first data.

5. The hardware queue manager of claim 4, further comprising a data copy circuit to copy the first data.

6. The hardware queue manager of claim 1, further comprising a queue routing control circuit to route the first data and the first copy data to respective output queues coupled between the second and third processing cores and the hardware queue manager.

7. The hardware queue manager of claim 6, further comprising a sequencer circuit to receive indication information to indicate data to be copied from a plurality of input queues, and to provide the data to be copied to the third processing core, and to provide a copy of the data to be copied to the replication circuit.

8. A non-transitory machine-readable medium comprising instructions, which when executed on a machine, cause the machine to perform operations comprising: receiving, at an input interface of a hardware queue manager and through one of a plurality of input queues coupled to the hardware queue manager, first data from a first worker thread; and generating, at the hardware queue manager, a copy of at least a portion of the first data to create first copy data; (a) providing the first copy data to a second worker thread to perform network security monitoring, the second worker thread being coupled to a first output queue of a plurality of output queues coupled to the hardware queue manager, and (b) providing at least a portion of the first data to a third worker thread through a second output queue of the plurality of output queues coupled to the hardware queue manager.

9. The non-transitory machine readable medium of claim 8, wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core and the third worker thread executes on a third processing core, the first, second and third processing cores comprising separate processing cores.

10. The non-transitory machine readable medium of claim 8, wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine and the third worker thread executes on a third virtual machine, the first, second and third processing virtual machines comprising separate virtual machines.

11. The non-transitory machine readable medium of claim 8, wherein generating the copy of at least a portion of the first data comprises copying a pointer to the first data.

12. The non-transitory machine readable medium of claim 8, wherein the operations further comprise routing the first data and the first copy data to respective output queues coupled between the second and third processing cores and the hardware queue manager.

13. The non-transitory machine readable medium of claim 12, further comprising receiving indication information to indicate data to be copied from a plurality of input queues, and providing the data to be copied to the data replication circuitry.

14. A method for network security monitoring, the method comprising: receiving first data from a first worker thread at an input interface of a hardware queue manager and through one of a plurality of input queues coupled to the hardware queue manager; generating, at the hardware queue manager, a copy of at least a portion of the first data to create first copy data; (a) providing the first copy data to a second worker thread to perform network security monitoring, the second worker thread coupled to a first output queue of a plurality of output queues coupled to the hardware queue manager, and (b) providing at least a portion of the first data to a third worker thread through a second output queue of the plurality of output queues coupled to the hardware queue manager.

15. The method of claim 14, wherein the first worker thread executes on a first processing core, the second worker thread executes on a second processing core and the third worker thread executes on a third processing core, the first, second and third processing cores comprising separate processing cores.

16. The method of claim 14, wherein the first worker thread executes on a first virtual machine, the second worker thread executes on a second virtual machine and the third worker thread executes on a third virtual machine, the first, second and third processing virtual machines comprising separate virtual machines.

17. The method of claim 14, wherein generating the copy of at least a portion of the first data comprises copying a pointer to the first data.

18. The method of claim 14, further comprising routing the first data and the first copy data to respective output queues coupled between second and third processing cores and a hardware queue manager.

19. The method of claim 18, further comprising receiving indication information indicating data to be copied from a plurality of input queues, and providing the data to be copied to a data replication circuit.

20. An apparatus comprising means for performing the steps of the method of any of claims 14 to 19.

21. A computer program product comprising instructions which, when executed by a processor, cause the processor to perform the method of any of claims 14 to 19.

Images