Patent ID: 12197939

DETAILED DESCRIPTION

The present disclosure relates to provisioning data processing unit (DPU) management operating systems. The disclosure provides mechanisms that can deliver an installer image to provision a DPU with a management operating system (OS). The DPUs can be physically installed to host devices. The DPUs can include processors, a network interface, and in many cases can include acceleration engines capable of machine learning, networking, storage, and artificial intelligence processing. However, DPUs can be made by a wide variety of manufacturers. The interface and general operation can differ from DPU to DPU. This can pose problems for management services and enterprises that desire to fully utilize the capabilities of DPUs in host devices. The present disclosure describes mechanisms that can integrate DPUs into a virtualization and management solution by provisioning data processing unit DPU management operating systems.

With reference toFIG.1, shown is an example of a networked environment100. The networked environment100can include a management system103, host devices106, and other components in communication with one another over a network112. DPU devices109can be installed to the host devices106. In some cases, host devices106can include computing devices or server computing devices of a private cloud, public cloud, hybrid cloud, and multi-cloud infrastructures. Hybrid cloud infrastructures can include public and private host computing devices. Multi-cloud infrastructures can include multiple different computing platforms from one or more service providers in order to perform a vast array of enterprise tasks.

The host devices106can also include devices that can connect to the network112directly or through an edge device or gateway. The components of the networked environment100can be utilized to provide virtualization solutions for an enterprise. The hardware of the host devices106can include physical memory, physical processors, physical data storage, and physical network resources that can be utilized by virtual machines. Host devices106can also include peripheral components such as the DPU devices109. The host devices106can include physical memory, physical processors, physical data storage, and physical network resources. Virtual memory, virtual processors, virtual data storage, and virtual network resources of a virtual machine can be mapped to physical memory, physical processors, physical data storage, and physical network resources of the host devices106. The management hypervisor155can provide access to the physical memory, physical processors, physical data storage, and physical network resources of the host devices106to perform workloads130.

The DPU devices109can include networking accelerator devices, smart network interface cards, or other cards that are installed as a peripheral component. The DPU devices109themselves can also include physical memory, physical processors, physical data storage, and physical network resources. The DPU devices109can also include specialized physical hardware that includes accelerator engines for machine learning, networking, storage, and artificial intelligence processing. Virtual memory, virtual processors, virtual data storage, and virtual network resources of a virtual machine can be mapped to physical memory, physical processors, physical data storage, physical network resources, and physical accelerator resources of the DPU devices109. The DPU management OS165can communicate with the management hypervisor155and/or with the management service120directly to provide access to the physical memory, physical processors, physical data storage, physical network resources, and physical accelerator resources of the DPU devices109. However, the DPU management OS165, or an up-to-date version of the DPU management OS165may not be initially installed to the DPU device109.

Virtual devices including virtual machines, containers, and other virtualization components can be used to execute the workloads130. The workloads130can be managed by the management service120for an enterprise that employs the management service120. Some workloads130can be initiated and accessed by enterprise users through client devices. The virtualization data129can include a record of the virtual devices, as well as the host devices106and DPU devices109that are mapped to the virtual devices. The virtualization data129can also include a record of the workloads130that are executed by the virtual devices.

The network112can include the Internet, intranets, extranets, wide area networks (WANs), local area networks (LANs), wired networks, wireless networks, other suitable networks, or any combination of two or more such networks. The networks can include satellite networks, cable networks, Ethernet networks, telephony networks, and other types of networks.

The management system103can include one or more host or server computers, and any other system providing computing capability. In some examples, a subset of the host devices106can provide the hardware for the management system103. While referred to in the singular, the management system103can include a plurality of computing devices that are arranged in one or more server banks, computer banks, or other arrangements. The management system103can include a grid computing resource or any other distributed computing arrangement. The management system103can be multi-tenant, providing virtualization and management of workloads130for multiple different enterprises. Alternatively, the management system103can be customer or enterprise-specific.

The computing devices of the management system103can be located in a single installation or can be distributed among many different geographical locations which can be local and/or remote from the other components. The management system103can also include or be operated as one or more virtualized computer instances. For purposes of convenience, the management system103is referred to herein in the singular. Even though the management system103is referred to in the singular, it is understood that a plurality of management systems103can be employed in the various arrangements as described above.

The components executed on the management system103can include a management service120, as well as other applications, services, processes, systems, engines, or functionality not discussed in detail herein. The management service120can be stored in the data store123of the management system103. While referred to generally as the management service120herein, the various functionalities and operations discussed can be provided using a management service120that includes a scheduling service and a number of software components that operate in concert to provide compute, memory, network, and data storage for enterprise workloads and data. The management service120can also provide access to the enterprise workloads and data executed by the host devices106and can be accessed using client devices that can be enrolled in association with a user account126and related credentials.

The management service120can communicate with associated management instructions executed by host devices106, client devices, edge devices, and IoT devices to ensure that these devices comply with their respective compliance rules124, whether the specific host device106is used for computational or access purposes. If the host devices106or client devices fail to comply with the compliance rules124, the respective management instructions can perform remedial actions including discontinuing access to and processing of workloads130.

The data store123can include any storage device or medium that can contain, store, or maintain the instructions, logic, or applications described herein for use by or in connection with the instruction execution system. The data store123can be a hard drive or disk of a host, server computer, or any other system providing storage capability. While referred to in the singular, the data store123can include a plurality of storage devices that are arranged in one or more hosts, server banks, computer banks, or other arrangements. The data store123can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples include solid-state drives or flash drives. The data store123can include a data store123of the management system103, mass storage resources of the management system103, or any other storage resources on which data can be stored by the management system103. The data store123can also include memories such as RAM used by the management system103. The RAM can include static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), and other types of RAM.

The data stored in the data store123can include management data including device data122, enterprise data, compliance rules124, user accounts126, and device accounts128, as well as other data. Device data122can identify host devices106by one or more device identifiers, a unique device identifier (UDID), a media access control (MAC) address, an internet protocol (IP) address, or another identifier that uniquely identifies a device with respect to other devices.

The device data122can include an enrollment status indicating whether each computing device is enrolled with or managed by the management service120. For example, an end-user device, an edge device, IoT device, host device106, client device, or other devices can be designated as “enrolled” and can be permitted to access the enterprise workloads and data hosted by host devices106, while those designated as “not enrolled,” or having no designation, can be denied access to the enterprise resources. The device data122can further include indications of the state of IoT devices, edge devices, end user devices, host device106, and other devices. While a user account126can be associated with a particular person as well as client devices, a device account128can be unassociated with any particular person, and can nevertheless be utilized for an IoT device, edge device, or another client device that provides automatic functionalities.

Device data122can also include data pertaining to user groups. An administrator can specify one or more of the host devices106as belonging to a user group. The user group can refer to a group of user accounts126, which can include device accounts128. User groups can be created by an administrator of the management service120.

Compliance rules124can include, for example, configurable criteria that must be satisfied for the host devices106and other devices to be in compliance with the management service120. The compliance rules124can be based on a number of factors, including geographical location, activation status, enrollment status, and authentication data, including authentication data obtained by a device registration system, time, and date, and network properties, among other factors associated with each device. The compliance rules124can also be determined based on a user account126associated with a user.

Compliance rules124can include predefined constraints that must be met in order for the management service120, or other applications, to permit host devices106and other devices access to enterprise data and other functions of the management service120. The management service120can communicate with management instructions on the client device to determine whether states exist on the client device which do not satisfy one or more of the compliance rules124. States can include, for example, a virus or malware being detected; installation or execution of a blacklisted application; and/or a device being “rooted” or “jailbroken,” where root access is provided to a user of the device. Additional states can include the presence of particular files, questionable device configurations, vulnerable versions of applications, vulnerable states of the client devices or other vulnerability, as can be appreciated. While the client devices can be discussed as user devices that access or initiate workloads130that are executed by the host devices106, all types of devices discussed herein can also execute virtualization components and provide hardware used to host workloads130.

The management service120can oversee the management and resource scheduling using hardware provided using host devices106. The management service120can transmit various software components, including enterprise workloads, enterprise data, and other enterprise resources for processing and storage using the various host devices106. The host devices106can include host devices106such as a server computer or any other system providing computing capability, including those that compose the management system103.

Host devices106can include public, private, hybrid cloud and multi-cloud devices that are operated by third parties with respect to the management service120. The host devices106can be located in a single installation or can be distributed among many different geographical locations which can be local and/or remote from the other components.

The host devices106can include DPU devices109that are connected to the host device106through a universal serial bus (USB) connection, a Peripheral Component Interconnect Express (PCI-e) or mini-PCI-e connection, or another physical connection. DPU devices109can include hardware accelerator devices specialized to perform artificial neural networks, machine vision, machine learning, and other types of special purpose instructions written using CUDA, OpenCL, C++, and other instructions. The DPU devices109can utilize in-memory processing, low-precision arithmetic, and other types of techniques. The DPU devices109can have hardware including a network interface controller (NIC), CPUs, data storage devices, memory devices, and accelerator devices.

The management service120can include a scheduling service that monitors resource usage of the host devices106, and particularly the host devices106that execute enterprise workloads130. The management service120can also track resource usage of DPU devices109that are installed on the host devices106. The management service120can track the resource usage of DPU devices109in association with the host devices106to which they are installed. The management service120can also track the resource usage of DPU devices109separately from the host devices106to which they are installed.

In some examples, the DPU devices109can execute workloads130assigned to execute on host devices106to which they are installed. For example, the management hypervisor155can communicate with a DPU management OS165to offload all or a subset of a particular workload130to be performed using the hardware resources of a DPU device109. Alternatively, the DPU devices109can execute workloads130assigned specifically to the DPU device109or to a virtual device that includes the hardware resources of a DPU device109. In some examples, the management service120can communicate directly with the DPU management OS165, and in other examples the management service120can use the management hypervisor155to communicate with the DPU management OS165.

The host device106can include a management component151. The management component151can communicate with the management service120for scheduling of workloads130executed using virtual resources that are mapped to the physical resources of one or more host device106. The management component151can communicate with the management hypervisor155to deploy virtual devices that perform the workloads130. In various embodiments, the management component151can be separate from, or a component of, the management hypervisor155. The management component151can additionally or alternatively be installed to the DPU device109. The management component151of a DPU device109can be separate from, or a component of, the DPU management OS165.

The host device106can include a management hypervisor installer153, a management hypervisor155, an installer server component157, a baseboard management controller (BMC)159, and a DPU management operating system (OS) installer161image. The management hypervisor installer153can refer to one or more installation file, executable, or other program instructions that install the management hypervisor155on the host device106. The management hypervisor installer153can be downloaded, otherwise transferred over a network112, or provided using a physical medium attached to a physical connection to the host device106.

The management hypervisor installer153can install the management hypervisor155to the host device106. In some cases, the management hypervisor installer153can also install the management component151as a user mode or kernel mode application that works in concert with the management hypervisor155. The management hypervisor installer153can include or temporarily install the installer server component157. Generally, the management hypervisor installer153can communicate and work in concert with the BMC159to identify DPU devices109and orchestrate the delivery of the DPU management OS installer161image to the DPU device109.

The management hypervisor155can include a bare metal or type1hypervisor that can provide access to the physical memory, physical processors, physical data storage, and physical network resources of the host devices106to perform workloads130. A management hypervisor155can create, configure, reconfigure, and remove virtual machines and other virtual devices on a host device106. The management hypervisor155can also relay instructions from the management service120to the DPU management OS165. In other cases, the management service120can communicate with the DPU management OS165directly. The management hypervisor155can identify that a workload130or a portion of a workload130includes instructions that can be executed using the DPU device109, and can offload these instructions to the DPU device109.

The installer server component157can be used by the management hypervisor installer153, which is used as a server to serve the DPU management OS installer161image. The installer server component157can be executed using the host device106, and can include an executable program that is part of the management hypervisor installer153, installed by the management hypervisor installer153, or otherwise used in concert with the management hypervisor installer153as a server to serve the DPU management OS installer161image.

The BMC159can include a specialized processor, chip, system-on-chip, or other hardware devices used for remote monitoring and management of the host device106. The BMC159can be part of the motherboard or baseboard of the host device106. The BMC159can be accessed using a network connection. The BMC159can access the installer server component157using this network connection, although the BMC159can be considered part of the same host device106by being located on the motherboard.

The BMC159can include the ability to power off, power on, and otherwise power cycle the host device106. The BMC159can include or use sensors to identify hardware and software configurations of the host device106. For example, the BMC159can identify a list of all the DPU devices109installed to the host device106. The BMC159can also include the ability to transmit commands to the DPU device109using BMC-to-DPU interfaces such as network controller sideband interface (NC-SI), General Purpose Input/Output (GPIO), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C or IIC), synchronous or asynchronous serial busses, and others. The commands can include a command to reset the DPU device109. The commands can also include commands to use a network boot process. Alternatively, the DPU device109can be set by default or by a manufacturer to use a network boot process if available.

The DPU device109, when reset, can transmit a request for pending image data or updates from the BMC159. The BMC159can receive the request for pending image data updates, and can use the uniform resource identifier (URI) to retrieve the DPU management OS installer161image. For example, this can include using Unified Extensible Firmware Interface (UEFI) or other mechanisms to fetch OS data including the DPU management OS installer161image remotely. The mechanisms can include HTTP boot, Preboot execution Environment (PXE) boot, or another network boot process, which can be set before or after the reset command. A UEFI mechanism such as UEFI secure boot can also validate integrity. The UEFI secure boot process can also use a signed UEFI bootloader application, which is responsible for further checks.

The DPU management OS installer161image can be a specially prepared image that can be mounted from a RAM disk, an in-memory volatile block device, in-memory volatile disk, or another volatile memory virtual disk of the DPU device109. The image data includes DPU management OS installer161image that can be mounted and executed on the next bootup of the DPU device109, in order to install the DPU management OS165using an install process from the RAM disk of the DPU management OS installer161image. The DPU UEFI163can change the boot options to boot to the RAM disk of the DPU management OS installer161image or another volatile memory based virtual disk. This can include using HTTP boot or PXE boot. Once the DPU management OS165is installed, the DPU UEFI163can update the boot options again to UEFI secure boot or otherwise boot to the DPU management OS165installed to eMMC or another nonvolatile memory.

While the discussion generally refers to an initial provisioning of the DPU management OS165, the process can also be used to provide automatic updates to the DPU management OS165on each reboot or reset of the DPU device109. In the OS update example, the server component can be launched by, or can be part of, the management component151or the management hypervisor155. The management service120can transmit a command to update the OS, and the management component151or the management hypervisor155can launch the server component, and can perform the other steps and actions discussed as performed by the management hypervisor installer153.

The DPU device109can include a DPU UEFI163and the DPU management OS165. The DPU UEFI163of the DPU device109can include preinstalled, such as factory installed, manufacturer installed, or supplier installed instructions that identify that the DPU management OS installer161image includes an installer for a DPU management OS165. The DPU UEFI163can then write or store the DPU management OS installer161image to RAM or volatile memory, and update boot options, and boot to a RAM disk or another volatile memory virtual disk, and configure boot options and boot order to boot to the volatile memory virtual disk with the DPU management OS installer161. The internal memory or data store of the DPU device109can include an Embedded MultiMediaCard (eMMC), a solid-state memory, a flash memory, or another nonvolatile memory. The internal memory or data store of the DPU device109can also include the volatile memory that can be used for the RAM disk or another volatile memory virtual disk. The DPU management OS installer161can install the DPU management OS165to the eMMC or another nonvolatile memory.

The DPU management OS165can be a management-service-specific operating system that enables the management service120to manage the DPU device109and assign workloads130to execute using its resources. The DPU management OS165can communicate with the management hypervisor155and/or with the management service120directly to provide access to the physical memory, physical processors, physical data storage, physical network resources, and physical accelerator resources of the DPU devices109. However, the DPU management OS165, or an up-to-date version of the DPU management OS165may not be initially installed to the DPU device109. In some cases, since the DPU devices109can vary in form and function, DPU management OS165can be DPU-device-type specific for a device type such as a manufacturer, product line, or model type of a DPU device109.

FIG.2is a sequence diagram that provides an example of the operation of components of the networked environment100to provision a DPU device109with a DPU management OS165. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step. Generally, this figure shows how the management hypervisor installer153works in concert with the DPU UEFI163, the BMC159, and other components in order to provision the DPU device109with the DPU management OS165.

In step203, the management hypervisor installer153can request a DPU device list from the BMC159. The management hypervisor installer153can transmit a request or command that causes the BMC159to return a DPU device list. The BMC159can maintain the list based on periodic updates, or can identify all DPU devices109and create the list in response to the request.

In step206, the management hypervisor installer153can receive the DPU device list from the BMC159. The DPU device list or another data structure can include and specify information about one or more than one DPU device109. The information can include a DPU device identifier of each DPU device109, a DPU type such as a manufacturer and model number of the DPU device109, and other data.

In step209, the management hypervisor installer153can identify supported accelerators or DPU devices109from the list. The management hypervisor installer153can then generate a user interface that identifies the DPU devices109and obtains a user indication to copy the DPU management OS165to the supported DPU devices109. While the discussion can refer to a particular DPU device109, the process can be repeated sequentially, simultaneously, or with partial concurrence for all supported DPU devices109.

The management hypervisor installer153can maintain a list or another data structure that indicates DPU types that are supported by the management hypervisor155and for which a DPU management OS installer161image is available and configurable. In some examples, the management hypervisor installer153can include one or more DPU management OS installer161images. Since a DPU device109can be a specialized hardware device, a different DPU management OS165and corresponding DPU management OS installer161can be used for each supported DPU device type.

In step212, the management hypervisor installer153can generate a DPU management OS installer161image. The management hypervisor installer153can identify a DPU management OS installer161image that installs a DPU management OS165for the DPU device type of the DPU device109. The management hypervisor installer153can also identify a configuration for the DPU management OS165and modify the DPU management OS installer161image to install the DPU management OS165according to a specified configuration. Modifying the image can include modifying installation parameters and other data.

The configuration can be identified based on the DPU device type of the DPU device109, or can be identified based on other parameters of the host device106or a user of the host device106. The management hypervisor installer153image or a header used for the image can include a parameter that is associated with a DPU management OS165or the DPU management OS installer161. In other words, the parameter can identify the image data as a DPU management OS installer161image. The parameter can be an EFI GUID parameter that specifies a particular GUID that is associated with the DPU management OS165or the DPU management OS installer161.

In step215, the management hypervisor installer153can provide or transmit the DPU management OS installer161image to the installer server component157. The management hypervisor installer153or the installer server component157can store the DPU management OS installer161image locally to a data store of the host device106. The management hypervisor installer153or the installer server component157can then generate a URI through which the DPU management OS installer161image can be accessed over an network internal to the host device106. In some examples, the management hypervisor installer153can transmit this DPU management OS installer URI to the management hypervisor installer153.

In step218, the management hypervisor installer153can transmit the DPU management OS installer URI to the BMC159. This transmission can identify the URI as an image data update URI for an update such as a firmware update or another kind of update for the DPU device109. The URI can be transmitted along with an identifier of the DPU device109and an indication that the URI is for the firmware update. The BMC159can store the DPU management OS installer URI. The process can then move toFIG.3.

FIG.3is a sequence diagram that provides an example of the operation of components of the networked environment100to provision a DPU device109with a DPU management OS165. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step. Generally, this figure continues the example ofFIG.2.

In step303, the BMC159can reset the DPU device109. The BMC159can transmit a command to the DPU device109that causes the DPU device109to reset. In some examples, the management hypervisor installer153can use the BMC159to reset the DPU device109. The management hypervisor installer153can transmit a command to the BMC159that instructs the BMC159to reset the DPU device109. This can include communications using NC-SI, synchronous or asynchronous serial busses, PCIe, I2C, SPI, and GPIO among others.

In step306, the BMC159can receive a request for pending image data, or a request for updates from the DPU UEFI163of the DPU device109. This can be part of a startup process of the DPU device109. The request can be part of an HTTP boot or PXE boot process. In some examples, the request can specify an identifier of the DPU device109, and the BMC159can identify pending image data based on the identifier. If pending image data is available, the BMC159can return an indication that there is pending image data available. In some cases, the DPU UEFI163of the DPU device109can provide a separate request that instructs the BMC159to retrieve and relay the DPU management OS installer161image from the installer server component157. Otherwise the process can proceed without further instruction from the DPU UEFI163.

In step309, the BMC159can retrieve and relay the DPU management OS installer161image from the installer server component157to the DPU device109. This can include retrieving and relaying the DPU management OS installer161image from the installer server component157to the DPU device109as part of an HTTP boot or PXE boot process to boot from the installer server component157. The BMC159can use the URI that was provided by the management hypervisor installer153to access the DPU management OS installer161image. The BMC159can temporarily store the DPU management OS installer161image. Alternatively, the BMC159can stream the DPU management OS installer161image to the DPU device109without storing it. The BMC159can also retrieve the DPU management OS installer161image in a number of chunks that are then forwarded or relayed to the DPU device109in sequence, in parallel, or with partial concurrence.

The DPU UEFI163can identify whether the received image data includes an installer for a DPU management OS165. In other words, the DPU UEFI163can identify the image data as a DPU management OS installer161image that installs a DPU management OS165. For example, the DPU UEFI163can verify that the received DPU management OS installer161image includes a parameter or indication that identifies it to include or install a DPU management OS165. The DPU UEFI163can include a specific component or mechanism that can identify whether the received DPU management OS installer161image includes a DPU management OS165based on a parameter specified in the header, by parsing another portion of the image data.

In step312, the DPU UEFI163can mount the DPU management OS installer161image as a RAM disk, an in-memory volatile block device, in-memory volatile disk, or another volatile memory based virtual disk of the DPU device109. The DPU UEFI163can create the volatile memory based virtual disk using the DPU management OS installer161image and then mount it. The DPU UEFI163can also update boot options and the order of the DPU device109to boot to the volatile memory based virtual disk created using the DPU management OS installer161image. The HTTP boot or PXE boot process can cause the DPU device109to boot to the volatile memory based virtual disk created using the DPU management OS installer161image. The boot options and order can include a set of options and order that are pre-stored as part of the DPU UEFI163or received through BMC-to-DPU communications using NC-SI, synchronous or asynchronous serial busses, PCIe, I2C, SPI, and GPIO among others.

In step315, the DPU UEFI163can instruct the DPU device109boot to the DPU management OS installer161. The DPU UEFI163can continue to boot the DPU device109into the DPU management OS installer161once the boot options and the order of the DPU device109are set to boot to the DPU management OS installer161.

In step318, the DPU management OS installer161can execute and perform an installation process that installs the DPU management OS165. The DPU management OS installer161can install the DPU management OS165and then provide an indication to the DPU UEFI163that the DPU management OS165is installed. While the DPU management OS installer161is executed using a volatile memory based virtual disk, the DPU management OS165is installed to a nonvolatile memory of the DPU device109, according to a specified configuration.

In step321, the DPU UEFI163can configure boot options and the order of the DPU device109to boot to the DPU management OS165. For example, the DPU UEFI163can configure the boot order so that the DPU management OS165is listed first in the boot order. The boot options and order can include a set of options and order that are pre-stored as part of the DPU UEFI163. The boot options and order can include a set of options and orders that are indicated as a parameter received in the DPU management OS installer161image or header.

In step324, the DPU UEFI163can instruct the DPU device109boot to the DPU management OS165on nonvolatile memory of the DPU device109. In some examples, the DPU UEFI163can reboot the DPU device109once the boot options and order of the DPU device109are set to boot to the DPU management OS165. The DPU management OS165can initialize and transmit an indication to the BMC159that it is initialized and running. The BMC159can transmit an indication to the management hypervisor installer153that the provisioning of the DPU management OS165is completed, and the management hypervisor installer153can stop executing the installer server component157.

FIG.4shows a flowchart400that provides an example of the operation of components of the networked environment100to provision a DPU device109. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step. Generally, this figure shows how the management hypervisor installer153works in concert with the DPU UEFI163, the BMC159, and other components in order to provision the DPU device109with the DPU management OS165.

In step403, the management hypervisor installer153can receive a DPU device list from the BMC159. The DPU device list or another data structure can include and specify information about one or more than one DPU device109. The information can include a DPU device identifier of each DPU device109, a DPU type such as a manufacturer and model number of the DPU device109, and other data. The management hypervisor installer153can transmit a request or command that causes the BMC159to return a DPU device list. The BMC159can maintain the list based on periodic updates, or can identify all DPU devices109and create the list in response to the request.

In step406, the management hypervisor installer153can identify supported accelerators or DPU devices109from the DPU device list. The management hypervisor installer153can then generate a user interface that identifies the DPU devices109and obtains a user indication to install the DPU management OS165to the supported DPU devices109. While the discussion can refer to a particular DPU device109, the process can be repeated sequentially, simultaneously, or with partial concurrence for all supported DPU devices109.

In step409, the management hypervisor installer153can generate a DPU management OS installer161image. The management hypervisor installer153can identify a DPU management OS installer161image that installs a DPU management OS165for the DPU device type of the DPU device109. The management hypervisor installer153can also identify a configuration for the DPU management OS165and modify the DPU management OS installer161image to install the DPU management OS165according to a specified configuration.

In step412, the management hypervisor installer153can launch the installer server component157that provides the DPU management OS installer161image at a particular URI. The management hypervisor installer153or the installer server component157can store the DPU management OS installer161image locally to a data store of the host device106. The management hypervisor installer153or the installer server component157can generate the URI through which the DPU management OS installer161image can be accessed over a network internal to the host device106. In some examples, the management hypervisor installer153can transmit this DPU management OS installer URI to the installer server component157or otherwise instruct the installer server component157to provide access to the DPU management OS installer161image at the URI.

In step415, the management hypervisor installer153can transmit the DPU management OS installer URI to the BMC159. This transmission can identify the URI as an image data update URI for an update such as a firmware update or another kind of update for the DPU device109. The URI can be transmitted along with an identifier of the DPU device109and an indication that the URI is used for the firmware update. The BMC159can store the DPU management OS installer URI.

In step418, the management hypervisor installer153can use the BMC159to reset the DPU device109. The management hypervisor installer153can transmit a command to the BMC159that instructs the BMC159to reset the DPU device109. The BMC159can transmit a command to the DPU device109, or otherwise cause the DPU device109to power cycle or reset.

The BMC159can receive a request for pending image data, or a request for updates from the DPU UEFI163of the DPU device109. This can be part of a startup process of the DPU device109. In some examples, the request can specify an identifier of the DPU device109, and the BMC159can identify pending image data based on the identifier. If pending image data is available, the BMC159can return an indication that there is pending image data available. In some cases, the DPU UEFI163of the DPU device109can provide a separate request that instructs the BMC159to retrieve and relay the DPU management OS installer161image from the installer server component157. Otherwise the process can proceed without further instruction from the DPU UEFI163.

In step421, the management hypervisor installer153can receive a request specifying the DPU management OS installer URI. The BMC159can transmit a request to retrieve image data using the DPU management OS installer URI the installer server component157of the management hypervisor installer153can process the request.

In step424, the installer server component157of the management hypervisor installer153can transmit or serve the DPU management OS installer161image to the BMC159. The BMC159can relay the DPU management OS installer161image from the installer server component157to the DPU device109. The BMC159can temporarily store the DPU management OS installer161image. Alternatively, the BMC159can stream the DPU management OS installer161image to the DPU device109without storing it. The BMC159can also retrieve the DPU management OS installer161image in a number of chunks that are then forwarded or relayed to the DPU device109in sequence, in parallel, or with partial concurrence.

The DPU UEFI163can identify whether the received image data includes an installer for a DPU management OS165. In other words, the DPU UEFI163can identify the image data as a DPU management OS installer161image that installs a DPU management OS165. For example, the DPU UEFI163can verify that the received DPU management OS installer161image includes a parameter or indication that identifies it to include or install a DPU management OS165. The DPU UEFI163can include a specific component or mechanism that can identify whether the received DPU management OS installer161image includes a DPU management OS165based on a parameter specified in the header, by parsing another portion of the image data.

FIG.5shows a flowchart500that provides an example of the operation of components of the networked environment100to provision a DPU device109. While a particular step can be discussed as being performed by a particular hardware or software component of the networked environment100, other components can perform aspects of that step. Generally, this figure shows how the DPU UEFI163works in concert with the management hypervisor installer153, the BMC159, and other components in order to provision the DPU device109with the DPU management OS165. The flowchart500can generally follow the flowchart400ofFIG.4, but certain actions of the combined set of steps of the flowcharts can be scrambled relative to one another.

In step503, the DPU UEFI163can mount the DPU management OS installer161image as a RAM disk or another volatile memory based virtual disk. The DPU UEFI163can create the volatile memory based virtual disk using the DPU management OS installer161image and then mount it.

In step506, the DPU UEFI163can update boot options and the order of the DPU device109to boot to the DPU management OS installer161. In other words, the DPU UEFI163can cause the DPU device109to boot to the volatile memory based virtual disk created using the DPU management OS installer161image. For example, the DPU UEFI163can configure the boot order so that the volatile memory based virtual disk and the DPU management OS installer161is listed first in the boot order. The boot options and order can include a set of options and order that are pre-stored as part of the DPU UEFI163. The boot options and order can include a set of options and orders that are indicated as a parameter received in the DPU management OS installer161image or header.

In step509, the DPU UEFI163can instruct the DPU device109to boot to the DPU management OS installer161. The DPU UEFI163can reboot the DPU device109once the boot options and the order of the DPU device109are set to boot to the DPU management OS installer161. The DPU management OS installer161can execute and perform an installation process that installs the DPU management OS165. The DPU management OS installer161can install the DPU management OS165and then provide an indication to the DPU UEFI163that the DPU management OS165is installed. While the DPU management OS installer161is executed using a volatile memory based virtual disk, the DPU management OS165is installed to a nonvolatile memory of the DPU device109, according to a specified configuration.

In step512, the DPU UEFI163can configure boot options and order of the DPU device109to boot to the DPU management OS165. For example, the DPU UEFI163can configure the boot order so that the DPU management OS165is listed first in the boot order. The boot options and order can include a set of options and order that are pre-stored as part of the DPU UEFI163. The boot options and order can include a set of options and orders that are indicated as a parameter received in the DPU management OS installer161image or header.

In step515, the DPU UEFI163can instruct the DPU device109to boot to the DPU management OS165on nonvolatile memory. In some examples, the DPU UEFI163can reboot the DPU device109once the boot options and the order of the DPU device109are set to boot to the DPU management OS165. The DPU management OS165can initialize and transmit an indication to the BMC159that it is initialized and running. The BMC159can transmit an indication to the management hypervisor installer153that the provisioning of the DPU management OS165is completed.

The management hypervisor installer153can receive the indication that the DPU management OS165is executing on the DPU device. The management hypervisor installer153can instruct the server component to stop serving the DPU management OS installer161image, and remove it from the memory of the host device106. The management hypervisor installer153can also halt execution of the server component based on the indication that the DPU management OS165is executing on the DPU device109.

A number of software components are stored in the memory and executable by a processor. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of one or more of the memory devices and run by the processor, code that can be expressed in a format such as object code that is capable of being loaded into a random access portion of the one or more memory devices and executed by the processor, or code that can be interpreted by another executable program to generate instructions in a random access portion of the memory devices to be executed by the processor. An executable program can be stored in any portion or component of the memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

Memory devices can include both volatile and nonvolatile memory and data storage components. Also, a processor can represent multiple processors and/or multiple processor cores, and the one or more memory devices can represent multiple memories that operate in parallel processing circuits, respectively. Memory devices can also represent a combination of various types of storage devices, such as RAM, mass storage devices, flash memory, or hard disk storage. In such a case, a local interface can be an appropriate network that facilitates communication between any two of the multiple processors or between any processor and any of the memory devices. The local interface can include additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor can be of electrical or of some other available construction.

Although the various services and functions described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative, the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components.

The sequence diagrams and flowcharts can show examples of the functionality and operation of an implementation of portions of components described herein. If embodied in software, each block can represent a module, segment, or portion of code that can include program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that can include human-readable statements written in a programming language or machine code that can include numerical instructions recognizable by a suitable execution system such as a processor in a computer system or another system. The machine code can be converted from the source code. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although sequence diagrams and flowcharts can be shown in a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the drawings can be skipped or omitted.

Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or another system. In this sense, the logic can include, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system.

The computer-readable medium can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium include solid-state drives or flash memory. Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices.

It is emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations described for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiments without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included in the following claims herein, within the scope of this disclosure.