SERVER WITH NETWORK INTERFACE CARD BASEBOARD MANAGEMENT CONTROLLER
A single BMC on an intelligent network card manages both the host and network card, addressing complexity and cost issues in cloud-native server architectures by integrating management functions, thereby enhancing operational efficiency and security.
Patent Information
- Application Number
- DE102022108436
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-10-14
- Filing Date
- 2022-04-07
- Publication Date
- 2024-12-19
- Estimated Expiration
- 2042-04-07
AI Technical Summary
In cloud-native server architectures, the coordination between multiple baseboard management controllers (BMCs) for managing hosts and intelligent network cards increases complexity and cost, necessitating a more efficient management solution.
Implementing a single BMC on an intelligent network card to manage both the host and the network card, eliminating the need for separate BMCs and reducing coordination overhead.
This approach simplifies management, reduces complexity, and lowers costs by integrating BMC functions for both the host and intelligent network card, enhancing operational efficiency and security.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
BACKGROUND
[0001] To communicate with an external network, a computer platform may have a network interface card (NIC) (e.g., a Peripheral Component Interconnect Express (PCIe) bus card) that connects the platform's components to the network. Computer technology is constantly evolving, and newer computer platforms may feature "smart NICs." A smart network card not only provides network connectivity but can also offload processing traditionally performed by general-purpose central processing units (CPUs) of older computer platforms. US 2019 / 0 303 335 A1 describes an apparatus for providing a Baseboard Management Controller ("BMC") via an M.2 slot with a presence module that determines whether a BMC is connected to an M.2 expansion slot.US 2019 / 0 045 037 A1 describes a technology for network packet processing between cloud and telecommunications networks using a network computing device that includes two application layer packet translators (ALPTs). US 2014 / 0 280 837 A1 describes a baseboard management controller (BMC) that manages a computer system with N computer nodes. It is an object of the invention to propose a method, a system, and a non-transitory, machine-readable storage medium for managing a computer platform. This object is achieved by a method according to claim 1, a system according to claim 4, and a non-transitory, machine-readable storage medium according to claim 18. BRIEF DESCRIPTION OF THE DRAWINGS Fig. is a schematic diagram of a cloud-based computing system according to an example implementation. Fig. is a schematic diagram of an intelligent network interface card (NIC) used in a computer platform of the computer system of Fig. installed and which contains a base board management controller (BMC) for managing the computing platform according to an example implementation. Fig. shows a virtual BMC of the intelligent network card according to an example implementation. Fig. is a schematic diagram of a Smart NIC hardware BMC according to an example implementation. Fig. is a flowchart showing a process of a BMC with intelligent NIC for managing a computing platform according to an example implementation. Fig. is a flowchart showing the management of a boot process of a host of the computing platform by a BMC with intelligent NIC according to an example implementation. Fig. is a flowchart showing how a BMC with intelligent NIC manages system performance status according to a sample implementation. Fig. is a flowchart illustrating how a BMC with an intelligent NIC manages a boot path for a host of the computing platform, according to an example implementation. Fig. is a flowchart illustrating the thermal management of a computing platform by a BMC with intelligent NIC according to an example implementation. Fig. is a flowchart showing a process for deploying a BMC with intelligent NIC to manage a computing platform according to a sample implementation. Fig. is a schematic diagram of a system with a host, an intelligent network card, and a BMC of the intelligent network card that manages the system according to an example implementation. Fig. is an illustration of instructions stored on a non-transitory machine-readable storage medium that, when executed by a machine, cause the machine to provision a virtual BMC on an intelligent network card to manage a system that includes the intelligent network card and a host of the system, according to an example implementation. DETAILED DESCRIPTION
[0002] The IT industry is increasingly focused on the cloud, and server architectures are evolving accordingly to address the challenges posed by cloud service delivery. A multi-tenant cloud operator that provides cloud services to a large number of customers or tenants may rely on networked servers (e.g., blade servers) located in one or more data centers. A given server may run cloud-native software for multiple tenants; therefore, certain server resources may be considered to reside in an untrusted cloud tenant domain (or "client domain") because the domain is shared by more than one tenant.The execution of the tenant software may rely on input / output (I / O) services provided by the cloud operator, and these I / O services may be located in a trusted cloud operator domain separate from the client domain due to security restrictions enforced by the server.
[0003] More specifically, a set of resources of a particular server can be considered part of a "host." "In general, the host is traditionally considered the main control point for the server and includes the server's common processing hardware (e.g., common central processing units (CPUs), memory, etc.) and software that runs software instances (application instances, operating system instances, etc.) for the tenants and provides virtualization-based tenant isolation (e.g., virtual machines and containers) for the software instances. Thus, at least part of the host can be considered part of the client domain.
[0004] The I / O services provided by the cloud operator may include network services such as network virtualization services (e.g., overlay network services, virtual switching services, virtual routing services, and network function virtualization services), network storage services, network monitoring services, etc. The I / O services may also include storage acceleration services (e.g., NVMe-based services) and security services (e.g., cryptography services and network firewall services).
[0005] To address the increasing cloud-centricity of server processing, a cloud-native server architecture can offload processing operations traditionally performed by the main CPU in older server architectures to one or more server peripherals. In this context, a "peripheral" refers to a server component that provides one or more services or functions to the server host; in particular, according to example implementations, the peripheral may be an intelligent network card that provides one or more I / O services to tenant application instances running on the server.
[0006] In this context, a "smart network card" generally refers to a network card that, in addition to providing network connectivity to the server, provides one or more I / O services associated with the cloud operator (and the cloud operator domain). Here, the term "I / O service" refers to a service that involves the use of one or more network resources (e.g., resources accessible to the server through an external network) and performs a function other than, or in addition to, providing network connectivity to components of the server. As described above, the I / O service can be any of the above-mentioned services, such as a network service, a storage service, or a security service.
[0007] Unlike traditional server architectures where the host serves as the main control point for all server-related operations, the intelligent network interface card (NIC) in a native cloud server architecture can serve as the control point for the server. The intelligent NIC can enforce a boundary or isolation between the client domain and the cloud operator domain by providing two dual "air-gapped" security management and control interfaces on the server: a first "air-gapped" security management and control interface for transactions (e.g., communications, requests, responses, etc.) transferred from the tenant domain to the cloud operator domain, and a second "air-gapped" security management and control interface for transactions transferred from the cloud operator domain to the tenant domain.In this context, an "air-gapped interface" (such as the first air-gapped security management interface or the second air-gapped security management and control interface) refers to a communication interface that is isolated from an insecure network by software and / or hardware. The "air-gapped interface" may or may not correspond to actual physical isolation (e.g., the "air-gapped interface" may or may not involve the presence of an actual air gap in the communication path), depending on the specific implementation.
[0008] The server may include a special service processor called a "baseboard management controller" or "BMC," which is generally accessible remotely (for example, from a remote server located in a different geographic location than the server, such as a remote server located outside the data center where the server is located). Generally, the BMC serves as an agent that can manage the server's operation and functions in response to communications from a remote management server. This management is generally independent of the host, and the BMC can manage the host even if no software is installed on the host; and in accordance with example implementations, the BMC can perform management functions when the host is powered off due to a power supply that provides power to the BMC independently of the host.In this context, the term "host management" refers to the BMC performing one or more actions related to monitoring, maintaining, configuring, or controlling the host. Examples of BMC host management tasks include powering on the host, powering off the host, monitoring sensors (e.g., temperature sensors, fan speed sensors), monitoring the operating system status, monitoring the power status, logging computer system events, controlling boot paths, controlling the use of virtual media, controlling security checks, updating firmware, validating software, validating hardware, enabling host boot functionality, etc.In addition, the BMC can manage operations for the host before it is powered on, manage operations before the host's operating system has booted, and perform recovery operations after an operating system or computer system failure.
[0009] While legacy servers may contain a single BMC for managing the host, servers with cloud-native architectures can have multiple BMCs (e.g., one BMC for the host and one BMC for each server Smart NIC). This way, the intelligent network card can contain a BMC for managing operations and functions on the intelligent network card, such as powering on the intelligent network card, configuring the intelligent network card, booting the intelligent network card, monitoring the health of the intelligent network card, updating the intelligent network card's firmware, and so on. However, problems can arise when using multiple BMCs on the server, such as one BMC for the host and another BMC for an intelligent network card. For example, the host BMC may be responsible for overall management of the server.This means that management actions for the host and the intelligent network card can result in the intelligent network card BMC coordinating its management actions with the host BMC, and possibly vice versa. This coordination can consist, for example, of the intelligent network card BMC communicating with the host BMC to manage the power-on and / or power-off operations of the host, the intelligent network card, and / or the server. As further examples of coordination between BMCs, the smart NIC BMC can communicate with the host BMC to, for example, determine whether the host is powered on; determine whether the host has passed the error checks associated with powering on the host; determine whether the host has passed the security checks associated with powering on the host; the smart NIC BMC notifying the smart NIC BMC that the server is being powered off; and so on.Another example of coordination between BMCs is communication between the host BMC and the Smart NIC BMC regarding compatibility or the timing of firmware upgrades. Another example is communication between the host BMC and the Smart NIC BMC regarding a thermal issue on the Smart NIC, allowing the host BMC to adjust the fan speed. Therefore, the two BMCs can generally coordinate a number of management issues related to the host, the Smart NIC, and the entire server platform. This coordination between two BMCs can contribute to the overall complexity and cost of the server.
[0010] According to the example implementations described here, a computing platform (e.g., a server, a blade server, etc.) comprises a host and a Smart NIC installed in an expansion bus connector (e.g., a PCIe bus connector) of the computing platform. Instead of the host and the Smart NIC each containing a BMC, according to the example implementations, a single BMC resides on the Smart NIC; and this single BMC manages both the Smart NIC and the host. In other words, according to the example implementations, the BMC housed in the Smart NIC manages operations (e.g., power-on, configuration, boot-up, platform state control, firmware updates, etc.) of the host and manages operations (e.g., power-on, configuration, boot-up, platform state control, firmware updates, etc.) of the Smart NIC.Potential benefits of such an arrangement include reducing server costs and complexity by eliminating the overhead associated with coordination and collaboration between multiple BMCs.
[0011] With reference to Fig. As a more specific example, a cloud-based computer system 99 associated with a particular cloud operator may provide multi-tenant cloud services to multiple customers or tenants. The cloud services may be any of a variety of cloud services, such as Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and so on. Furthermore, depending on the implementation, the cloud services may be associated with any of a variety of cloud infrastructures, such as a public cloud available to all potential users over a public network, a private cloud with limited access provided over a private network (e.g., cloud services provided by an on-premises data center), or a hybrid cloud, which is a combination of public and private clouds.
[0012] Tenants can access cloud computing resources 100 (which provide the cloud services) of the system 99 via cloud clients 128 (e.g., laptops, desktop computers, smartphones, tablet computers, portable computers, etc.). As in Fig. As illustrated, the cloud computing resources 100 and the clients 128 may be interconnected by a network fabric 159. In general, the network fabric 159 may be interconnected by one or more types of communications networks, such as (as examples) Fibre Channel networks, Gen-Z fabrics, dedicated management networks, local area networks (LANs), wide area networks (WANs), global networks (e.g., the Internet), wireless networks, or any combination thereof.
[0013] In general, the cloud computing resources 100 are a shared pool of resources, including physical hardware resources such as physical servers (e.g., server blades), network components, management resources, physical storage devices, physical storage networks, and so on. Fig. shows a physical computing platform 100-1 that can provide at least a portion of the cloud computing resources 100. In this context, a "computing platform" refers to a unit comprising a chassis and hardware mounted on the chassis, the hardware capable of executing machine-executable instructions (or "software"). A blade server is an example of a computing platform 100-1 according to one example implementation. However, according to further implementations, the computing platform 100-1 may be a platform other than a blade server, such as a rack-mounted server, a client, a desktop, a smartphone, a laptop, a tablet computer, etc.
[0014] In example implementations where the computing platform 100-1 is a blade server, the server may have a frame or chassis; one or more motherboards may be attached to the chassis; and each motherboard may contain one or more multi-core central processing unit (CPU) semiconductor packages (or "sockets" or "chips"). Consistent with example implementations, the blade server may include a form factor, mechanical latch(es), and corresponding electrical connectors to allow the server blade to be installed and removed from a corresponding server blade opening or slot in a rack-mounted blade enclosure.
[0015] Regardless of its particular form, according to example implementations, computing platform 100-1 may have a native cloud architecture in which hardware resources and machine-executable instruction resources (i.e., "software resources") of computing platform 100-1 are divided into two security domains: a cloud tenant domain and a cloud operator domain. In this context, the "tenant domain" refers to the portion of computing platform 100-1 associated with executing tenant software and data; and, according to example implementations, the cloud operator (the entity providing cloud services) cannot access, or at least has limited access to, the tenant data and software. The "cloud operator domain" refers to the portion of computing platform 100-1 associated with providing I / O services to the executing tenant software.
[0016] More specifically, in accordance with some implementations, computing platform 100-1 includes a host 101 connected to the client domain. Host 101 includes an application layer 160 containing application instances that may be associated with one or more tenants at a given time. Virtualization technology may be employed on computing platform 100-1 to provide security and fault isolation between tenants. For example, application instances for a particular tenant may run in one or more virtual machines (VMs) 170, and these VM(s) 170 may, in turn, be located in a particular container 172 associated with the tenant. In this way, in accordance with some implementations, a particular tenant may be associated with one or more VMs 170 and one or more containers 172.
[0017] In this context, a "virtual machine" or "VM" (also called "virtual guest machine," "virtual machine instance," or "guest virtual machine instance") refers to a virtual environment that acts as a virtual server or virtual computer system that has its own physical resources (e.g., CPU(s), system memory, network interface(s), and storage). In addition, the VM may have its own abstraction of an operating system, such as the operating system 176; and in general, the VM is a virtual abstraction of the hardware and software resources of the computing platform 100-1. The life cycle (e.g., provisioning and termination) of the VM may be managed by a virtual machine monitor (VMM) or hypervisor, such as hypervisor 174.
[0018] A "container" (also called an "instantiated container," a "container instance," or a "software container"), as used herein, generally refers to a virtual runtime environment for one or more applications and / or application modules, and this virtual runtime environment is structured to interface with an operating system kernel. For example, a container for a particular application may contain the executable code for the application and its dependencies, such as system tools, libraries, configuration files, executable files, and binaries for the application. Consistent with example implementations, the container contains an interface for incorporating the operating system kernel, but not the operating system kernel. For example, a particular computing platform may contain multiple containers that share an operating system kernel through corresponding operating system kernel mount interfaces.Docker containers and rkt containers are examples of software containers.
[0019] According to example implementations, host 101 includes a bus infrastructure that includes one or more expansion bus ports 150 (e.g., Peripheral Component Interconnect express (PCIe) bus ports). A particular expansion bus port 150 can accommodate an intelligent network card 140. Furthermore, according to example implementations, intelligent network card 140 provides dual-asset security management and control interfaces to create boundaries between the tenant and cloud operator domains. As described in Fig. As shown, according to example implementations, a particular intelligent network card 140 includes a BMC 129; and according to example implementations, this single BMC 129 manages the operation of the entire computer platform 100-1, that is, the BMC 129 manages the host 101, and the BMC 129 also manages the intelligent network card 140.
[0020] A "BMC," or "baseboard management controller," is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system over a management network. The baseboard management controller can also communicate with applications running at the operating system level through an input / output controller (IOCTL) interface driver, a REST application program interface (API), or another system software proxy that facilitates communication between the baseboard management controller and applications. The baseboard management controller can access hardware devices located within a server chassis, including system memory, at the hardware level. The baseboard management controller may be capable of directly modifying the hardware devices.The baseboard management controller can operate independently of the operating system of the system in which the baseboard management controller is located. The baseboard management controller can be located on the motherboard or mainboard of the server or other device to be monitored. The fact that a baseboard management controller is mounted on the motherboard of the server / hardware to be monitored or is otherwise connected or attached to the server / hardware to be monitored does not prevent the baseboard management controller from being considered "separate" from the server / hardware to be monitored. As used herein, a baseboard management controller has management functions for subsystems of a computing device and is separate from a processing resource executing an operating system of a computing device.The baseboard management controller is separate from a processor, such as a central processing unit, that runs a high-level operating system or hypervisor on a system.
[0021] Remote access to the BMC 129 may be provided through a remote management server 197 connected to the network fabric 159. In this manner, the remote server 197 may transmit requests (e.g., IPMI (Intelligent Platform Management Interface) messages containing IPMI commands) to the BMC 129 to enable the BMC 129 to manage and control functions of the host 101 and the intelligent network card 140; and the remote server 197 may receive messages (e.g., IPMI messages) from the BMC 129 representing status information, state information, configuration information, configuration options, event notifications, etc. from the BMC 129.
[0022] In accordance with example implementations, the BMC 129 with the intelligent network card manages the host 101 using communications that occur through a signaling interface 152 of the connector 150 via one or more out-of-band communication channels 109. In this context, the signaling interface 152 of the connector 150 refers to physical communication ports (e.g., pins, sockets, or ports) of the connector 150. An "out-of-band communication channel" with the intelligent network card 140, in this context, refers to the use of a secure communication channel with the intelligent network card 140 that is not the primary communication channel of the intelligent network card.For example, in some implementations, the intelligent NIC 140 may be a PCIe card that has a primary PCIe bus communication channel; in these implementations, the out-of-band communication channel 109 may be, for example, an inter-integrated bus (I. 2 C), an improved inter-integrated bus (I 3 C), a Serial Peripheral Interface (SPI) bus, an extended SPI bus (eSPI), or a bus associated with another standard. The signaling interface 152 may, in accordance with example implementations, include communication channels associated with communicating control and / or telemetry signals to / from the BMC 129. Depending on the particular implementation, the signaling interface 152 may correspond to all ports of the connector 150 or a lesser subset of all ports of the connector 150.
[0023] According to example implementations, the Smart NIC 140 may be disposed on a circuit card substrate having a card edge connector constructed to be inserted into the connector 150 to mechanically secure the Smart NIC 140 to the connector 150 and to establish electrical connections between the host and the Smart NIC 140. For example, according to some implementations, the connector 150 is a slotted connector; and a circuit substrate of the Smart NIC 140 may include electrically conductive traces disposed on a card edge having a form factor constructed to be received within the connector 150 such that when the card edge is received within the connector, the traces contact terminals (e.g., spring terminals) of the connector 150 and are electrically connected.
[0024] In accordance with example implementations, port 150 may have a card edge layout that conforms to the Datacenter-ready Secure Control Interface (DC-SCI) of the Datacenter-Secure Control Module (DC-SCM) specification published by the Open Compute Project, version 1.0 (March 11, 2021).
[0025] As further described herein, according to some implementations, the BMC 129 may include dedicated hardware that performs exclusively BMC-related management operations and is not shared with other components of the smart NIC 140 for non-management-related BMC operations. For example, in some implementations, the BMC 129 may include a main semiconductor package (or "die") containing one or more semiconductor dies. More specifically, according to some implementations, the BMC 129 may include a main semiconductor package that includes one or more main hardware processing cores (e.g., CPU cores, Advanced Reduced Instruction Set Computer (RISC) Machine (ARM) processing cores, etc.) that execute machine-executable instructions (or "software," such as firmware) for the purpose of managing operations of the host 101 and the smart NIC 140. Fig. (described further herein) is a schematic diagram of such a dedicated hardware-based BMC in accordance with example implementations.
[0026] As from Fig. combined with Fig. As can be seen, according to further example implementations, the BMC 129 may be a virtual BMC, i.e., an abstraction of the actual hardware and software of the intelligent NIC 140. For example, in accordance with some implementations, the intelligent NIC 140 may provide one or more guest VMs 149 that provide the BMC 129. The guest VM(s) 149 may, for example, execute in a virtualized environment, such as a container. In accordance with some implementations, as further described herein, the intelligent network card 140 may include hardware processors (e.g., CPUs, CPU processing cores, ARM processing cores, etc.) that execute machine-executable instructions to provide one or more I / O services to the intelligent network card 140.In accordance with example implementations, one or more of these hardware processors of the intelligent network interface 140 may further execute instructions to provision the VM machine 149 and BMC 129.
[0027] As a more specific example, according to some implementations, hardware processors of the intelligent network card 140 may execute machine-executable instructions to deploy a container that includes a virtual machine 149 connected to a management plane of the BMC 129 and containing one or more application instances corresponding to the management stack of the BMC for the purpose of managing the computing platform 100-1; and the container may include another virtual machine 149 connected to a security plane of the BMC 129 and containing one or more application instances that provide security services to the computing platform 100-1. A security plane 230 and a management plane 210 of a hardware BMC 129 are described further below in connection with Fig. explained.
[0028] In accordance with further example implementations, the BMC 129 may be a hybrid combination of a virtual BMC and a hardware BMC. For example, the hybrid BMC 129 may include dedicated hardware components to provide certain management and / or security-level functions of the hybrid BMC 129; and hardware processors of the intelligent network card 140, which execute machine-executable instructions to provide I / O services to the intelligent network card 140, may further execute machine-executable instructions to provide management and / or security-level functions of the hybrid BMC 129.
[0029] Back to Fig. : At the Fig. In the example implementation illustrated, host 101 may include one or more general-purpose hardware processors 102 (e.g., one or more CPU packages, one or more CPU processing cores, one or more GPU cores, one or more FPGAs, etc.), system memory 104, and bus infrastructure. In accordance with example implementations, general-purpose hardware processor(s) 102 execute machine-executable instructions (i.e., "software") for host 101. For example, hardware processor(s) 102 may execute instructions associated with instances of VMs 170, instances of containers 172, a hypervisor 174, operating system 176, application instances associated with application layer 160, boot service firmware 175, etc.According to example implementations, system memory 104 and other memories discussed herein are non-transitory storage media that may generally be formed from memory devices such as semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase-change memory devices, a combination of devices from one or more of these memory technologies, etc. System memory 104 may represent a collection of volatile and non-volatile memory devices. Boot service firmware 175 represents firmware (e.g., Basic Input / Output Operating System (BIOS) firmware and / or Unified Extensible Firmware Interface (UEFI) firmware) executed by computing platform 100-1 during booting of computing platform 100-1 following a power-on or reset of computing platform 100-1.
[0030] In accordance with example implementations, the bus infrastructure of host 101 may include one or more bridges 106 that may connect to system memory 104 and other components of host 101, such as a Trusted Platform Module (TPM) 177, one or more USB devices 126, etc. The bridge(s) 106 may include one or more PCIe ports connected via one or more corresponding PCIe links or buses 108 to one or more PCIe bus expansion cards 150, such as the depicted port 150 that accommodates an intelligent network card 140. In general, the bridge(s) 106 may include interfaces to various buses of host 101, such as a PCIe bus, an SPI bus, an enhanced SPI bus (eSPI), a low pin count (LPC) bus, an I 2 C-Bus, an I 3 C-Bus and possibly buses connected to other bus standards.
[0031] According to some implementations, the bridges 106 may include a northbridge 106 and a separate southbridge 106. Thus, according to some implementations, the general-purpose hardware processor 102 may include one or more semiconductor packages (or "chips"), and the processor 102 may include the northbridge 106, which includes a memory controller and PCIe root ports. The southbridge 106 may provide I / O ports, such as Serial Advanced Technology Attachment (SATA) ports, Universal Serial Bus (USB) ports, LPC ports, SPI ports, eSPI ports, and so on. According to some implementations, the northbridge 106 may not be part of the hardware processor 102. According to further implementations, the northbridge and southbridge may be combined into a single bridge 106, and according to some implementations, this single bridge 106 may be part of the processor 102.
[0032] Among its other hardware components, according to example implementations, host 101 may include a power regulator 180 that may be controlled by operating system 176 to set a particular system power state for computing platform 100-1. In this manner, according to example implementations, operating system 176 may communicate with power regulator 180 (e.g., cause one or more signals to be asserted to power regulator 180) to change the system power state. In this context, the "system power state" refers to the power state of all components of computing platform 100-1, excluding those components of computing platform 100-1 involved in managing the platform, such as BMC 129. For a given system power state, some components of computing platform 100-1 may be powered on at different levels than other components (e.g.,Some components of the computing platform 100-1 may be turned off for a given power consumption state for the purpose of saving power, while other components may be turned on to a relatively higher power consumption state. For example, the operating system 176 may communicate with the power controller 180 to place the computing platform 100-1 into a power-on reset, transition the computing platform 100-1 from a higher power consumption state to a lower power consumption state, transition the computing platform 100-1 from a lower power consumption state to a higher power consumption state, shut down the computing platform 100-1, etc.
[0033] According to example implementations, the power controller 180 may be controlled by an entity other than the operating system 176. For example, in some implementations, the boot service firmware 175 may communicate with the power controller 180 to control the power state of the system. Furthermore, as further described herein, in accordance with some implementations, the BMC 129 may communicate with the appropriate entity (e.g., the power controller 180, the boot service firmware 175, or the operating system 176) to change the system power state.
[0034] As also in Fig. As illustrated, in accordance with some implementations, the computing platform 100-1 may include one or more sensors 105. In accordance with example implementations, the sensors 105 provide signals or indications representative of various sensed conditions related to the environment and / or the state of the computing platform 100-1. In this way, in accordance with example implementations, the BMC 129 may monitor signals provided by the sensors 105 for purposes such as monitoring the state of the computing platform 100-1, monitoring temperatures of the computing platform 100-1 for the purpose of performing thermal management, monitoring for tamper detection, etc. The sensors 105 may be, for example, temperature sensors, tamper indication sensors, overvoltage sensors, undervoltage sensors, fan speed sensors, etc.The signals supplied by the sensors 105 are forwarded to the BMC 129 via the signaling interface 152.
[0035] As in Fig. As shown, in accordance with example implementations, the smart NIC 140 may include one or more hardware components mounted on one or more circuit substrates 141. Furthermore, a particular circuit substrate 141 may have a form factor and corresponding features (electrical traces, etc.) that enable the smart NIC 140 to be installed into the connector 150. According to some implementations, the circuit substrate 141 may include a card edge having traces arranged in a pinout corresponding to the DC-SCI, and according to further implementations, the circuit substrate 141 may include a card edge having traces arranged in a different pinout than or in addition to the DC-SCI. According to example implementations, the smart NIC 140 includes hardware components, such as one or more hardware processors 142 (e.g.,CPU processing cores, such as ARM processing cores, embedded processing cores, ARM processing cores, etc.), a memory 144, one or more sensors 154, a network interface (not shown), and a power controller 156.
[0036] The processor(s) 142 executes machine-executable instructions 146 stored in memory 144. In accordance with some implementations, the processor(s) 142 execute the instructions 146 to perform one or more cloud operator domain-based I / O services for the host 101. In this way, in accordance with example implementations, the processor(s) 142 may execute the instructions 146 to execute one or more application instances of an application layer 148, as well as instances associated with virtual machines, containers, etc.
[0037] The sensors 154 detect conditions (e.g., environmental, fault, and / or tamper events) of the intelligent NIC 140, and the indications or signals provided by the sensors 154 may be monitored by the BMC 129.
[0038] As mentioned herein, in accordance with some implementations, the BMC 129 may be formed from discrete hardware components separate from other components of the intelligent NIC 140, such as a standalone semiconductor package and possibly associated memory, application-specific integrated circuits (ASICs), etc. Moreover, according to further example implementations, the BMC 129 may be a virtual BMC formed by one or more processors 142 of the intelligent NIC 140 executing machine-executable instructions; or according to still further implementations, the BMC 129 may be a hybrid BMC including virtual and actual hardware components.
[0039] In Fig. A hardware BMC 129 is shown, which is formed from actual hardware components according to example implementations. According to Fig. in connection with the Fig. The BMC 129 includes a management plane 210 and a security plane 230 isolated from the management plane 210. In accordance with example implementations, the security plane 230 includes a secure enclave 240, which refers to the portion of the BMC 129 that provides security services for the computing platform 100-1. In this context, the term "secure enclave" refers to a subsystem where access into and out of the subsystem is tightly controlled. The management plane 210 is the portion of the BMC 129 that executes a management firmware stack 257 (hereinafter referred to as "management stack 257") to provide management services for the computing platform 100-1, including management of the host 101 and management of the intelligent network card 140, according to example implementations. For example, the management stack 257 may be an Open BMC firmware stack, version 2.9.0, released on December 12, 2012.January 2021. The management stack 257 may be a management stack other than an Open BMC stack and a management stack other than an open source stack, as is the case in further implementations.
[0040] As in Fig. As shown, according to example implementations, the BMC 129 may be coupled to one or more external memories (e.g., outside of a semiconductor package containing the BMC 129), such as volatile memory 264 and non-volatile memory 268. For example, the non-volatile memory 268 may store firmware 270 (e.g., a firmware image) and may be connected to the BMC 129 via a bus (e.g., an SPI bus). As further described herein, in accordance with some implementations, the BMC 129 may validate the firmware 270 upon booting the computing platform 100-1.
[0041] According to example implementations, the secure enclave 240 includes, among its other features, a security processor 242 (e.g., an embedded CPU processing core); volatile memory 251 (e.g., memory for storing firmware loaded into the volatile memory and executed by the security processor); a secure bridge for controlling access to the secure enclave and for controlling outgoing communication from the secure enclave; peripherals (e.g., cryptographic accelerators, a random number generator, tamper detection circuitry, etc.), and a hardware root of trust engine 243 (referred to herein as a silicon RoT engine or “SRoT engine 243”).In accordance with example implementations, the SRoT engine 243 validates the firmware to be executed by the security processor 242 before the SRoT engine 243 loads the firmware into the secure enclave's volatile memory 251 and allows the security processor 242 to execute the firmware.
[0042] As used herein, a "Root of Trust device," such as the SRoT engine 243, may be a device that behaves in an expected manner. In other words, the SRoT device 243 may be inherently trusted software, hardware, or a combination thereof. The SRoT device 243 may include compute units. The compute engine may be software operating with hardware within the SRoT device 243, hardware of the SRoT device 243, or a combination thereof. An SRoT device 243 may include a Root of Trust for Verification (RTV). The RTV performs an integrity measurement or digital signature on the program code (e.g., code loaded into the secure enclave) and validates the code against a predetermined expectation or policy. The SRoT device 243 may include a Root of Trust for Storage (RTS).The RTS may be a computing engine capable of creating an accurate summary of the tamper-evident values. For example, the SRoT device 243 may include a register storing a reference hash or a measurement hash. Furthermore, the SRoT device 243 may include a plurality of such registers. In another example, the SRoT device 243 may include a Root of Trust for Reporting (RTR). The RTR may be a computing engine capable of sending requested information to a requesting device. The information may include the contents of a register of the SRoT device 243 (or the contents of the RTS) and information specified by the requester. The SRoT device 243 may also include other computing units not described here, such as a computing unit for measuring certain values or a computing unit for authentication.
[0043] As in Fig. As shown, in accordance with some implementations, the BMC 129 includes one or more in-band communication interfaces 205 (e.g., a PCIe bus interface) and one or more out-of-band communication interfaces 206 (e.g., a DC-SCI). Furthermore, the BMC 129 includes one or more embedded hardware processing cores 254 (e.g., an embedded CPU processing core, such as an ARM processing core) that execute machine-executable instructions 256 stored in a non-volatile memory 255 of the BMC 129 to provide the BMC management stack 257. As shown in Fig. As shown, in accordance with some implementations, the signaling interface 152 may include signals communicated with out-of-band communication interface(s) 206. In accordance with other implementations, the signaling interface 152 may also include signals associated with the in-band communication interface(s) 204.
[0044] Fig. shows an exemplary process 300 of the management plane of the BMC 129 in accordance with some implementations. Referring to Fig. combined with Fig. In accordance with some implementations, process 300 includes communication (block 304) of BMC 129 with remote server 197, communication of BMC 129 with components of host 101 via signaling interface 151, and communication of BMC 129 with components of intelligent network card 140. According to block 308, in response to these communications, BMC 129 manages platform 100-1, including BMC 129 managing host 101 via signaling interface 151 and BMC 129 managing intelligent network card 140.
[0045] As an example of BMC management of host 101, in accordance with some implementations, BMC 129 may manage booting of host 101, as shown in example process 400 of Fig. With reference to Fig. in connection with the Fig. According to some implementations, after power-up or reset, the BMC 129 keeps its general-purpose processing core(s) 254 in reset until certain actions are performed, as indicated by the dashed box 401 of Fig. In this way, after initial root-of-trust security checks as well as other checks (e.g., hardware bug checks) of the computing platform 100-1 have been passed (e.g., no security or hardware bug checks have failed), the BMC 129 releases the general-purpose processing core(s) 254 from reset.
[0046] According to example implementations, the secure enclave 240 stores an immutable fingerprint used by the SRoT engine 243 to validate machine-executable instructions. More specifically, according to example implementations, in response to the BMC 129 being powered on or reset, the SRoT engine 243 validates an initial portion of the firmware 270 according to block 404 and loads the validated portion of the firmware 270 into a non-volatile memory 251 of the BMC 129 so that this portion of the firmware is now trusted. According to block 408, the security processor 242 may then boot and execute the loaded firmware instructions.By executing the firmware instructions, the security processor 242 may then validate another portion of the firmware 270 corresponding to a portion of the management firmware stack 257, as per block 408; and after validating this portion of the management firmware stack 257, the security processor 242 may then load the validated portion into the memory 255 of the BMC 129. This portion of the management firmware stack 257 may then be executed by the general-purpose processing core(s) 254, causing the processing core(s) 254 to load additional portions of the firmware 270 and place the loaded portions into the memory 264. Accessing the memory 264 may include additional training and initialization steps (e.g., training and initialization steps specified in the DDR4 specification). These instructions can be executed by the validated part of the management firmware stack 257 in memory 255.In accordance with example implementations, the secure enclave 240 may lock the memory 255 to prevent changes or tampering with the validated part(s) stored in the memory 255.
[0047] According to decision block 412, the BMC 129 determines whether the security and hardware error checks performed by the BMC 129 have passed. If not, the BMC 129 may abort or terminate the boot of the computing platform 100-1, in accordance with example implementations. Otherwise, the BMC 129 releases the general-purpose processing core(s) 254 from reset (block 416) so that the processing core(s) 254 can execute the management stack 257 to manage the computing platform 100-1, including managing the intelligent network card 140 and the host 101.
[0048] Fig. shows a process 500 of the BMC 129 for the purpose of controlling a power system state of the computer platform 100-1. With reference to Fig. in connection with the Fig. In accordance with example implementations, the BMC 129 receives a communication (e.g., a message containing a command) from the remote server 197 requesting a change in the system power state for the computing platform 100-1 (block 504). The request may be, for example, a request to turn off the computing platform 100-1, a request to reset the computing platform 100-1, a request to put the computing platform 100-1 into a hibernation state, etc. According to process 500, the BMC 129 determines (decision block 508) whether the change in the system power state involves communication with the operating system 176. For example, the computing platform 100-1 may be fully powered up; and as such, control of power management may be performed with the operating system 176. Conversely, the BMC 129 can communicate with the boot service firmware 175 in a pre-operating system environment, e.g.B. with the BIOS or UEFI firmware. As described in . Fig. As shown, if the BMC 129 determines, as per decision block 508, that the operating system 176 is involved, it communicates with the operating system 176 via the signaling interface 152, as per block 512, to change the system's power state according to the request. Otherwise, the BMC 129 communicates, as per block 516, with either the power controller 180 or the BIOS or UEFI via the signaling interface 152 to change the system's power state.
[0049] Fig. shows another management process 600 of the BMC 129 according to example implementations. This example process 600 relates to the control of a boot path for the host 101 by the BMC 129. In this way, the "boot path" refers to the path used to load the operating system boot loader, capture the operating system image, capture operating system-related files, etc. As can be seen from Fig. combined with Fig. As shown in block 604, the BMC 129 selects the boot path based on a particular boot path configuration. In this context, the remote server 197 may, for example, communicate with the BMC 129 to select a virtual media device as the boot device, select a Preboot Execution Environment (PXE) network boot, etc. According to block 608, the BMC 129 communicates with the boot service firmware 75 via the signaling interface 152 to cause the loading and booting of the operating system 176.
[0050] Fig. shows another example of a management process 700 of the BMC 129. Here, the process 700 shows a thermal management process. With reference to Fig. in connection with the Fig. According to process 700 (block 704), the BMC 129 monitors signals from cooling fan sensors 105 and temperature sensors 105 of the host 101 (via the signaling interface 152) and signals from temperature sensors 154 of the smart NIC 140 to evaluate a thermal condition for the host 101 and / or the smart NIC 140. This evaluation may include, for example, the BMC 129 determining that one or more temperatures of the host 101 or the smart NIC 140 are outside of acceptable operating ranges. The BMC 129 may then determine that corrective action must be taken, according to decision block 708. The corrective actions may include, for example, turning on one or more fans, increasing the speed of one or more fans, turning off or shutting down certain components of the host 101 or the intelligent network card 140, changing the power state of the system, etc.If a thermal management corrective action is to be taken, the BMC 129 takes the appropriate corrective action according to block 712.
[0051] The BMC 129, in accordance with example implementations, can perform management functions for the Smart NIC 140, similar to the management functions described above for the host 101. For example, the BMC 129 can be remotely controlled via remote messages to change the power state of the Smart NIC 140 (e.g., turn off the Smart NIC 140, reset the Smart NIC 140, turn on the Smart NIC 140, etc.); select a boot path to boot and load the Smart NIC 140's operating system 143; select and configure virtual media for use by the Smart NIC 140; update the Smart NIC 140's firmware, etc.Additionally, the BMC 129 may monitor one or more of the sensors 154 of the intelligent NIC; report environmental conditions and events resulting from the monitoring to the remote server 197; perform corrective actions based on the sensor monitoring by controlling components of the intelligent NIC 140; and so on. The BMC 129 may, in accordance with example implementations, validate firmware executed by the processor(s) 142 of the intelligent NIC 140; detect hardware failures on the intelligent NIC 140; perform recovery actions in response to an operating system failure on the intelligent NIC 140; and so on.
[0052] Because a single BMC 129 manages both the intelligent network card 140 and the host 101, the single BMC 129 can coordinate and collaborate the management actions for the host 101 with the management actions for the intelligent network card 140. As described herein, in accordance with example implementations, the single BMC 129 manages the entire computing platform 100-1, including the management of the host 101 and the management of the intelligent network card 140. As can be seen from the foregoing description, some of the management actions performed by the BMC 129 are directed exclusively to actions performed on the host 101, some of the management actions are directed exclusively to actions performed on the intelligent NIC 140, and some of the management actions may affect both the host 101 and the intelligent NIC 140.
[0053] As in Fig. As shown, according to example implementations, a process 800 includes a host application layer of a computing platform using a smart network interface card (NIC) of the computing platform (block 804) to provide an input / output (I / O) service to the application layer. The I / O service includes a service associated with a cloud operator domain; the smart NIC is installed in a port; and the application layers are associated with a cloud tenant domain. The process 800 includes a baseboard management controller of the smart NIC managing the computing platform (block 808).Managing the computing platform includes managing the host through the baseboard management controller; managing components of the Smart NIC other than the baseboard management controller through the baseboard management controller; and managing the host includes communicating the baseboard management controller with the host through the connector to control a system power state of the computing platform.
[0054] As in Fig. As shown, according to example implementations, a system 900 includes a host 904, a port 916, and an intelligent network interface card (NIC) 920 that is installed in the port 916. The host 904 includes a central processing unit (CPU) 908 and memory 912. The intelligent NIC 920 includes memory 924, at least one hardware processor 932, and a baseboard management controller 936. The hardware processor(s) 932 execute(s) instructions 928 stored in memory 924 to provide a non-network communication I / O (input / output) service to the host 904. The I / O service is connected to a cloud operator domain.The baseboard management controller 936 manages components of the intelligent network card 920 other than the baseboard management controller 936 and manages the host 904, including communication with the host 904 via the port 916 to control a system power state.
[0055] Referring to Fig.According to example implementations, a non-transitory storage medium 1000 stores machine-readable instructions 1010 that, when executed by the machine, cause the machine to provide an input / output (I / O) service to a host of a computing platform via an intelligent network interface card (NIC). The I / O service includes a service associated with a cloud operator domain; the intelligent NIC is to be housed in a port of a motherboard of the host; and the host is to include an application layer associated with a cloud tenant domain. The instructions 1010, when executed by the machine, further cause the machine to provide a virtual baseboard management controller on the intelligent network card to manage components of the intelligent network card other than the baseboard management controller; and to manage the host.Managing the host involves communicating with the host through the port to control a system performance state.
[0056] According to example implementations, platform management involves executing commands through the intelligent network card to provide a virtual controller for baseboard management. A particular advantage is that no dedicated hardware is used for the baseboard management controller.
[0057] According to example implementations, the smart NIC that uses the smart NIC to provide the I / O service includes at least one smart NIC central processing unit (CPU) that executes instructions to provide the I / O service; and the baseboard management controller that manages the computing platform further includes an embedded smart NIC hardware subsystem that is distinct from the CPU(s) that manage the computing platform. A particular advantage is that a single baseboard management controller can manage both the smart NIC and the host.
[0058] In accordance with example implementations, the intelligent network card is installed in a connector of the computing platform; and the baseboard management controller that manages the computing platform further includes the baseboard management controller communicating telemetry signals with components of the host through the connector. Managing the computing platform further includes the baseboard management controller communicating with at least one general-purpose central processing unit (CPU) of the host through the connector; and the CPU(s) is / are connected to the application layer. A particular advantage is that a single baseboard management controller can be used to manage both the intelligent network card and the host.
[0059] According to example implementations, the host may contain an application layer connected to a cloud tenant domain; the cloud tenant domain may contain an untrusted domain; the cloud operator domain may contain a trusted domain; and the baseboard management controller may be connected to the cloud operator domain. A particular advantage is that a single baseboard management controller can be used to manage both the host and the intelligent network card in a cloud-centric application.
Claims
[1] Procedure comprising: an application layer (160) of a host (101) of a computer platform (100-1) using an intelligent network interface card (NIC (140; 920)) of the computer platform (100-1) to provide an input / output (I / O) service to the application layer (160), wherein the I / O service comprises a service associated with a cloud operator domain, the intelligent NIC (140; 920) is installed in a connector (150), and the application layer (160) is associated with a cloud tenant domain; and a baseboard management controller (936) of the intelligent NIC (140; 920) that manages the computer platform (100-1), wherein the management of the computer platform (100-1) comprises: the baseboard management controller (936) managing the host (101), wherein the baseboard management controller (936) manages components of the intelligent NIC (140; 920) other than the baseboard management controller (936), wherein managing components of the intelligent NIC (140; 920) other than the baseboard management controller (936) comprises the baseboard management controller (936) changing a power state of the intelligent NIC (140; 920) in response to a remote message; and managing the host (101) comprises the baseboard management controller (936) communicating with the host (101) via the port to control a system performance state of the computer platform (100-1). [2] The method of claim 1, wherein the baseboard management controller (936) managing the computer platform (100-1) comprises the intelligent NIC (140; 920) executing instructions to provide a virtual baseboard management controller (936). [3] The method of claim 1, wherein: the use of the intelligent network card (Smart NIC (140; 920)) to provide the I / O service comprises at least one central processing unit (CPU (908)) of the intelligent NIC (140; 920) that executes instructions to provide the I / O service; and the baseboard management controller (936) that manages the computing platform (100-1) further comprises an embedded hardware subsystem of the intelligent NIC (140; 920) that is different from the at least one CPU (908) that manages the computing platform (100-1). [4] The method of claim 1, wherein: the intelligent NIC (140; 920) is installed in a connector (150) of the computer platform (100-1); the baseboard management controller (936) managing the computer platform (100-1) further comprises the baseboard management controller (936) communicating telemetry signals with components of the host (101) via the connector (150); the baseboard management controller that manages the computer platform (100-1) further comprises the baseboard management controller (936) that communicates with at least one general-purpose central processing unit (CPU (908)) of the host (101) via the connector (150); and the at least one general-purpose CPU (908) is assigned to the application layer (160). [5] System (900), comprising: a host (101) comprising a central processing unit (CPU (908)) and a memory (104); a connector (150) and an intelligent network interface card (NIC (140; 920)) to be installed in the connector (150), the intelligent NIC (140; 920) comprising: a memory (144) for storing instructions; at least one hardware processor (142; 932) for executing the instructions to provide an input / output (I / O) service to the host (101) that is not a network communication, the I / O service being associated with a cloud operator domain; and a base board management controller (936) to: to manage components of the intelligent NIC (140; 920) other than the baseboard management controller, wherein managing components of the intelligent NIC (140; 920) other than the baseboard management controller comprises the baseboard management controller changing a power state of the intelligent NIC (140; 920) in response to a remote message; and to manage the host (101), wherein managing the host (101) comprises communicating with the host (101) via the connector (150) to control a system power state. [6] The system (900) of claim 5, wherein the baseboard management controller (936) comprises a virtual baseboard management controller and the at least one hardware processor (142; 932) further executes the instructions to provide the virtual baseboard management controller. [7] The system (900) of claim 5, wherein the baseboard management controller (936) comprises an embedded hardware subsystem separate from the at least one hardware processor (142), and the embedded hardware subsystem comprises an embedded hardware processor (254) to execute instructions to manage the system. [8] System (900) according to claim 5, wherein: the host (101) further comprises an application layer (160) connected to a cloud tenant domain; the cloud tenant domain includes an untrusted domain; the cloud operator’s domain includes a trusted domain; and the base board management controller (936) is connected to the cloud operator domain. [9] The system (900) of claim 8, wherein the CPU (908) comprises at least one hardware processor to further execute the instructions to perform the I / O service in response to a request from the application layer (160). [10] The system (900) of claim 5, further comprising: a circuit substrate (141) separate from the intelligent NIC (140; 920), wherein the CPU (908) and the connector (150) are mounted on the circuit substrate (141). [11] The system (900) of claim 5, wherein the connector (150) comprises a data center-suitable secure control interface (DC-SCI). [12] The system (900) of claim 5, wherein the at least one hardware processor (142) further executes the instructions to communicate telemetry signals for the baseboard management controller (936) with components of the host (101) via the connector (150) and to communicate signals connected to a host interface of the baseboard management controller (936) via the connector (150). [13] The system (900) of claim 5, wherein the base board management controller (936) comprises a hardware root of trust (RoT (243)). [14] The system (900) of claim 5, wherein the at least one hardware processor (142; 932) executes the instructions to provide a virtualization service to the host (101). [15] The system (900) of claim 5, wherein the at least one hardware processor (142) executes the instructions to provide a virtualized network for the host (101). [16] The system (900) of claim 5, wherein the at least one hardware processor (142) executes the instructions to provide network function virtualization for the host (101). [17] The system (900) of claim 5, wherein the at least one hardware processor (142; 932) executes the instructions to provide at least one of a storage service for the host (101), a network security service for the host (101), and a network control plane service for the host (101). [18] Non-transitory machine-readable storage medium Storage medium for storing machine-readable instructions which, when executed by a machine, cause the machine to: Providing, via an intelligent network interface card (NIC (140; 920)), an input / output (I / O) service for a host (101) of a computer platform (100-1), wherein the I / O service comprises a service connected to a cloud operator domain, wherein the intelligent NIC (140; 920) is to be received in a connector (150) of a motherboard of the host (101), and the host (101) comprises an application layer (160) connected to a cloud tenant domain; and providing a virtual baseboard management controller (936) on the intelligent NIC (140; 920) to manage components of the intelligent NIC (140; 920) other than the virtual baseboard management controller (936) and to manage the host (101), including communicating with the host (101) via the connector (150) to control a system power state, wherein managing components of the intelligent NIC (140; 920) other than the virtual baseboard management controller includes the baseboard management controller changing a power state of the intelligent NIC (140; 920) in response to a remote message. [19] The storage medium of claim 18, wherein the instructions, when executed by a machine, further cause the machine to provide at least one of a network security service for the application layer (160), a network storage service for the application layer (160), a virtualized function for the application layer (160), and a virtual network for the application layer (160). [20] The storage medium of claim 18, wherein the instructions, when executed by the machine, further cause the machine to: exchange telemetry signals with components of a main board using the connector (150); and using the connector (150) bus interface requirements and -Responses to communicate with a host central processing unit (CPU (908)) of the main board. [21] The method of claim 1, wherein managing, by the baseboard management controller (936), components of the intelligent NIC (140; 920) other than the baseboard management controller (936), further comprises the baseboard management controller (936) selecting a boot path for loading an operating system of the intelligent NIC (140; 920). [22] The method of claim 1, wherein managing, by the baseboard management controller (936), components of the intelligent NIC (140; 920) other than the baseboard management controller (936), further comprises the baseboard management controller (936) updating the firmware of the intelligent NIC (140; 920). [23] The method of claim 1, wherein managing, by the baseboard management controller (936), components of the intelligent NIC (140; 920) other than the baseboard management controller (036), further comprises the baseboard management controller (936) performing a management action directed exclusively to the intelligent NIC (140; 920) and not to the host (101).
Citation Information
Patent Citations
Dynamic scalable baseboard management controller stacks on single hardware structure
US20140280837A1
Technologies for network packet processing between cloud and telecommunications networks
US20190045037A1
BMC coupled to an m.2 slot
US20190303335A1
Cited By
Server and network card association registration method and device, electronic equipment and storage medium
CN115834531A
Server and network interface card (NIC) association registration methods, devices, electronic devices, and storage media
CN115834531B
