Patent Description:
A packet processing engine in a streaming pipeline accesses a small portion of a data packet, typically just the first N bytes (for example, L3-L1 headers). However, applications such as Deep Packet Inspection (DPI), transport offload and Transport Layer Security (TLS) offload need to access other portions of the data packet. These types of applications are becoming more critical to networking use-cases such as microservices.

<CIT> discloses techniques for handling network groupings in a proxy grid architecture.

<CIT> discloses techniques that can increase the packet processing speed of a system despite delays associated with memory accesses by enabling the processor to perform other operations, while memory operations occur.

<CIT> discloses technologies for filtering network packets on ingress that include a network interface controller (NIC) to retrieve classification filters based on packet classification identifying information of a network packet received by the NIC, wherein each of the classification filters is usable to identify rules for identifying any operations to be performed on at least a portion of the received network packet. The NIC is further configured to compare the first classification filter to the packet classification identifying information to determine whether the determined packet classification identifying information meets criteria of the first classification filter.

Preferred, optional, features are recited in the accompanying dependent claims.

Features of embodiments of the claimed subject matter will become apparent as the following detailed description proceeds, and upon reference to the drawings, in which like numerals depict like parts, and in which.

Although the following Detailed Description will proceed with reference being made to illustrative embodiments of the claimed subject matter, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art.

A large amount of memory is needed to buffer a large payload to allow a streaming pipeline to access any portion of the data packet as the data packet is received and transmitted. A stacked memory such as a high bandwidth memory (HBM) with a wide data path is used by the streaming pipeline in a Network Interface Controller to buffer segments of the data packet to allow the network interface controller to perform operations on the packet payload. The use of high bandwidth memory by the streaming pipeline allows the network interface controller to perform Transport Level Security (TLS) offload, full protocol stack offload, whole-packet classification, in-pipeline layer <NUM> processing, and deep packet inspection and custom transport protocols. The headers and packet payload can be scanned and classified concurrently with the buffered payload parsed in parallel. Packet parsing may include the use of programmable packet parsers and parsing programmable languages such as Programming Protocol-independent Packet Processors (P4) or Networking Programming Language (NPL).

The following description and drawings are illustrative of the invention.

Various embodiments and aspects of the inventions will be described with reference to details discussed below. In certain instances, well-known or conventional details are not described in to provide a concise discussion of embodiments of the present inventions.

<FIG> is a block diagram of a multi-chip package <NUM> that includes a logic die, High Bandwidth Memory (HBM) and an Embedded Multi-die Interconnect Bridge (EMIB). The logic die can be a System on Chip (SoC) or a Network Interface Controller (NIC).

A plurality of bumps (also referred to as solder bump, microbumps, or ball) provide contact between I/O pins on the logic die and I/O pins on the HBM to the package substrate. The EMIB is embedded in the package substrate below the edges of the logic die and the HBM die and includes routing layers to connect I/O pins from the logic die to I/O pins on the HBM die via the micro-bumps on the logic die and the HBM die.

A plurality of bumps provide contact between I/O pins on the logic die and I/O pins on the HBM to the interposer. The logic die and HBM die are placed side by side on top of an interposer that includes through-silicon vias (TSVs). The interposer acts as a bridge between the logic die and HBM die and a printed circuit board (PCB).

HBM is a high-speed memory interface for 3D-stacked Synchronous Dynamic Random Access Memory (SDRAM). High Bandwidth Memory (HBM) may be compatible with HBM (HBM, JESD235, originally published by JEDEC (Joint Electronic Device Engineering Council) in October <NUM>), HBM2 (HBM version <NUM>, JESD235C, originally published by JEDEC in January <NUM>), or HBM3 (HBM version <NUM> currently in discussion by JEDEC). A HBM die with a stack of four SDRAM dies has two <NUM>-bit channels per die for a total of <NUM> channels and a data bus width of <NUM> bits.

<FIG> is a block diagram of a multi-chip package <NUM> that includes a network interface controller <NUM> and HBM <NUM> that can be the multi-chip package <NUM> (<FIG>) or the multi-chip package <NUM> (<FIG>) to buffer segments of a data packet to allow a streaming pipeline in the network interface controller <NUM> to perform operations on the data packet payload. Streaming can refer to data movement and transformation operations performed in the network interface controller <NUM>.

HBM <NUM> is stacked High Bandwidth Memory with a stack of SDRAM dies as discussed in conjunction with <FIG>.

Headers in the data packet payload are processed by the streaming pipeline in a pipelined fashion. The network interface controller <NUM> includes host interface circuitry <NUM>, a processor <NUM>, media access control (MAC) layer circuitry <NUM>, physical (PHY) layer circuitry <NUM>, and a local memory <NUM>.

The Media Access Control layer circuitry <NUM> includes a plurality of full duplex Ethernet layer ports. In an embodiment there can be four full duplex Ethernet layer ports and the Media Access Control layer circuitry <NUM> uses the Ethernet protocol.

The physical (PHY) layer circuitry <NUM> (PHY circuitry) provides the plurality of Ethernet ports with integrated PHY interfaces to connect directly to a medium or to external PHYs. In an embodiment with four full duplex Ethernet MAC ports, the physical PHY layer circuitry <NUM> can support eight physical high speed SerDes lanes, two per Ethernet layer port.

The host interface circuitry <NUM> is communicatively coupled over bus <NUM> to a host interface. In an embodiment, the host interface circuitry <NUM> may include a Peripheral Component Interconnect Express (PCIe) adapter that is communicatively coupled over bus <NUM> using the Peripheral Component Interconnect Express (PCIe) protocol to a host. The PCIe standards are available at www.

<FIG> is a block diagram that includes circuitry in the network interface controller <NUM> to process data packets received by the network interface controller <NUM>. The network interface controller <NUM> uses both a streaming pipeline and HBM <NUM> to process data packets received by port circuitry <NUM>. The streaming pipeline includes packet processing circuitry <NUM> that can write segments into the HBM <NUM>. A segment is a portion of the data packet. The size of the segment is dependent on the width of the data path in the network interface controller <NUM>.

The circuitry to process received data packets includes ingress buffer <NUM>, packet processing circuitry <NUM>, payload buffer circuitry <NUM> and buffer management circuitry <NUM>. Buffer management circuitry <NUM> allocates memory in the HBM <NUM> for use by the network interface controller <NUM>. The buffer management circuitry <NUM> performs memory management of the allocated memory in the HBM <NUM>.

A data packet includes a plurality of segments. Each of the plurality of segments is received from the medium by port circuitry <NUM> and buffered in the ingress buffer <NUM>. The first segment of the data packet is sent from the ingress buffer <NUM> to the payload buffer circuitry <NUM>. The packet processing circuitry <NUM> reads the first segment of the data packet from the payload buffer circuitry <NUM> and inspects the headers in the first segment of the data packet. Based on the inspection of the first segment, the packet processing circuitry <NUM> determines whether to inspect and perform operations on other segments of the received data packet. If the packet processing circuitry <NUM> is not to perform operations on other segments of the data packet, the other segments of the data packet are streamed directly from port circuitry <NUM> via the ingress buffer <NUM> and the payload buffer circuitry <NUM> to the host interface circuitry <NUM>.

If operations are to be performed on other segments of the received data packet or packet processing circuitry <NUM> determines whole-packet flow is required, the packet processing circuitry <NUM> writes per-flow metadata (for example, policy related identifiers) to HBM <NUM>. For example, whole-packet flow can be based on policy. In a data server with multiple tenants, the policy for a tenant can be to perform Deep Packet Inspection (DPI) for each received data packet associated with the tenant.

To perform whole-packet flow processing or processing on a portion of the received data packet (for example, one or more segments in the data packet that may not be contiguous in the received packet), the packet processing circuitry <NUM> writes the updated first segment and a reinsertion tag (for example, REINSERT_ALL_SEGs) to the payload buffer circuitry <NUM>. For a received data packet with N segments, Segments <NUM>. N are buffered in ingress buffer <NUM> and sent to the payload buffer circuitry <NUM>. The segments stored in the payload buffer circuitry are written to the HBM <NUM>.

After the last segment (segment N) of the data packet has been received by the network interface controller <NUM> (also referred to as the end of packet (EOP) has been detected), the payload buffer circuitry <NUM> checks the reinsertion tag, and the buffer management circuitry <NUM> reads segments <NUM>-N from HBM <NUM> and streams segments <NUM>-N into the host interface circuitry <NUM>.

When processing the entire data packet, each segment <NUM>-N is streamed through packet processing circuitry <NUM> and back to the payload buffer circuitry <NUM>. The local buffer streams the received segments <NUM>-N to the HBM <NUM> until the end of packet is detected. After the entire data packet has been received by the network interface controller <NUM>, the payload buffer circuitry <NUM> streams the segments stored in HBM <NUM> to the host interface circuitry <NUM>.

Packet processing circuitry <NUM> that processes whole packets (for example, a crypto function) streams all segments <NUM>-N of the data packet after detecting end of packet to the host interface circuitry <NUM> or to another accelerator in the network interface controller <NUM>.

Packet processing circuitry <NUM> that performs processing on headers in the packet processes the packet data one segment at a time, with metadata indicating a current offset in the packet. Per-packet state (context related to the current data packet) can be written from any segment.

Header processing for processing headers in a data packet has a well-known classification model. That is, given a known header, rules can be created that match a header and an offset in the data packet. However, for deep packet processing, a relevant record can be midway through a data packet at an arbitrary offset, and may straddle data path segments.

Deep Packet Inspection (DPI) can be performed by the packet processing circuitry <NUM> in the network interface controller <NUM> for a received packet that is stored in the HBM <NUM>. A multi-segment data packet stored in the HBM <NUM> is transferred to the packet processing circuitry <NUM> over a packet processing circuitry data path <NUM>. The width of the packet processing circuitry data path <NUM> is H bits. H bits is a portion of the data packet that can be dependent on the width of the packet processing circuitry data path <NUM> and the width of the HBM <NUM> data path. The width of the HBM <NUM> data path can be <NUM> bits. Parsing circuitry <NUM> in packet processing circuitry <NUM> parses each H-bit segment received to locate a starting token T and returns a token offset S to packet processing circuitry <NUM>.

After the data packet has been processed by the parsing function, a portion of the multi-segment data packet stored in the HBM <NUM> is transferred again to the packet processing circuitry <NUM> over a packet processing circuitry data path <NUM>. Ingress circuitry <NUM> in the packet processing circuitry <NUM> streams H sized chunks of the data packet stored in HBM <NUM> over the packet processing circuitry data path <NUM> starting at the token offset S. This enables classifiers in the packet processing circuitry <NUM> to use existing fixed length matching mechanisms.

<FIG> is a flow graph illustrating a method for processing data packets received from the network by the port circuitry <NUM> in the network interface controller <NUM>.

At block <NUM>, packet processing circuitry <NUM> inspects the headers in the first segment of the received data packet.

At block <NUM>, Based on the inspection of the first segment, the packet processing circuitry <NUM> determines whether to inspect and perform operations on other segments of the received data packet. If the packet processing circuitry <NUM> is not to perform operations on other segments of the data packet, processing continues with block <NUM>.

At block <NUM>, the segments are stored in the payload buffer circuitry <NUM> and are written to the HBM <NUM>.

At block <NUM>, if the last segment has been received, processing continues with block <NUM>. If not, processing continues with block <NUM>.

At block <NUM>, each segment <NUM>-N is streamed through packet processing circuitry <NUM> to perform operations on the data packet and back to the payload buffer circuitry <NUM>.

At block <NUM>, the payload buffer circuitry <NUM> streams the segments to the host interface circuitry <NUM> or another accelerator.

At block <NUM>, the other segments of the data packet are streamed directly from port circuitry <NUM> via the ingress buffer <NUM> and the payload buffer circuitry <NUM> to the host interface circuitry <NUM>.

<FIG> is a block diagram that includes circuitry in the network interface controller <NUM> to process data packets transmitted by the network interface controller <NUM>.

The host interface circuitry <NUM> receives a first segment of a data packet to be transmitted from the network interface controller <NUM>. The host interface circuitry <NUM> forwards the first segment to packet processing circuitry <NUM>. The packet processing circuitry <NUM> processes the first segment, if the packet processing circuitry <NUM> determines from the first segment that whole-packet flow is not required, packet processing circuitry <NUM> forwards the first segment to payload build circuitry <NUM>. Payload build circuitry <NUM> fetches any further packet segments via host interface circuitry <NUM>, if needed and adds the segments to the data packet. When the data packet is ready to be transmitted from the network interface controller <NUM>, payload build circuitry <NUM> forwards the data packet to the egress buffer <NUM>. Data is forwarded to the medium (network) from the egress buffer <NUM>. If whole-packet flow is not required, the data packet is streamed via host interface circuitry, payload build circuitry <NUM>, egress buffer <NUM> and port circuitry <NUM>.

If packet processing circuitry <NUM> determines from a header in the first segment to be transmitted that whole-packet flow is required, packet processing circuitry <NUM> writes per-flow metadata to HBM <NUM>. Packet processing circuitry <NUM> returns the updated first segment and a reinsertion tag set to "REINSERT_ALL_SEGS". The updated first segment can include a checksum and data inserted by the packet processing circuitry <NUM>.

The payload build circuitry <NUM> receives the first segment with the reinsertion tag, and requests that the packet processing circuitry <NUM> write segments <NUM>. N to HBM <NUM>. The host interface circuitry <NUM> sends SEGMENT_READY to payload build circuitry <NUM> for each segment that is written to HBM <NUM>.

For whole-packet processing, the local buffer waits to receive all segments (segments <NUM>-N) for the data packet before streaming the segments that are stored in HBM <NUM> into the egress buffer <NUM>.

For segment specific processing, the local buffer streams segments received from host interface circuitry <NUM> from payload build circuitry <NUM> into the egress buffer <NUM>.

After receiving the last segment for the data packet, payload build circuitry <NUM> performs any further whole packet operations (for example, checksum operations and length field updates) and sends all segments to the egress buffer <NUM>.

The data packet can be edited by the packet processing circuitry <NUM>, the packet editing can result in an increase in the size of a segment in the data packet. When packet editing on a segment increases the size of the segment, the local buffer handles splitting segments that have increased in size into one or more segments, streaming these into the HBM <NUM>, and updating the segment chain.

Length fields in the header stack of the data packet are updated by maintaining a metadata list of fields in preceding segments that contain lengths. The metadata list of fields can be stored in the Network Interface Controller <NUM> on-die because the number of lists is proportional to the loop latency of processing payloads in the Network Interface Controller <NUM>. During EOP, the metadata list of fields can be used by the payload build circuitry <NUM> to update length fields along with any checksum operations the payload build circuitry <NUM> is performing.

<FIG> is a flow graph illustrating a method for processing data packets received by host interface circuitry <NUM> in the network interface controller <NUM> to be transmitted by the port circuitry <NUM> in the network interface controller to the network.

At block <NUM>, packet processing circuitry <NUM> inspects the headers in the first segment of the data packet to be transmitted.

At block <NUM>, based on the inspection of the first segment, the packet processing circuitry <NUM> determines whether to inspect and perform operations on other segments of the data packet to be transmitted. If the packet processing circuitry <NUM> is not to perform operations on other segments of the data packet, processing continues with block <NUM>.

At block <NUM>, the segments are stored in the payload build circuitry and are written to the HBM <NUM>.

At block <NUM>, each segment <NUM>-N is streamed through payload build circuitry <NUM> to perform operations on the data packet and back to the payload build circuitry <NUM>.

At block <NUM>, the payload build circuitry <NUM> streams the segments to the port circuitry <NUM> via the payload build circuitry <NUM> and the egress buffer <NUM> to the network.

At block <NUM>, the other segments of the data packet are streamed directly to port circuitry <NUM> via the payload build circuitry <NUM> and the egress buffer <NUM> to the network.

<FIG> is a block diagram of an embodiment a computer system <NUM> that includes the multi-chip package <NUM> that includes network interface controller <NUM> and HBM <NUM>. Computer system <NUM> may correspond to a computing device including, but not limited to, a server, a workstation computer, a desktop computer, a laptop computer, and/or a tablet computer.

The computer system <NUM> includes a system on chip (SOC or SoC) <NUM> which combines processor, graphics, memory, and Input/Output (I/O) control logic into one SoC package. The SoC <NUM> includes at least one Central Processing Unit (CPU) module <NUM>, a memory controller <NUM>, and a Graphics Processor Unit (GPU) <NUM>. In other embodiments, the memory controller <NUM> may be external to the SoC <NUM>. The CPU module <NUM> includes at least one processor core <NUM> and a level <NUM> (L2) cache <NUM>.

Although not shown, each of the processor core(s) <NUM> may internally include one or more instruction/data caches, execution units, prefetch buffers, instruction queues, branch address calculation units, instruction decoders, floating point units, retirement units, etc. The CPU module <NUM> may correspond to a single core or a multi-core general purpose processor, such as those provided by Intel® Corporation, according to one embodiment.

The Graphics Processor Unit (GPU) <NUM> may include one or more GPU cores and a GPU cache which may store graphics related data for the GPU core. The GPU core may internally include one or more execution units and one or more instruction and data caches. Additionally, the Graphics Processor Unit (GPU) <NUM> may contain other graphics logic units that are not shown in <FIG>, such as one or more vertex processing units, rasterization units, media processing units, and codecs.

Memory <NUM> is communicatively coupled to memory controller <NUM>. The memory <NUM> can be a non-volatile memory, a volatile memory, a tiered memory (with multiple levels of volatile and/or non-volatile memory) or a remote memory.

A non-volatile memory (NVM) device is a memory whose state is determinate even if power is interrupted to the device. In one embodiment, the NVM device can comprise a block addressable memory device, such as NAND technologies, or more specifically, multi-threshold level NAND flash memory (for example, Single-Level Cell ("SLC"), Multi-Level Cell ("MLC"), Tri-Level Cell ("TLC"), Quad-Level Cell ("QLC"), Penta-Level Cell (PLC) or some other NAND). A NVM device can also include a byte-addressable, write-in-place three dimensional Crosspoint memory device, or other byte addressable write-in-place NVM devices (also referred to as persistent memory), such as single or multi-level Phase Change Memory (PCM) or phase change memory with a switch (PCMS), NVM devices that use chalcogenide phase change material (for example, chalcogenide glass), resistive memory including metal oxide base, oxygen vacancy base and Conductive Bridge Random Access Memory (CB-RAM), nanowire memory, ferroelectric random access memory (FeRAM, FRAM), magneto resistive random access memory (MRAM) that incorporates memristor technology, spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, a thyristor based memory device, or a combination of any of the above, or other memory.

Volatile memory is memory whose state (and therefore the data stored in it) is indeterminate if power is interrupted to the device. Dynamic volatile memory requires refreshing the data stored in the device to maintain state. One example of dynamic volatile memory incudes DRAM (Dynamic Random Access Memory), or some variant such as Synchronous DRAM (SDRAM). A memory subsystem as described herein may be compatible with a number of memory technologies, such as DDR3 (Double Data Rate version <NUM>, original release by JEDEC (Joint Electronic Device Engineering Council) on June <NUM>, <NUM>). DDR4 (DDR version <NUM>, originally published in September <NUM> by JEDEC), DDR5 (DDR version <NUM>, originally published in July <NUM>), LPDDR3 (Low Power DDR version <NUM>, JESD209-3B, August <NUM> by JEDEC), LPDDR4 (LPDDR version <NUM>, JESD209-<NUM>, originally published by JEDEC in August <NUM>), LPDDR5 (LPDDR version <NUM>, JESD209-5A, originally published by JEDEC in January <NUM>), WIO2 (Wide Input/Output version <NUM>, JESD229-<NUM> originally published by JEDEC in August <NUM>), HBM (High Bandwidth Memory, JESD235, originally published by JEDEC in October <NUM>), HBM2 (HBM version <NUM>, JESD235C, originally published by JEDEC in January <NUM>), or HBM3 (HBM version <NUM> currently in discussion by JEDEC), or others or combinations of memory technologies, and technologies based on derivatives or extensions of such specifications. The JEDEC standards are available at www.

Within the I/O subsystem <NUM>, one or more I/O adapter(s) <NUM> are present to translate a host communication protocol utilized within the processor core(s) <NUM> to a protocol compatible with particular I/O devices. Some of the protocols that adapters may be utilized for translation include Peripheral Component Interconnect (PCI)-Express (PCIe); Universal Serial Bus (USB); Serial Advanced Technology Attachment (SATA) and Institute of Electrical and Electronics Engineers (IEEE) <NUM> "Firewire".

The I/O adapters <NUM> may include a Peripheral Component Interconnect Express (PCIe) adapter that is communicatively coupled using the PCIe (Peripheral Component Interconnect Express) protocol over bus <NUM> to the multi-chip package <NUM>. The PCIe standards are available at www.

The I/O adapter(s) <NUM> may communicate with external I/O devices <NUM> which may include, for example, user interface device(s) including a display and/or a touch-screen display <NUM>, printer, keypad, keyboard, communication logic, wired and/or wireless, storage device(s) including hard disk drives ("HDD"), solid-state drives ("SSD"), removable storage media, Digital Video Disk (DVD) drive, Compact Disk (CD) drive, Redundant Array of Independent Disks (RAID), tape drive or other storage device. The storage devices may be communicatively and/or physically coupled together through one or more buses using one or more of a variety of protocols including, but not limited to, SAS (Serial Attached SCSI (Small Computer System Interface)), PCIe (Peripheral Component Interconnect Express), NVMe (NVM Express) over PCIe (Peripheral Component Interconnect Express), and SATA (Serial ATA (Advanced Technology Attachment)).

Additionally, there may be one or more wireless protocol I/O adapters. Examples of wireless protocols, among others, are used in personal area networks, such as IEEE <NUM> and Bluetooth, <NUM>; wireless local area networks, such as IEEE <NUM>-based wireless protocols; and cellular protocols.

Power source <NUM> provides power to the components of computer system <NUM>. More specifically, power source <NUM> typically interfaces to one or multiple power supplies <NUM> in computer system <NUM> to provide power to the components of system <NUM>. In one example, power supply <NUM> includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be a renewable energy power source <NUM> (for example, solar power). In one example, power source <NUM> includes a DC power source, such as an external AC to DC converter. In one example, power source <NUM> or power supply <NUM> includes wireless charging hardware to charge via proximity to a charging field. In one example, power supply <NUM> can include an internal battery or fuel cell source.

It is envisioned that aspects of the embodiments herein can be implemented in various types of computing and networking equipment, such as switches, routers and blade servers such as those employed in a data center and/or server farm environment. Typically, the servers used in data centers and server farms comprise arrayed server configurations such as rack-based servers or blade servers. These servers are interconnected in communication via various network provisions, such as partitioning sets of servers into Local Area Networks (LANs) with appropriate switching and routing facilities between the LANs to form a private Intranet. For example, cloud hosting facilities can typically employ large data centers with a multitude of servers.

Cloud computing provides access to servers, storage, databases, and a broad set of application services over the Internet. A cloud service provider offers cloud services such as network services and business applications that are hosted in servers in one or more data centers that can be accessed by companies or individuals over the Internet. Hyperscale cloud-service providers typically have hundreds of thousands of servers. Each server in a hyperscale cloud includes storage devices to store user data, for example, user data for business intelligence, data mining, analytics, social media and micro-services. The cloud service provider generates revenue from companies and individuals (also referred to as tenants) that use the cloud services.

Disaggregated computing or Composable Disaggregated Infrastructure (CDI) is an emerging technology that makes use of high bandwidth, low-latency interconnects to aggregate compute, storage, memory, and networking fabric resources into shared resource pools that can be provisioned on demand. Computer system <NUM> can be a disaggregated platform.

An Infrastructure Processing Unit (IPU) is a programmable network device that intelligently manages system-level resources by securely accelerating networking and storage infrastructure functions in a disaggregated computing system data center. Systems can be composed differently based at least on how functions are mapped and offloaded.

Infrastructure Processing Units (IPUs) can be used by CSPs for performance, management, security and coordination functions in addition to infrastructure offload and communications. For example, IPUs can be integrated with smart NICs and storage or memory (for example, on a same die, system on chip (SoC), or connected dies) that are located at on-premises systems, base stations, gateways, neighborhood central offices, and so forth. An IPU (also referred to as a Data Processing Unit (DSP) ) can be integrated with NIC <NUM>.

Each blade comprises a separate computing platform that is configured to perform server-type functions, that is, a "server on a card. " Accordingly, each blade includes components common to conventional servers, including a main printed circuit board (main board) providing internal wiring (i.e., buses) for coupling appropriate integrated circuits (ICs) and other components mounted to the board. These components can include the components discussed earlier in conjunction with <FIG> and <FIG>.

Flow diagrams as illustrated herein provide examples of sequences of various process actions. The flow diagrams can indicate operations to be executed by a software or firmware routine, as well as physical operations. In one embodiment, a flow diagram can illustrate the state of a finite state machine (FSM), which can be implemented in hardware and/or software. Although shown in a particular sequence or order, unless otherwise specified, the order of the actions can be modified. Thus, the illustrated embodiments should be understood only as an example, and the process can be performed in a different order, and some actions can be performed in parallel. Additionally, one or more actions can be omitted in various embodiments; thus, not all actions are required in every embodiment. Other process flows are possible.

To the extent various operations or functions are described herein, they can be described or defined as software code, instructions, configuration, and/or data. The content can be directly executable ("object" or "executable" form), source code, or difference code ("delta" or "patch" code). The software content of the embodiments described herein can be provided via an article of manufacture with the content stored thereon, or via a method of operating a communication interface to send data via the communication interface. A machine readable storage medium can cause a machine to perform the functions or operations described, and includes any mechanism that stores information in a form accessible by a machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). A communication interface includes any mechanism that interfaces to any of a hardwired, wireless, optical, etc., medium to communicate to another device, such as a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc. The communication interface can be configured by providing configuration parameters and/or sending signals to prepare the communication interface to provide a data signal describing the software content. The communication interface can be accessed via one or more commands or signals sent to the communication interface.

Various components described herein can be a means for performing the operations or functions described. Each component described herein includes software, hardware, or a combination of these. The components can be implemented as software modules, hardware modules, special-purpose hardware (e.g., application specific hardware, application specific integrated circuits (ASICs), digital signal processors (DSPs), etc.), embedded controllers, hardwired circuitry, etc..

Besides what is described herein, various modifications can be made to the disclosed embodiments and implementations of the invention.

Claim 1:
A computing device (<NUM>) comprising:
a memory (<NUM>) with a wide data path, wherein the memory is a stacked High Bandwidth Memory and the width of the wide data path is <NUM>-bits; and
a network interface controller, NIC (<NUM>), communicatively coupled to the memory, the NIC comprising:
host interface circuitry (<NUM>);
port circuitry (<NUM>) configured to receive a data packet from a medium, the data packet includes a plurality of data segments;
ingress buffer (<NUM>) configured to buffer the received data packet; and
packet processing circuitry configured to inspect the headers in a first data segment in the plurality of data segments of the data packet to determine whether to either: stream the other data segments in the plurality of data segments of the data packet directly from the port circuitry via the ingress buffer to the host interface circuitry, or store the first data segment and the other data segments in the plurality of data segments of the data packet in the memory to enable operations associated with Deep Packet Inspection, DPI, to be performed by the packet processing circuitry on the first data segment and the other data segments in the plurality of data segments of the data packet.