Network interface device for booting one or more devices

Abstract

Examples described herein relate to a network interface device that launches one or more devices. In some examples, the network interface device includes: a device interface; a direct memory access (DMA) circuit; a network interface; a processor; and circuitry to launch from a network source, obtain one or more launch images from the network source, and then operate as a network launch server of at least one other device.

Description

Technical Field

[0001] The present disclosure relates to a network interface device for starting one or more devices. Background Art

[0002] The Preboot Execution Environment (PXE) (e.g., Preboot Execution Environment (PXE) Specification, Version 2.1 (1999)) describes a standardized way in which a client starts software components from a boot server via a network. If the client cannot be booted (e.g., the operating system (OS) is not installed, or there is some failure in the OS), the client can execute a Universal Extensible Firmware Interface (UEFI) application and use a PXE-capable network interface controller (NIC) to boot from a PXE boot server. Figure 1 An example of the prior art of a PXE server boot server system is depicted.

[0003] A network interface device, such as an Infrastructure Processing Unit (IPU), a data processing unit (DPU), or a Smart NIC, may include a general-purpose computer system, which includes a central processing unit (CPU), a memory, a storage device, input / output (I / O) devices, etc. In connection with a boot operation, such a network interface device executes an operating system (OS) installed before boot. Different customers and different use cases utilize OSs with different configurations. Therefore, some network interface devices that execute an OS are not configured in the factory but are configured on-site by an end user by installing the OS on-site. However, installing and configuring the OS and software on the network interface device and the host system may be an error-prone and time-consuming manual process. Summary of the Invention

[0004] According to an embodiment of the present disclosure, there is provided an apparatus including: a network interface device including: a device interface; a direct memory access (DMA) circuit; a network interface; a processor; and circuitry for booting from a network source, obtaining one or more boot images from the network source, and subsequently operating as a network boot server for at least one other device.

[0005] According to an embodiment of the present disclosure, at least one non-transitory computer-readable medium is provided, the medium including instructions stored thereon, which, if executed by one or more processors of a network interface device, cause the one or more processors to: request the boot software from a network boot server based on a processor among the one or more processors being unable to access the boot software for execution; intercept a request for the boot software received from a host system via a device interface; and provide the boot software to the host system via the device interface for execution by the host system, wherein the boot software includes one or more of the following: boot firmware or an operating system (OS).

[0006] According to an embodiment of the present disclosure, a method is provided, including: a network interface device performs: retrieving boot software from a boot software server and installing the boot software for execution by a processor of the network interface device and a host system connected to the network interface device via a device interface, wherein the boot software includes one or more of the following: boot firmware or an operating system (OS), and wherein the network interface device includes: the device interface; a direct memory access (DMA) circuit; a network interface; and the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An example prior art of booting is depicted.

[0008] Figure 2 An example system is depicted.

[0009] Figure 3 An example process is depicted.

[0010] Figure 4 An example process is depicted.

[0011] Figure 5A and 5B An example network interface device is depicted.

[0012] Figure 6 An example system is depicted. DETAILED DESCRIPTION

[0013] At least to support the provisioning or installation of boot firmware or software components in a network interface device and / or a host system locally or in another environment, in the case where the host system is connected to the network interface device and neither or both of the host system or the network interface device are provisioned with boot firmware or an OS (e.g., the boot firmware or OS is corrupted, not licensed for use, or not stored before or during boot), the network interface device can boot from a network source, obtain one or more boot images from the network source, and operate as a network boot server for at least one other device. For example, the boot server can include a server connected to the network interface device using the network and can send or receive packets conforming to Ethernet or other standard or proprietary protocols. For example, at least one other device can include a server connected to the network interface device through a device interface, and the server executes one or more processes that send and / or receive packets using the network interface device. For example, at least one other device can include a second network interface device, a server accessible using packets conforming to Ethernet or other standard or proprietary protocols and connected to the network interface device through the network, a composite system formed by devices connected through a network, fabric, or interconnect and organized by the network interface device or a coordinator, or other systems. For example, one or more boot images can include one or more of the following: boot firmware, an operating system (OS), an application, a configured application, a full disk image (e.g., processes, drives, processes, devices, and process states), or others.

[0014] For example, a network interface device can receive a boot image from another device as a PXE client and provide the services of a PXE server to the other device by: responding to a PXE boot request by providing a boot image stored on the network interface device, or passing the PXE boot request to a PXE server for service by a network-accessible PXE server and forwarding the response from the network-accessible PXE server to the other device. For example, the network interface device can configure, provision, initialize, and / or install a boot image from a boot server for execution by the network interface device and by connected hosts as well as other servers and / or network interface devices. In some examples, the network interface device can access a PXE server to access a boot image to provision the network interface device for booting. Next, the network interface device can provide PXE boot services to a connected host system. Depending on the configuration, the network interface device can forward a request for a boot image from the host system to a PXE server and provide the response from the PXE server (e.g., the boot image and other software and configuration) to the host system, or directly provision the host system with the boot image received from the PXE server and stored on the network interface device. When the host and the network interface device are restarted or after a restart, the host and the network interface device may be fully provisioned and ready to operate. References to PXE can also be changed to refer to other systems, such as Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, DHCP servers for Windows, ERPXE, Tiny PXE Server and TinyWeb, or other network boot services.

[0015] Figure 2 An example system is depicted. Server 200 can include one or more processors 202, memory 204, memory 206, and a device interface 208. Server 200 can include at least the circuitry and software referenced Figure 6 described. Server 200 can be communicatively coupled to a network interface device 220 via a device interface 208 that at least complies with Peripheral Component Interconnect express (PCIe), Compute Express Link (CXL), or other protocols. Network interface device 220 can include a device interface 222 for communicating with the device interface 208 of server 200, direct memory access (DMA) circuitry 224 for copying data to and reading data from server 200, a processor 226, memory 228, and a network interface 230 for sending and receiving packets via the network. At least referencedFigure 5A and 5B describes various examples of the network interface device 220.

[0016] In some examples, the network interface device 220 may include one or more of the following: a network interface controller (NIC), a NIC supporting remote direct memory access (RDMA), a SmartNIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), an edge processing unit (EPU), or an Amazon Web Service (AWS) Nitro card. The edge processing unit (EPU) may include a network interface device that utilizes a processor and accelerators (e.g., a digital signal processor (DSP), a signal processor, or a wireless dedicated accelerator for virtualized radio access network (vRAN), cryptographic operations, compression / decompression, etc.). The Nitro card may include various circuits for performing compression, decompression, encryption, or decryption operations, as well as circuits for performing input / output (I / O) operations.

[0017] The boot server 240 can provide a boot image 242 to the server 200 and the network interface device 220. The boot server 240 may operate in a manner compliant with one or more of the following: PXE, HTTP boot (e.g., UEFI specification V2.5 (2015)), Serva 32 / 64, the DHCP server for Windows, ERPXE, Tiny PXE server and TinyWeb, or other network boot services. The boot image 242 may include one or more of the following: boot firmware or an operating system (OS), an application, a configured application, a full disk image (e.g., an OS, processes, process states, device states, drives, or other software or firmware), the migration of a virtual machine or container environment, or others.

[0018] In some examples, the boot firmware code or firmware may include one or more of the following: Basic Input / Output System (BIOS), Unified Extensible Firmware Interface (UEFI), or a boot loader. The BIOS firmware may be pre-installed on the system board of a personal computer or may be accessed from a boot storage device (e.g., flash memory) via an SPI interface. In some examples, the firmware may include an SPS. In some examples, the Unified Extensible Firmware Interface (UEFI) may be used as an alternative or addition to the BIOS for booting or restarting the core or processor. The UEFI is a specification that defines the software interface between an operating system and platform firmware. The UEFI can read from entries in a disk partition by booting not only from a disk or storage device but also from a specific boot loader in a specific location on a specific disk or storage device. The UEFI can support remote diagnosis and repair of a computer even without an operating system installed. The boot loader may be written for the UEFI and may be instructions that the boot code firmware can execute, and the boot loader is to boot one or more operating systems. The UEFI boot loader may be a boot loader that can be read from UEFI-type firmware.

[0019] The UEFI is the standard BIOS installed in every PC-compatible system; when the system is powered on, it is the UEFI that initially runs to wake up the system, run the self-test, and then boot the operating system. The UEFI capsule is a way to encapsulate a binary image for firmware code updates. But in some examples, the UEFI capsule is used to update the runtime components of the firmware code. The UEFI capsule may include updatable binary images that have a relocatable Portable Executable (PE) file format for executable files or dynamic linked library (dll) files based on the Common Object File Format (COFF). For example, the UEFI capsule may include an executable (*.exe) file. This UEFI capsule can be deployed to a target platform as an SMM image via existing OS-specific technologies (e.g., Windows Update for Azure or LVFS for Linux).

[0020] For example, the boot server 240 can use network protocols including the Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), Hypertext Transfer Protocol (HTTP), or other protocols to provide network boot services for at least the server 200 and the network interface device 220. For example, to perform a network boot, one or more of the server 200, the network interface device 220, the server 250, and / or the network interface device 260 can: execute the Basic Input / Output System (BIOS), which initiates a PXE boot as a fallback option in case of a boot failure; send a DHCP request and a PXE request to the boot server 240 or other boot servers; receive a DHCP response and an Internet Protocol (IP) address from the TFTP server and the file name of the network boot program (NBP); download and execute the NBP; and the NBP causes the loading of configurations, scripts, and / or images to run the OS.

[0021] For example, to perform a network boot, one or more of the server 200, the network interface device 220, the server 250, and / or the network interface device 260 can: send a DHCP request containing an HTTP boot identifier to the boot server 240 or other boot servers; receive the boot resource location in the format of a Uniform Resource Identifier (URI); access the NBP identified by the URI; download the NBP from the HTTP server using the HTTP protocol; and execute the downloaded NBP image.

[0022] For example, a manufacturer can configure the network interface device 220 in a factory with an installed software stack that includes at least client and server software. The client and server software can include: a PXE client and a PXE server, and other software including but not limited to TFTP client / server software, and / or a saved OS image of the host. At power-on or startup, the network interface device 220 can provide a file (e.g., a PXE executable file) to the server 200 that pauses the server 200 until the network interface device 220 can configure itself over the network using a boot image 242 from the boot server 240. When configuring the network interface device 220 with the boot image 242 or thereafter, the network interface device 220 can assist in booting the server 200 based on a request for the boot image from the server 200. The network interface device 220 can boot from the boot server 240, obtain one or more boot images from the boot server 240, and then operate as a network boot server for at least one other device. For example, the network interface device 220 can act as a boot server for the server 200, other servers, and / or other network interface devices on an internal network port. The network interface device 220 can perform the operations of a boot server and provide a boot image to one or more of the following: the network interface device 220, the server 200, other servers 250, and / or other network interface devices 260.

[0023] Depending on the configuration or depending on the memory or storage available to the network interface device 220, the network interface device 220 can receive the boot image 242 from the boot server 240 and store the boot image 242 in the memory 228 accessible to the network interface device 220. In this case, the network interface device 220 can directly configure the server 200 as a boot server with the boot image 242. Depending on the configuration, or if the storage on the network interface device 220 is insufficient to store the boot image 242 for the server 200 or another device, the server 200 can pass a request for the boot image from the server 200 (or other device) to the boot server 240, thereby allowing the server 200 to be configured from the boot server 240 over the network.

[0024] In operation, at (1), based on a request for a boot image received from the network interface device 220, the boot server 240 can provide the boot image 242 to the network interface device 220. At (2), based on verification of the boot image 242 (e.g., verification of a checksum), the network interface device 220 can store the boot image 242 in the memory 228 for access and utilization to boot one or more of the processors 226. At (3), the network interface device 220 can provide the image 242 to the memory 206 of the server 200 for access and to boot one or more of the processors 202.

[0025] From the perspective of a network administrator, the boot firmware configuration of the server 200 and the network interface device 220 occurs in a single action when the server 200 is initially powered on. Once the system is physically installed and connected to the network, no additional manual operation time is required.

[0026] Figure 3 An example process is depicted. The process can be executed by a device, such as a host system, a network interface device, or other device. At 302, the device wakes up and attempts to boot. The processor of the device can attempt to perform UEFI initialization, which can include waking up the system, performing a self-check, searching for a boot image, and so on. At 304, the processor of the device can determine whether a boot image is available, or whether the processor of the device cannot boot. Based on the determination that a boot image is available, the process can proceed to 350, where the device can boot using the available boot image. Based on the determination that a boot image is not available, the process can proceed to 306.

[0027] At 306, the processor of the device can load a driver to communicate with the boot server. For example, the processor can load a Universal Network Device Interface (UNDI) driver to communicate with the boot server. At 306, based on a successful connection to the boot server, the processor can request the boot server to perform a boot loader process. For example, in the case where the boot server operates in a PXE-compliant manner, the processor can request a PXE executable file, and the device can receive the PXE executable file from the boot server. At 308, the processor can execute the boot loader, which can cause a request and download at least one boot image from the boot server into the memory accessible by the processor. At 310, the processor can execute the received at least one boot image.

[0028] At 312, a request for a boot image from a boot server can be received from a second device. The second device can include a host system, a network-connected host system, a network interface device, or other devices. For example, a processor can intercept communication with the boot server. For example, based on the PXE specification, the boot server can provide OS options and other boot image options to the second device. Based on the device being configured to interact with the second device as a boot server, at 360, the device can perform boot server operations for the second device and provide a stored boot image to the second device. However, based on the device not being configured to interact with the second device as a boot server or not storing the requested boot image, at 314, the device can request a specific boot image from the boot server. Based on receiving the boot image from the boot server, the device can provide the boot image to the second device. The second device can execute the boot image provided by the network interface device.

[0029] Figure 4 An example process is depicted. The process can be executed by a device such as a host system, a network interface device, or other devices. At 400, based on a host boot, the host can load a boot image installer (e.g., a pre-boot execution environment for management and deployment, a UEFI application, or other) to load the boot image. At 402, it can be determined whether the boot image is accessible to the device's processor. At boot time, the device can execute a UEFI BIOS that loads a driver (e.g., a Universal Network Device Interface (UNDI) driver) to cause the network interface device to search for a boot server. At 404, based on the boot image being inaccessible, the device can cause a request for a specific boot image to be sent to the boot server via the network interface device. The specific boot image can be identified by the host system. When the host system boots or prior thereto, the user can be presented with available boot images and can select a specific boot image, or a script can select a specific boot image, and the network interface device can report the selected boot image to the boot server, and the boot server can send the specific boot image to the network interface device.

[0030] At 406, based on receiving the boot image, the device can store the boot image. In some examples, the boot image can be loaded from the network interface device. However, based on not receiving the boot image, an error can be indicated, or the device can cause the network interface device to issue another request for the boot image to the boot server. At 408, the device can execute the stored specific boot image.

[0031] Referring again to 402, based on the device's ability to access a specific boot image from memory or a network interface device, at 450, the device can boot from a specific boot image stored in the device's memory or provided by the network interface device. For example, if the network interface device stores the requested specific boot image, the network interface device can provide the specific boot image to the device. The process can continue to 408, where the device can execute the specific boot image.

[0032] Figure 5A illustrates an example system. The host 500 may include a processor, a memory device, a device interface, and other circuitry, such as those described in reference to Figure 5B and / or Figure 6 one or more of. The processor of the host 500 may execute software, such as applications (e.g., microservices, virtual machines (VMs), micro-VMs, containers, processes, threads, or other virtualized execution environments), an operating system (OS), and device drivers. The OS or device drivers may configure the network interface device or packet processing device 510 to perform the operations of a boot server for one or more devices (e.g., a host system or a network interface device).

[0033] The packet processing device 510 may include multiple compute complexes, such as an Acceleration Compute Complex (ACC) 520 and a Management Compute Complex (MCC) 530, as well as packet processing circuitry 540 and network interface technology for communicating with other devices via the network. The ACC 520 may be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or at least reference Figure 5B and / or Figure 6 described circuitry. Similarly, the MCC 530 may be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or at least reference Figure 5B and / or Figure 6 described circuitry. In some examples, the ACC 520 and the MCC 530 may be implemented as separate cores in a CPU, different cores in different CPUs, different processors in the same integrated circuit, or different processors in different integrated circuits.

[0034] The packet processing device 510 can be implemented as one or more of the following: a microprocessor, a processor, an accelerator, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or at least the circuitry Figure 5B and / or Figure 6 described. The packet processing pipeline circuitry 540 can process packets according to the instructions or configuration of one or more control planes executed by multiple compute complexes. In some examples, the ACC 520 and the MCC 530 can execute the respective control planes 522 and 532.

[0035] As described herein, the packet processing device 510, the ACC 520, and / or the MCC 530 can be configured to request and receive a boot image from a boot server and / or perform the operations of a boot server on one or more devices including the host 500.

[0036] The SDN controller 542 can upgrade or reconfigure the software executed on the ACC 520 (e.g., the control plane 522 and / or the control plane 532) through the content of the packets received through the packet processing device 510. In some examples, the ACC 520 can execute a control plane operating system (OS) (e.g., Linux) and / or a control plane application 522 (e.g., a user space or kernel module) for the SDN controller 542 to configure the operations of the packet processing pipeline 540. The control plane application 522 can include a Generic Flow Table (GFT), ESXi, NSX, Kubernetes control plane software, application software for managing cryptographic configurations, a Programming Protocol-independent Packet Processor (P4) runtime daemon, a target specific daemon, a Container Storage Interface (CSI) agent, or a remote direct memory access (RDMA) configuration agent.

[0037] In some examples, the SDN controller 542 can communicate with the ACC 520 using a remote procedure call (RPC), such as Google remote procedure call (gRPC) or other services, and the ACC 520 can convert the request into a target-specific Protocol Buffer (protobuf) request to the MCC 530. gRPC is a remote procedure call solution based on data packets sent between a client and a server. Although gRPC is an example, other communication schemes can also be used, such as but not limited to Java Remote Method Invocation, Modula-3, RPyC, Distributed Ruby, Erlang, Elixir, Action Message Format, Remote Function Call, Open Network Computing RPC, JSON-RPC, and so on.

[0038] In some examples, the SDN controller 542 can provide packet processing rules for the ACC 520 to execute. For example, the ACC 520 can program the table rules (e.g., header field matching and corresponding actions) applied by the packet processing pipeline circuit 540 based on policy changes and changes in VMs, containers, microservices, applications, or other processes. The ACC 520 can be configured to provide network policies as flow cache rules into the table to configure the operation of the packet processing pipeline 540. For example, the control plane application 522 executed by the ACC can configure the rule table applied by the packet processing pipeline circuit 540 based on the packet type and content to define the traffic destination. The ACC 520 can program the table rules (e.g., match-action) into the memory accessible by the packet processing pipeline circuit 540 based on policy changes and changes in the VM.

[0039] For example, the ACC 520 can execute a virtual switch, such as vSwitch or Open vSwitch (OVS), Stratum, or Vector Packet Processing (VPP), which provides communication between virtual machines executed by the host 500 or with other devices connected to the network. For example, the ACC 520 can configure the packet processing pipeline circuit 540 regarding which VM receives traffic and what kind of traffic the VM can transmit. For example, the packet processing pipeline circuit 540 can execute a virtual switch, such as vSwitch or Open vSwitch, which provides communication between the virtual machines executed by the host 500 and the packet processing device 510.

[0040] The MCC 530 can execute the host management control plane, the global resource manager, and perform hardware register configuration. The control plane 532 executed by the MCC 530 can perform the provisioning and configuration of the packet processing circuit 540. For example, a VM executed on the host 500 can utilize the packet processing device 510 to receive or transmit packet traffic. The MCC 530 can execute startup, power, management, and manageability software (SW) or firmware (FW) code to start and initialize the packet processing device 510, manage device power consumption, provide connectivity with the Baseboard Management Controller (BMC), and other operations.

[0041] One or both of the control planes of the ACC 520 and the MCC 530 can define the traffic routing table content and the network topology, which are applied by the packet processing circuit 540 to select the path for the packet to go to the next hop in the network or to the destination network connection device. For example, a VM executed on the host 500 can utilize the packet processing device 510 to receive or transmit packet traffic.

[0042] The ACC 520 can execute a control plane driver to communicate with the MCC 530. At least to provide a configuration and provisioning interface between the control planes 522 and 532, the communication interface 525 can provide control plane-to-control plane communication. The control plane 532 can perform gatekeeper operations for the configuration of shared resources. For example, via the communication interface 525, the ACC control plane 522 can communicate with the control plane 532 to perform one or more of the following: determine hardware capabilities, access data plane configuration, reserve hardware resources and configuration, communicate between the ACC and the MCC via interrupt or polling, subscribe to receive hardware events, perform indirect hardware register reads and writes for debuggability, flash and physical layer interface (phy) configuration, or perform system provisioning for different deployments of network interface devices, such as: storage nodes, tenant-hosted nodes, microservice backends, compute nodes, or others.

[0043] The communication interface 525 can be utilized by the negotiation protocol and the configuration protocol running between the ACC control plane 522 and the MCC control plane 532. The communication interface 525 can include a general mailbox for different operations performed by the packet processing circuit 540. Examples of operations of the packet processing circuit 540 include: issuing non-volatile memory express (NVMe) reads or writes, Non-volatile Memory Express over Fabrics (NVMe-oF) TM)Issuance of reads or writes, lookaside cryptoEngine (LCE) (e.g., compression or decompression), Address Translation Engine (ATE) (e.g., input output memory management unit (IOMMU) to provide virtual to physical address translation), encryption or decryption, configured as a storage node, configured as a tenant-hosted node, configured as a compute node, providing multiple different types of services between different Peripheral Component Interconnect Express (PCIe) endpoints, or others.

[0044] The communication interface 525 may include one or more mailboxes that can be accessed as register or memory addresses. For communication from the control plane 522 to the control plane 532, the communication may be written by the control plane driver 524 to one or more mailboxes. For communication from the control plane 532 to the control plane 522, the communication may be written to one or more mailboxes. The communication written to the mailbox may include descriptors, which include message operation codes, message errors, message parameters, and other information. The communication written to the mailbox may include a defined format message for conveying data.

[0045] The communication interface 525 may provide communication based on writes or reads to specific memory addresses (e.g., dynamic random access memory (DRAM)), registers, and other mailboxes that are written to and read to transfer commands and data. To provide secure communication between the control planes 522 and 532, the registers and memory addresses (and memory address translation) for communication can only be written to or read by the control planes 522 and 532 or cloud service provider (CSP) software executing on the ACC 520 and device vendor software, embedded software, or firmware executing on the MCC 530. The communication interface 525 may support communication between multiple different compute complexes, such as from the host 500 to the MCC 530, the host 500 to the ACC 520, the MCC 530 to the ACC 520, the baseboard management controller (BMC) to the MCC 530, the BMC to the ACC 520, or the BMC to the host 500.

[0046] The packet processing circuit 540 can be implemented using one or more of the following: an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a processor executing software, or other circuitry. The control plane 522 and / or 532 can configure the packet processing pipeline circuit 540 or other processors to perform operations related to NVMe, NVMe-oF read or write, a legacy cipher engine (LCE), an address translation engine (ATE), a local area network (LAN), compression / decompression, encryption / decryption, or other acceleration operations.

[0047] Various message formats can be used to configure the ACC 520 or the MCC 530. In some examples, a P4 program can be compiled and provided to the MCC 530 to configure the packet processing circuit 540. The following is a JSON configuration file that can be transferred from the ACC 520 to the MCC 530 to obtain the capabilities of the packet processing circuit 540 and / or other circuitry in the packet processing device 510. More specifically, the file can be used to specify a number of transmit queues, a number of receive queues, a number of supported traffic classes (TCs), a number of available interrupt vectors, a number of available virtual ports and port types, the size of the allocated memory, supported parser profiles, exact match table profiles, packet mirroring profiles, and so on.

[0048] Figure 5B An example network interface device or packet processing device is depicted. In some examples, the circuitry of the network interface device can be utilized by the network interface 510 ( Figure 5A ) or another network interface for packet transmission and packet reception associated with a boot image request for a boot server or a response from a boot server, as described herein. In some examples, the network interface device 550 can be implemented as a network interface controller, a network interface card, a host fabric interface (HFI), or a host bus adapter (HBA), and such examples may be interchangeable. The packet processing device 550 can be coupled to one or more servers using a bus, PCIe, CXL, or Double Data Rate (DDR). The packet processing device 550 can be embodied as part of a system on a chip (SoC) including one or more processors, or be included on a multi-chip package that also contains one or more processors.

[0049] Some examples of network interface device 550 are part of an Infrastructure Processing Unit (IPU) or a data processing unit (DPU), or are utilized by an IPU or a DPU. xPU can refer to at least an IPU, a DPU, a GPU, a GPGPU, or other processing units (e.g., accelerator devices). An IPU or a DPU may include a network interface having one or more programmable or fixed-function processors to perform load transfer of operations that could otherwise be performed by a CPU. An IPU or a DPU may include one or more memory devices. In some examples, an IPU or a DPU may perform virtual switch operations, manage storage transactions (e.g., compression, cryptography, virtualization), and manage operations performed on other IPUs, DPUs, servers, or devices.

[0050] Network interface 550 may include a transceiver 552, a transmit queue 556, a receive queue 558, a memory 560, a host interface 562, a DMA engine 564, and a processor 580. Transceiver 552 may be capable of receiving and transmitting packets that conform to an applicable protocol, such as Ethernet as described in IEEE 802.3, but other protocols may also be used. Transceiver 552 may receive and transmit packets from and to the network via a network medium (not depicted). Transceiver 552 may include a PHY circuit 554 and a media access control (MAC) circuit 555. PHY circuit 554 may include encoding and decoding circuits (not shown) to encode and decode data packets according to an applicable physical layer specification or standard. MAC circuit 555 may be configured to assemble data to be transmitted into packets that include destination and source addresses, as well as network control information and error detection hash values.

[0051] Processor 580 may be any one or a combination of the following: a processor, a core, a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other programmable hardware devices that allow programming of network interface 550. For example, a “smart network interface” may utilize processor 580 to provide packet processing capabilities in the network interface.

[0052] The processor 580 may include one or more packet processing pipelines, which may be configured to perform match-action on received packets to identify packet processing rules and next hops using information stored in a ternary content-addressable memory (TCAM) table or an exact match table in some embodiments. For example, a match-action table or circuit may be used, whereby a hash of a portion of the packet is used as an index to find an entry. The packet processing pipeline may perform one or more of the following: packet parsing (parser), exact match-action (e.g., small exact match (SEM) engine or large exact match (LEM)), wildcard match-action (WCM), longest prefix match (LPM), hash block (e.g., receive side scaling (RSS)), packet modifier (modifier), or traffic manager (e.g., transmit rate metering or shaping). For example, the packet processing pipeline may implement an access control list (ACL) or drop packets due to queue overflow.

[0053] The configuration of the operation of the processor 580 (including its data plane) may be programmed based on one or more of the following: Protocol-independent Packet Processor (P4), Software for Open Networking in the Cloud (SONiC), Network Programming Language (NPL), DOCA TM , Infrastructure Programmer Development Kit (IPDK), and so on.

[0054] The packet distributor 574 may use the slot allocation or RSS described herein to provide distribution of received packets for processing by multiple CPUs or cores. When the packet distributor 574 uses RSS, the packet distributor 574 may calculate a hash or make another determination based on the content of the received packet to determine which CPU or core is to process the packet.

[0055] Interrupt coalescing 572 can perform interrupt throttling, whereby the network interface interrupt coalescing 572 waits for multiple packets to arrive or for a timeout to expire before generating an interrupt to the host system to process the received packet(s). Receive Segment Coalescing (RSC) can be performed by the network interface 550, whereby the parts of an incoming packet are combined into a packet fragment. The network interface 550 provides this combined packet to the application.

[0056] A direct memory access (DMA) engine 564 can copy packet headers, packet payloads, and / or descriptors directly from host memory to the network interface or vice versa, rather than copying the packet to an intermediate buffer at the host and then using another copy operation from the intermediate buffer to the destination buffer.

[0057] The memory 560 can be any type of volatile or non-volatile memory device and can store any queues or instructions for programming the network interface 550. The transmit queue 556 can include data to be sent by the network interface or references to data. The receive queue 558 can include data received by the network interface from the network or references to data. The descriptor queue 570 can include descriptors that reference data or packets in the transmit queue 556 or the receive queue 558. The host interface 562 can provide an interface to a host device (not depicted). For example, the host interface 562 can be compatible with a PCI, PCI Express, PCI-X, Serial ATA, and / or USB-compatible interface (although other interconnect standards can be used).

[0058] Figure 6Depicts a system. In some examples, the circuitry of the network interface device can be utilized to request a boot image from a boot server or to provide a boot image to one or more processors, as described herein. System 600 includes a processor 610 that provides processing, operational management, and execution of instructions for System 600. Processor 610 can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), XPU, processing core, or other processing hardware used to provide processing for System 600, or a combination of processors. The XPU can include one or more of the following: CPU, graphics processing unit (GPU), general purpose GPU (GPGPU), and / or other processing units (e.g., accelerators or programmable or fixed function FPGAs). Processor 610 controls the overall operation of System 600 and can be or can include one or more programmable general or special purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), etc., or a combination of such devices.

[0059] In one example, System 600 includes an interface 612 coupled to processor 610, which can represent a higher speed interface or high throughput interface for system components that require a higher bandwidth connection, such as memory subsystem 620 or graphics interface component 640, or accelerator 642. Interface 612 represents interface circuitry, which can be a separate component or can be integrated onto the processor die. If present, the graphics interface 640 interfaces with a graphics component to provide a visual display to a user of System 600. In one example, the graphics interface 640 can drive a display that provides output to the user. In one example, the display can include a touch screen display. In one example, the graphics interface 640 generates a display based on data stored in memory 630 or based on operations performed by processor 610 or both. In one example, the graphics interface 640 generates a display based on data stored in memory 630 or based on operations performed by processor 610 or both.

[0060] The accelerator 642 can be a programmable or fixed-function load transfer engine that can be accessed or used by the processor 610. For example, one of the accelerators among the accelerators 642 can provide data compression (DC) capabilities, cryptographic services (such as public key encryption (PKE)), cryptography, hashing / authentication capabilities, decryption, or other capabilities or services. In some cases, the accelerator 642 can be integrated into a CPU socket (e.g., a connector on a motherboard or circuit board that includes a CPU and provides an electrical interface to the CPU). For example, the accelerator 642 can include a single-core or multi-core processor, a graphics processing unit, a logical execution unit, a single-level or multi-level cache, functional units that can be used to independently execute programs or threads, an application specific integrated circuit (ASIC), a neural network processor (NNP), programmable control logic, and programmable processing elements such as a field programmable gate array (FPGA). The accelerator 642 can provide multiple neural networks, CPUs, processor cores, general-purpose graphics processing units, or graphics processing units for use by artificial intelligence (AI) or machine learning (ML) models. For example, an AI model can use or include any one or a combination of the following: reinforcement learning schemes, Q-learning schemes, deep Q-learning, or Asynchronous Advantage Actor-Critic (A3C), combined neural networks, recursive combined neural networks, or other AI or ML models. Multiple neural networks, processor cores, or graphics processing units are available for use by AI or ML models to perform learning and / or inference operations.

[0061] Memory subsystem 620 represents the main memory of system 600 and provides storage for code to be executed by processor 610 or data values to be used during the execution of routines. Memory subsystem 620 may include one or more memory devices 630, such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) (such as DRAM), or other memory devices, or a combination of such devices. Memory 630 stores and hosts an operating system (OS) 632, etc., to provide a software platform for the execution of instructions in system 600. Additionally, applications 634 may execute from memory 630 on the software platform of OS 632. Applications 634 represent programs with their own operation logic to perform the execution of one or more functions. Process 636 represents an agent or routine that provides auxiliary functions to OS 632 or one or more applications 634 or a combination thereof. OS 632, applications 634, and process 636 provide software logic to provide functionality for system 600. In one example, memory subsystem 620 includes a memory controller 622, which is a memory controller for generating and issuing commands to memory 630. Memory controller 622 may be a physical part of processor 610 or a physical part of interface 612. For example, memory controller 622 may be an integrated memory controller, integrated onto a circuit with processor 610.

[0062] Applications 634 and / or process 636 may alternatively or additionally refer to virtual machines (VMs), containers, microservices, processors, or other software. The various examples described herein may execute applications composed of microservices, where the microservices run in their own processes and communicate using protocols (e.g., application programming interfaces (APIs), Hypertext Transfer Protocol (HTTP) resource APIs, messaging services, remote procedure calls (RPCs), or Google RPC (gRPC)). Microservices may communicate with each other using a service mesh and be executed in one or more data centers or edge networks. Centralized management of these services may be used to deploy microservices independently. The management system may be written in different programming languages and use different data storage technologies. Microservices may be characterized by one or more of the following: multi-language programming (e.g., code written in multiple languages to capture additional functionality and efficiency not provided by a single language), or lightweight container or virtual machine deployment, and decentralized continuous microservice delivery.

[0063] In some examples, the OS 632 can be a server or a personal computer, VMware vSphere, openSUSE, RHEL, CentOS, Debian, Ubuntu, or any other operating system. The OS and the drive can execute on a processor sold or designed by companies such as or be compatible with a reduced instruction set computer (RISC) instruction set architecture (ISA) (e.g., RISC-V). In some examples, the OS 632 can configure the network interface 650 to provide services for booting the server to the processor 610.

[0064] Although not specifically illustrated, it will be understood that the system 600 can include one or more buses or bus systems between the devices, such as a memory bus, a graphics bus, an interface bus, or others. The bus or other signal lines can communicatively or electrically couple the components together, or simultaneously communicatively and electrically couple the components. The bus can include physical communication lines, point-to-point connections, bridges, adapters, controllers, or other circuits or combinations thereof. The bus can include, for example, one or more of the following: a system bus, a Peripheral Component Interconnect (PCI) bus, a Hyper Transport or an industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (Firewire).

[0065] In one example, system 600 includes interface 614, which may be coupled to interface 612. In one example, interface 614 represents interface circuitry, which may include discrete components and integrated circuits. In one example, a plurality of user interface components or peripheral components or both are coupled to interface 614. Network interface 650 provides system 600 with the ability to communicate with remote devices (e.g., servers or other computing devices) via one or more networks. Network interface 650 may include an Ethernet adapter, a wireless interconnect component, a cellular network interconnect component, a USB (Universal Serial Bus), or an interface based on other wired or wireless standards or proprietary interfaces. Network interface 650 may transfer data to devices in the same data center or rack or to remote devices, which may include sending data stored in memory. Network interface 650 may receive data from remote devices, which may include storing the received data in memory. In some examples, packet processing device or network interface device 650 may refer to one or more of the following: network interface controller (NIC), remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element, infrastructure processing unit (IPU), or data processing unit (DPU). Refer to Figure 5A or 5B describes example IPU or DPU.

[0066] In one example, system 600 includes one or more input / output (I / O) interfaces 660. I / O interfaces 660 may include one or more interface components through which users interact with system 600. Peripheral interface 670 may include any hardware interfaces not specifically mentioned above. Peripherals generally refer to devices that are dependently connected to system 600.

[0067] In one example, system 600 includes a storage subsystem 680 to store data in a non-volatile manner. In one example, in some system implementations, at least some components of storage device 680 may overlap with components of memory subsystem 620. Storage subsystem 680 includes one or more storage devices 684, which may be or may include any conventional medium for storing large amounts of data in a non-volatile manner, such as one or more magnetic, solid-state, or optical-based disks, or combinations thereof. Storage device 684 stores code or instructions and data 686 in a persistent state (e.g., the value is retained even though power to system 600 is interrupted). Storage device 684 may be generically considered "memory," although memory 630 is typically the execution or operating memory that provides instructions to processor 610. Storage device 684 is non-volatile, while memory 630 may include volatile memory (e.g., if power to system 600 is interrupted, the value or state of the data is indeterminate). In one example, storage subsystem 680 includes a controller 682 to interface with storage device 684. In one example, controller 682 is a physical part of interface 614 or processor 610, or may include circuitry or logic in both processor 610 and interface 614.

[0068] Volatile memory is memory whose state is indeterminate (and thus the data stored therein is indeterminate) in the event that power to the device is interrupted. A non-volatile memory (NVM) device is a type of memory whose state is determinate even in the event that power to the device is interrupted.

[0069] In one example, the system 600 can be implemented using an interconnected computing chassis of a processor, memory, storage, network interface, and other components. High-speed interconnects can be used, such as: Ethernet (IEEE 802.3), remote direct memory access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), quick UDP Internet Connection (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect express (PCIe), Intel QuickPath Interconnect (QPI), Intel UltraPath Interconnect (UPI), Intel On-Chip System Fabric (IOSF), Omni-Path, Compute Express Link (CXL), HyperTransport, high-speed fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Infinity Fabric (IF), Cache Coherent Interconnect for Accelerator (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variants thereof. Data can be copied or stored to virtualized storage nodes or accessed using protocols such as fabric-based NVMe (NVMe-oF) or NVMe (e.g., a non-volatile memory express (NVMe) device can operate in a manner compliant with the non-volatile memory express (NVMe) specification revision 1.3c released on May 24, 2018 (“NVMe specification”) or its derivatives or variants).

[0070] Communication between devices may occur using a network that provides die-to-die communication; chip-to-chip communication; board-to-board communication; and / or package-to-package communication.

[0071] In one example, system 600 may be implemented using an interconnected computing chassis of processors, memories, storage devices, network interfaces, and other components. High-speed interconnects such as PCIe, Ethernet, or optical interconnects (or combinations thereof) may be used.

[0072] Examples herein may be implemented in various types of computing and networking devices such as switches, routers, rack and blade servers such as those employed in data center and / or server farm environments. Servers used in data centers and server farms include arrayed server configurations such as rack-based servers or blade servers. These servers are communicatively interconnected via various network arrangements, such as dividing groups 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 typically may employ large data centers with numerous servers. Blades include individual computing platforms configured to perform server-type functions, i.e., "servers-on-a-card". Thus, blades include components common to traditional servers, including a main printed circuit board (motherboard) that provides internal wiring (e.g., buses) for coupling appropriate integrated circuits (ICs) and other components mounted to the board.

[0073] Various examples can be implemented using hardware elements, software elements, or a combination of both. In some examples, the hardware elements can include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, ASICs, PLDs, DSPs, FPGAs, memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, etc. In some examples, the software elements can include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and / or software elements can vary according to any number of factors desired for a given implementation, such as desired computing rate, power level, heat tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints. A processor can be a hardware state machine, digital control logic, a central processing unit, or a combination of one or more of any hardware, firmware, and / or software elements.

[0074] Some examples can be implemented using or be implemented as an article of manufacture or at least one computer-readable medium. A computer-readable medium can include a non-transitory storage medium to store logic. In some examples, the non-transitory storage medium can include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. In some examples, the logic can include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0075] According to some examples, a computer-readable medium may include a non-transitory storage medium to store or maintain instructions that, when executed by a machine, computing device, or system, cause the machine, computing device, or system to perform the methods and / or operations according to the described examples. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and so on. The instructions may be implemented according to a predefined computer language, manner, or syntax for instructing a machine, computing device, or system to perform a particular function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0076] One or more aspects of at least one example may be implemented by representative instructions stored on at least one machine-readable medium that represent various logic within a processor, which, when read by a machine, computing device, or system, cause the machine, computing device, or system to fabricate the logic to perform the techniques described herein. Such representations, referred to as “IP cores,” may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a fabrication machine that actually fabricates the logic or processor.

[0077] The occurrences of the phrase “an example” or “one example” do not necessarily all refer to the same example or embodiment. Any aspect described herein may be combined with any other aspect or similar aspect described herein, whether or not these aspects are described with respect to the same figure or element. The partitioning, omission, or inclusion of the block functions depicted in the figures does not necessarily infer that the hardware components, circuits, software, and / or elements for implementing these functions will be partitioned, omitted, or included in an embodiment.

[0078] Some examples may be described using the recitations “coupled” and “connected” and their derivatives. For example, a description using the terms “connected” and / or “coupled” may indicate that two or more elements make direct physical or electrical contact. However, the term “coupled” may also mean that two or more elements do not make direct contact but still cooperate or interact.

[0079] Terms such as "first", "second", etc. do not denote any order, quantity, or importance herein, but are used to distinguish one element from another. The term "a" herein does not denote a limitation on quantity, but rather denotes the presence of at least one of the items mentioned. The term "assert" when referring to a signal herein refers to a state of the signal in which the signal is valid, and this state can be achieved by applying any logic level (either logic 0 or logic 1) to the signal. The term "subsequently" or "afterward" can refer to immediately following or following after some other event or events. According to alternative embodiments, other sequences of operations may also be performed. Additionally, depending on the particular application, additional operations may be added or removed. Any combination of variations may be used, and those of ordinary skill in the art benefiting from this disclosure will understand many variations, modifications, and alternative embodiments thereof.

[0080] Unless otherwise specifically stated, disjunctive language such as the phrase "at least one of X, Y, or Z" is understood within the context to generally mean that an item, term, etc. can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language generally does not and should not imply that certain embodiments require the presence of at least one X, at least one Y, or at least one Z. Additionally, unless otherwise specifically stated, conjunctive language such as the phrase "at least one of X, Y, and Z" should also be understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z".

[0081] Illustrative examples of the devices, systems, and methods disclosed herein are provided below. Embodiments of the devices, systems, and methods may include any one or more of the examples described below, as well as any combination thereof.

[0082] Example 1 includes one or more examples and includes an apparatus that includes: a network interface device that includes: a device interface; a direct memory access (DMA) circuit; a network interface; a processor; and circuitry for booting from a network source, obtaining one or more boot images from the network source, and subsequently operating as a network boot server for at least one other device.

[0083] Example 2 includes one or more examples, wherein the network interface device includes one or more of the following: a network interface controller (NIC), a NIC supporting remote direct memory access (RDMA), an intelligent NIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

[0084] Example 3 includes one or more examples, wherein the circuitry is for providing a network boot service to a host system.

[0085] Example 4 includes one or more examples, wherein the circuit is used to provide a network boot service to a second system or a second network interface device.

[0086] Example 5 includes one or more examples, wherein the at least one other device includes a composite system formed by devices connected through a network, fabric, or interconnect.

[0087] Example 6 includes one or more examples, wherein the one or more boot images include one or more of the following: boot firmware, operating system (OS), applications, full disk images, drivers, process states, device states, or virtual machine migrations.

[0088] Example 7 includes one or more examples, wherein the network boot server operates in a manner compliant with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, DHCP server for Windows, ERPXE, or Tiny PXE Server and TinyWeb.

[0089] Example 8 includes one or more examples and includes at least one non-transitory computer-readable medium having instructions stored thereon that, if executed by one or more processors of a network interface device, cause the one or more processors to: request the boot software from a network boot server based on a processor among the one or more processors being unable to access the boot software for execution; intercept a request for the boot software from a host system received via a device interface; and provide the boot software to the host system via the device interface for execution by the host system, wherein the boot software includes one or more of the following: boot firmware or operating system (OS).

[0090] Example 9 includes one or more examples and includes instructions stored thereon that, if executed by one or more processors of a network interface device, cause the one or more processors to: communicate with the host system as the network boot server.

[0091] Example 10 includes one or more examples and includes instructions stored thereon that, if executed by one or more processors of a network interface device, cause the one or more processors to: intercept communication from the host system to the network boot server and provide boot software options to the host system.

[0092] Example 11 includes one or more examples, wherein the boot software includes one or more of the following: Basic Input / Output System (BIOS), Unified Extensible Firmware Interface (UEFI), boot loader, or operating system (OS).

[0093] Example 12 includes one or more examples, wherein the network boot server operates in a manner compliant with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, DHCP server for Windows, ERPXE, or Tiny PXE server and TinyWeb.

[0094] Example 13 includes one or more examples, wherein the network interface device includes one or more of the following: Network Interface Controller (NIC), NIC supporting Remote Direct Memory Access (RDMA), intelligent NIC, router, switch, forwarding element, Infrastructure Processing Unit (IPU), Data Processing Unit (DPU), or Edge Processing Unit (EPU).

[0095] Example 14 includes one or more examples and includes a method that includes: a network interface device performing: retrieving boot software from a boot software server and installing the boot software for execution by a processor of the network interface device and a host system connected to the network interface device via a device interface, wherein the boot software includes one or more of the following: boot firmware or operating system (OS), and wherein the network interface device includes: the device interface; Direct Memory Access (DMA) circuitry; a network interface; and the processor.

[0096] Example 15 includes one or more examples and includes the network interface device performing: requesting the boot software from the boot software server based on the boot of the processor and the inability of the processor of the host system to access the boot software for execution; intercepting a request for the boot software from the host system received via the device interface; and providing the boot software to the host system via the device interface for execution by the host system.

[0097] Example 16 includes one or more examples and includes the network interface device communicating with the host system as the boot software server.

[0098] Example 17 includes one or more examples and includes the network interface device intercepting communications from the host system to the network interface device and providing boot software options to the host system.

[0099] Example 18 includes one or more examples, wherein the boot software includes one or more of the following: Basic Input / Output System (BIOS), Unified Extensible Firmware Interface (UEFI), or boot loader.

[0100] Example 19 includes one or more examples, wherein the boot software server operates in a manner compliant with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, DHCP server for Windows, ERPXE, or Tiny PXE Server and TinyWeb.

[0101] Example 20 includes one or more examples, wherein the network interface device includes one or more of the following: Network Interface Controller (NIC), NIC supporting Remote Direct Memory Access (RDMA), Smart NIC, router, switch, forwarding element, Infrastructure Processing Unit (IPU), Data Processing Unit (DPU), or Edge Processing Unit (EPU).

Claims

1. A device comprising: A network interface device comprising: Device interface; Direct memory access (DMA) circuitry; Network interface; Processor; and Circuitry for booting from a network source, obtaining one or more boot images from the network source, and then operating as a network boot server for at least one other device.

2. The device according to claim 1, wherein: The network interface device includes one or more of the following: a network interface controller (NIC), a NIC supporting remote direct memory access (RDMA), an intelligent NIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

3. The device according to claim 1, wherein: The circuit is used to provide network boot services to a host system.

4. The device according to claim 1, wherein: The circuit is used to provide network boot service to the second system or the second network interface device.

5. The device according to claim 1, wherein: The at least one other device includes a composite system formed by devices connected by a network, structure or interconnect.

6. The device according to claim 1, wherein: The one or more boot images include one or more of: boot firmware, an operating system (OS), an application, a full disk image, a driver, a process state, a device state, or a virtual machine migration.

7. The device according to any one of claims 1 to 6, wherein: The network boot server operates in a manner consistent with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva32 / 64, Windows' DHCP server, ERPXE, or Tiny PXE server and TinyWeb.

8. At least one non-transitory computer-readable medium, the medium comprising instructions stored thereon, the instructions, if executed by one or more processors of a network interface device, causing the one or more processors to: requesting the boot software from a network boot server based on a processor of the one or more processors being unable to access the boot software for execution; intercepting a request for the startup software received from the host system via the device interface; and The boot software is provided to the host system via the device interface for execution by the host system, wherein the boot software includes one or more of: boot firmware or an operating system (OS).

9. The non-transitory computer readable medium of claim 8, comprising instructions stored thereon that, if executed by one or more processors of a network interface device, cause the one or more processors to: Communicates with the host system as the network boot server.

10. The non-transitory computer readable medium of claim 8, wherein: The boot software includes one or more of the following: a basic input / output system (BIOS), a universal extensible firmware interface (UEFI), a boot loader, or an operating system (OS).

11. The non-transitory computer readable medium of claim 8, wherein: The network boot server operates in a manner consistent with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, Windows' DHCP server, ERPXE, or Tiny PXE server and TinyWeb.

12. The non-transitory computer readable medium of claim 8, wherein: The network interface device includes one or more of the following: a network interface controller (NIC), a NIC supporting remote direct memory access (RDMA), an intelligent NIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

13. The non-transitory computer readable medium of any one of claims 8-12, comprising instructions stored thereon that, if executed by one or more processors of a network interface device, cause the one or more processors to: Communications from the host system to the network boot server are intercepted and boot software options are provided to the host system.

14. A method comprising: The network interface device performs: Boot software is retrieved from a boot software server and installed for execution by a processor of the network interface device and a host system connected to the network interface device via a device interface, wherein the boot software includes one or more of: boot firmware or an operating system (OS), and wherein the network interface device includes: the device interface; direct memory access (DMA) circuitry; a network interface; and the processor.

15. The method of claim 14, comprising: The network interface device performs: Based on the activation of the processor and the inability of the processor of the host system to access the startup software for execution, requesting the startup software from the startup software server; intercepting a request for the startup software from the host system received via a device interface; and The startup software is provided to the host system via the device interface for execution by the host system.

16. The method of claim 15, comprising: The network interface device communicates with the host system as the boot software server.

17. The method of claim 15, comprising: The network interface device intercepts communications from the host system to the network interface device and provides a launch software option to the host system.

18. The method of claim 14, wherein: The boot software includes one or more of the following: a basic input / output system (BIOS), a universal extensible firmware interface (UEFI), or a boot loader.

19. The method of claim 14, wherein: The network interface device includes one or more of the following: a network interface controller (NIC), a NIC supporting remote direct memory access (RDMA), an intelligent NIC, a router, a switch, a forwarding element, an infrastructure processing unit (IPU), a data processing unit (DPU), or an edge processing unit (EPU).

20. The method according to claim 14, comprising: A network boot service is provided to one or more of: a host system, a second system, a second network interface device, or a composite system formed by devices connected via a network, fabric, or interconnect.

21. The method of any one of claims 14 to 20, wherein: The boot software server operates in a manner consistent with one or more of the following: Preboot Execution Environment (PXE), Hypertext Transfer Protocol (HTTP) boot, Serva 32 / 64, DHCP server for Windows, ERPXE, or Tiny PXE server and TinyWeb.

Images