Patent Description:
A network interface card (NIC) is a hardware device used to connect a computer to a network to communicate. A NIC may also be referred to as a network interface controller, a local area network (LAN) card, a physical network interface, a network adapter, a network card, and an Ethernet card.

A NIC transmits data stored in a memory or cache to outside of the NIC. That is, a NIC may include a cache that serves as a buffer for storing information generated during the transmission/reception of data (e.g., during signal conversion). <CIT> refers to remote sharing of directly connected storage. A host system may include a computational processing unit implemented using hardware and a hardware virtualizing and remote sharing, HVRS, server that virtualizes and shares the computational processing unit with other host systems, where the host system is directly connected to an internal fabric of a storage system. A storage system interface, SSI, of the host system may be directly connected to the internal fabric of the storage system and is also directly connected to a same peripheral device interconnect as the CPU, the computational processing unit and/or other hardware resources of the host system. The SSI may communicate with storage resources of the storage system using remote direct memory access, RDMA, and zero-copy technologies. Such a host system may provide the storage capacity and data protection services of a storage system at relatively fast speeds e.g., comparable to non-volatile RAM on a host system configured for use as persistent memory.

In one general aspect, a computational network interface card (NIC) sharing a storage space with a memory expander thereof includes: a NIC memory including instructions; a NIC processor including a cache and electrically connected to the NIC memory; and a NIC configured to transmit data stored in the NIC memory or the cache to a network, wherein, the instructions are configured to cause the NIC processor to perform operations including: receiving a request to read or write metadata; and checking whether the requested metadata is stored in a local metadata cache of the computational NIC by sequentially checking whether the metadata is stored in the cache of the NIC processor, a cache of the NIC, the NIC memory, or the memory expander.

The metadata are metadata used in a distributed file system and a client device including the computation NIC participates in the distributed file system.

The NIC may be a compute express link (CXL)-NIC that supports CXL. cache as defined in a CXL protocol.

The memory expander is a CXL memory expander that supports CXL. mem as defined in a CXL protocol.

The computation NIC may be a type <NUM>, type <NUM>, or type <NUM> device as defined in a CXL protocol.

The NIC and the NIC processor may be connected in series, and a client device including the computational NIC may access the metadata via the NIC processor.

The NIC and the NIC processor may be connected in parallel, and a client device including the computational NIC may access the metadata without passing through the NIC processor.

The operations further include: when the requested metadata is determined to be stored in the local metadata cache, verifying validity of the cached metadata; or when the requested metadata is determined to not be stored in the local metadata cache, requesting a metadata server for a metadata management permission of the requested metadata.

The verifying of the validity may include: verifying a validity period of the stored metadata; and verifying whether the computational NIC holds a permission corresponding to the metadata work permission.

In a general aspect, an electronic device includes: a memory including instructions; a processor electrically connected to the memory and configured to execute the instructions; and a computational network interface card (NIC) configured to manage distributed filesystem (DFS) metadata work permissions for DFS metadata in a local distributed file system (DFS) metadata cache of the computational NIC, wherein the DFS metadata is metadata for a DFS, wherein the instructions are configured to cause the processor and/or the computational NIC to perform operations including: requesting, to the computational NIC, by the processor, metadata work permission for a piece of DFS metadata required by a first process executing on the processor; based on determining that the computational NIC does not have metadata management permission for the piece of DFS metadata, requesting, by the computational NIC, to a metadata server of the DFS, metadata management permission for the piece of DFS metadata; and obtaining, by the computational NIC, from the metadata server, metadata management permission for the piece of DFS metadata, and based thereon, assigning metadata work permission to the first process.

The metadata work permission may be a metadata read permission or a metadata write permission, and the metadata management permission from the metadata server grants permission to assign DFS metadata read permission or write permission to the process executed by the processor.

The metadata server may be configured to manage the metadata work permission for all metadata of at least a portion of the DFS, and the computational NIC may be configured to be entrusted, by the metadata server, with metadata management permission for at least some of the DFS metadata in the local DFS metadata cache.

The computational NIC may be configured to: based on obtained metadata management permission, assign the metadata read permission to both the first process and a second process executing on the processor.

When another electronic device different from the electronic device obtains the metadata write permission for the piece of DFS metadata, the metadata work permission for the piece of DFS metadata may be surrendered by the electronic device.

The computational NIC may include: a NIC memory including instructions; a NIC processor including a cache and electrically connected to the NIC memory; and a NIC configured to transmit data stored in the NIC memory or the cache to a network connected to the NIC.

In another general aspect, a memory expander supports CXL. mem as defined in a compute express link (CXL) protocol, the memory expander includes: a memory device in which pieces of DFS metadata of a DFS are stored; and a controller configured to control the memory device, wherein the controller is configured to: receive a work request for an operation on one of the pieces of metadata from an electronic device including a computational network interface card (NIC) connected with the memory expander; and in response to the work request, perform at least one operation on one of the pieces of DFS metadata stored in the memory device.

The controller may be further configured to: communicate directly with the computational NIC or the electronic device through a CXL interface.

The computational NIC may be a type <NUM> or type <NUM> device as defined in the CXL protocol, and includes a NIC memory supporting CXL. mem as defined in the CXL protocol.

The computational NIC is further configured to: assign, to a process executed by the electronic device, a metadata work permission to work on a piece of DFS metadata, wherein the memory expander may be configured to: receive the work request from the electronic device executing the process.

The controller may be further configured to: receive, from the electronic device, a metadata read request for reading the one of the pieces of DFS metadata; and in response to the metadata read request, transmit the one of the pieces of DFS metadata to the electronic device.

The controller may be further configured to: receive, from the electronic device, a metadata write request for writing the one of the pieces of DFS metadata and associated result data; and in response to the metadata write request, change the one of the pieces of DFS metadata to the result data and store the result data.

The pieces of DFS metadata are metadata may be used for accessing filesystem objects in a distributed file system.

Throughout the drawings and the detailed description, unless otherwise described or provided, the same or like drawing reference numerals will be understood to refer to the same or like elements, features, and structures.

As non-limiting examples, terms "comprise" or "comprises," "include" or "includes," and "have" or "has" specify the presence of stated features, numbers, operations, members, elements, and/or combinations thereof, but do not preclude the presence or addition of one or more other features, numbers, operations, members, elements, and/or combinations thereof.

Throughout the specification, when a component or element is described as being "connected to," "coupled to," or "joined to" another component or element, it may be directly "connected to," "coupled to," or "joined to" the other component or element, or there may reasonably be one or more other components or elements intervening therebetween. When a component or element is described as being "directly connected to," "directly coupled to," or "directly joined to" another component or element, there can be no other elements intervening therebetween. Likewise, expressions, for example, "between" and "immediately between" and "adjacent to" and "immediately adjacent to" may also be construed as described in the foregoing.

Unless otherwise defined, all terms, including technical and scientific terms, used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains and based on an understanding of the disclosure of the present application. Terms, such as those defined in commonly used dictionaries, are to be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the disclosure of the present application and are not to be interpreted in an idealized or overly formal sense unless expressly so defined herein. The use of the term "may" herein with respect to an example or embodiment, e.g., as to what an example or embodiment may include or implement, means that at least one example or embodiment exists where such a feature is included or implemented, while all examples are not limited thereto.

<FIG> illustrate example structure and operation of a distributed file system, according to one or more embodiments.

A high-performance computing system may include multiple computer system nodes connected in parallel to perform billions of operations per second. For such a high-performance computing system, a distributed file system <NUM> in which multiple computer system nodes are connected through a parallel input/output (I/O) path may be used. Clients and servers of the high-performance computing system may be equipped with NICs for network communication, and NICs may be connected to each other through a high-performance network for a data center, for example, and Infiniband or high bandwidth Ethernet network. The distributed file system <NUM> may provide high-speed access to extremely large and/or numerous file data to support high-performance computing as used, for example, in weather modeling and seismic prospecting. However, the distributed file system <NUM> is not limited to use with high-performance applications. In some implementations, the distributed file system <NUM> may be a variation of a Lustre distributed file system.

Referring to <FIG>, the distributed file system <NUM> may include metadata servers <NUM> for managing metadata of the distributed file system <NUM> and object storage servers <NUM> for storing file data of the distributed file system <NUM> (e.g., filesystem objects such as file objects, directory objects, or the like). The metadata describes file data/objects such as namespace data, locations of file system objects, permission data, etc. The distributed file system <NUM> may be scalable and performance may be improved by the separation of an I/O path of the file data and an I/O path of the metadata (in other words, by allowing data and metadata to be separately accessed). In the distributed file system <NUM>, client devices (e.g., clients <NUM> to N), the metadata servers <NUM>, and/or the object storage servers <NUM> may transmit and/or receive data (e.g., the file data and the metadata) while communicating with each other through a network. The metadata referred to herein is distributed file system (DFS) metadata.

The metadata servers <NUM> may include metadata targets in which the metadata is stored. The object storage servers <NUM> may include object storage targets in which file data is stored. Management servers <NUM> may manage the metadata servers <NUM> and the object storage servers <NUM>. The management servers <NUM> may include a management target (MGT) in which data associated with management of the metadata servers <NUM> and the object storage servers <NUM> is stored.

Referring to <FIG>, a client device accessing the distributed file system <NUM> may (<NUM>) request metadata (e.g., metadata describing file data to be used, e.g. a file open request specifying a namespace filepath) from a metadata server <NUM> to use file data. A client device may then (<NUM>) obtain, from the metadata server <NUM>, a piece of metadata such as position information (e.g., block information) indicating a position where the file data is stored in the distributed file system <NUM> (or other information about the file data). The client device may, according to the obtained metadata, access the object storage server <NUM> where a block is positioned and (<NUM>) read/write data (e.g., the file data) from/to the block.

While the performance of distributed file systems such as the example distributed file system <NUM> can be improved through the increased performance of object storage servers <NUM>, most operations on file data in previous distributed file systems generally involve corresponding accesses to the metadata server <NUM> (e.g., access to a metadata server by a client device). Even if the performance of object storage servers <NUM> is increased, there may be bottlenecks caused by the need to access the metadata servers <NUM> (generally, for each file request). The performance of the metadata servers <NUM> may be increased to, for example, meet service level agreements (SLAs) when client devices create overload (e.g., burst demand) to the distributed file system <NUM>. The performance improvement of the metadata server <NUM> may be partly addressed through server expansion (adding servers), but server expansion requires additional cost for server installation and maintenance/repair, and often, such additional resources for demand spikes go under-utilized at other times.

<FIG> illustrates an example electronic device (e.g., a client device) according to one or more example embodiments. The example electronic device may be a client participating in (or accessing) the distributed file system <NUM>.

An electronic device <NUM> (e.g., a client device) may use local metadata caching to reduce latency of its distributed file system (DFS) requests (such latency that would be incurred by accessing the metadata servers <NUM>) by instead accessing locally cached metadata for DFS requests, which may also reduce load on the metadata servers <NUM>.

The electronic device <NUM> may provide locally cached DFS metadata through the use of a computational network interface card (NIC) <NUM> and possibly other components, such as, for example a compute express link (CXL) memory expander <NUM>. The computational NIC <NUM> may also be referred to as a computational network interface controller or a smart NIC. The electronic device <NUM> may increase its local metadata caching capacity by using memory of the CXL memory expander <NUM> and/or the computational NIC <NUM> for its local metadata cache.

The electronic device <NUM> may be connected to the metadata server <NUM> through a network (e.g., an InfiniBand network). In the electronic device <NUM>, the computational NIC <NUM> may manage local permissions for its locally cached metadata, for example, permission for local processes to work on (modify, access, etc.) the locally cached metadata. The computational NIC <NUM> may manage the permissions for the cached metadata in a local storage area, and the metadata server <NUM> may manage the permissions for metadata in a global area/scope. Accordingly, data coherency (or integrity) of the metadata may be maintained efficiently.

As noted, the electronic device <NUM> may function as a client device in a distributed file system. The electronic device <NUM> may be a personal computer (PC), a portable device, an application server, or a storage server, to name some examples. A portable device may be implemented as, for example, a laptop computer, a mobile phone, a smartphone, a tablet PC, a mobile Internet device (MID), a personal digital assistant (PDA), an enterprise digital assistant (EDA), a digital still camera, a digital video camera, a portable multimedia player (PMP), a personal (or portable) navigation device (PND), a handheld game console, an e-book, or a smart device. A smart device may be implemented as, for example, a smartwatch, a smart band, or a smart ring.

Still referring to <FIG>, the electronic device <NUM> may include a processor <NUM>, a memory <NUM>, and the computational NIC <NUM>. The electronic device <NUM> may further include the CXL memory expander <NUM> (see <FIG>).

The processor <NUM> may process data stored in the memory <NUM>. The processor <NUM> may execute a computer-readable code (e.g., software) stored in the memory <NUM> and instructions triggered by the processor <NUM>. The processor <NUM> may execute an operating system kernel that manages resources of the electronic device <NUM>. Processes/threads managed by the operating system kernel may execute on the processor <NUM> and may make requests to access resources (e.g., file system objects) of the distributed file system <NUM>. Metadata may be requested directly or indirectly as a result (e.g. by a DFS module) of requesting file system objects.

The processor <NUM> may be a hardware-implemented data processing device with a physically structured circuit to execute desired operations. The desired operations may include, for example, code or instructions included in a program. The hardware-implemented data processing device may include, for example, a microprocessor, a central processing unit (CPU), a processor core, a multi-core processor, a multiprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or combinations thereof.

The memory <NUM> may be implemented as a volatile memory device or a non-volatile memory device. A volatile memory device may be implemented as, for example, a dynamic random-access memory (DRAM), a static RAM (SRAM), a thyristor RAM (T-RAM), a zero capacitor RAM (Z-RAM), or a twin transistor RAM (TTRAM). A non-volatile memory device may be implemented as, for example, an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic RAM (MRAM), a spin-transfer torque MRAM (STT-MRAM), a conductive bridging RAM (CBRAM), a ferroelectric RAM (FeRAM), a phase change RAM (PRAM), a resistive RAM (RRAM), a nanotube RRAM, a polymer RAM (PoRAM), a nano floating gate Memory (NFGM), a holographic memory, a molecular electronic memory device, or an insulator resistance change memory.

The computational NIC <NUM> may also be referred to as a smart NIC or a data processing unit. The computational NIC <NUM> have one or more processors that may perform functions throughout the network stack (even as high as the application layer, depending on implementation). The computational NIC <NUM> may be configured for offloading network processing from the processor <NUM> (a host processor) to a processor of the computational NIC <NUM> (although such use is not required). The computational NIC <NUM> may perform an operation (e.g., managing metadata) through a processor thereof (e.g., a NIC processor <NUM> of <FIG>). The computational NIC <NUM> may cache DFS metadata and may perform cache management functionality. That is, the computational NIC <NUM> may store (or partly store) and manage locally cached DFS metadata.

The CXL memory expander <NUM> may be configured in a similar form to that of a solid-state drive (SSD) and may be an external storage device. The CXL memory expander <NUM> may be provided at a position where an SSD is provided and may contribute to the expansion of DRAM capacity. The CXL memory expander <NUM> may be used for caching DFS metadata. The computational NIC <NUM> and the CXL memory expander <NUM> are described with reference to <FIG>.

<FIG> illustrates a computational NIC according to one or more example embodiments.

A computational NIC <NUM> may provide a connection (e.g., to another client device and/or a server) for an electronic device (e.g., the electronic device <NUM> of <FIG>) through a network (e.g., a local area network (LAN)). The computational NIC <NUM> may access a CXL memory expander <NUM> to access cached DFS metadata requested by the electronic device <NUM> or to store DFS metadata acquired from a metadata server.

Referring to <FIG>, the computational NIC <NUM> includes a NIC processor <NUM>, a NIC memory <NUM>, and a CXL-NIC <NUM> (a NIC portion of the computational NIC <NUM>).

The NIC processor <NUM> may be configured as a CPU that consumes relatively low power, for example, an FPGA or a reduced instruction set computer (RISC) microprocessor. The NIC processor <NUM> may manage DFS metadata cached in the NIC memory <NUM>, the CXL-NIC <NUM>, a cache <NUM>, and/or the CXL memory expander <NUM>. To avoid the latency time of accessing a metadata server (e.g., the metadata server <NUM>) with a small cost, the NIC processor <NUM> may be configured to manage local caching of DFS metadata (in some implementations, for improved performance, the NIC processor <NUM> may be reserved for only/primarily managing local DFS caching).

The NIC memory <NUM>, the CXL-NIC <NUM>, the cache <NUM>, and/or the CXL memory expander <NUM> may function as a locale cache for storing DFS metadata.

The CXL-NIC <NUM> may support CXL. cache as defined in a CXL protocol. The CXL-NIC <NUM> may be a type <NUM> device as defined in a CXL protocol. The CXL-NIC <NUM> may include a cache (e.g., a cache <NUM> of <FIG>). The cache <NUM> of the CXL-NIC <NUM> may store DFS metadata.

The cache <NUM> may be a memory that serves as an intermediate buffer to improve the speed of communication between the NIC memory <NUM> and the NIC processor <NUM> (e.g., Level-<NUM> cache). The cache <NUM> may have a faster data processing/access speed than the NIC memory <NUM>. The NIC processor <NUM> may perform fast processing of DFS requests by storing and accessing, in the cache <NUM>, some of data (e.g., DFS metadata) stored in the NIC memory <NUM>.

The CXL memory expander <NUM> supports CXL. mem as defined in a CXL protocol. The CXL memory expander <NUM> may be a type <NUM> device as defined in a CXL protocol. The CXL memory expander <NUM> may be directly connected to the electronic device <NUM> and the computational NIC <NUM> through a CXL interface.

The CXL memory expander <NUM> may include a memory device <NUM> and a controller <NUM>.

The memory device <NUM> may store data (e.g., DFS metadata). The controller <NUM> may control writing of data (e.g., DFS metadata) in the memory device <NUM> and reading of data (e.g., DFS metadata) stored in the memory device <NUM>.

The controller <NUM> may receive a DFS metadata work/operation request which is a request for working/operating on metadata; the request may come from the electronic device <NUM> including the computational NIC <NUM>. The computational NIC <NUM> may assign, to a process on the electronic device <NUM> (e.g., an operating system process), a metadata work permission for working on local DFS metadata. The controller <NUM> may receive the metadata work request from the process. The metadata described herein may be DFS metadata used in a distributed file system and the metadata work request may be a read or write request.

In response to the received work request, the controller <NUM> may perform a corresponding operation on the DFS metadata. For example, in response to the read request for metadata, the controller <NUM> may transmit the metadata corresponding to the read request to the electronic device <NUM> (e.g., based on the electronic device or its process having a metadata read permission). For example, in response to a metadata write request, the controller <NUM> may change/update/store DFS metadata included with the request and store the DFS metadata. Writing DFS metadata to a local cache may affect cache coherency. Operations for maintaining the coherency of metadata stored in the CXL memory expander <NUM> (or another local memory) are described with reference to <FIG>.

The CXL memory expander <NUM> may expand storage space of the computational NIC <NUM>, and by extension, the electronic device <NUM>. The electronic device <NUM> including the CXL memory expander <NUM> may simultaneously use a storage space of a host memory (e.g., the memory <NUM> of <FIG>) and a storage space of the CXL memory expander <NUM>. The electronic device <NUM> may use the CXL memory expander <NUM> to cache DFS metadata and thereby reduce the latency of local DFS requests of the electronic device <NUM> and increase throughput of local DFS requests.

In addition, caching DFS metadata in the CXL memory expander <NUM> may facilitate the electronic device <NUM> accessing the metadata using the CXL memory expander <NUM>. In addition, using the metadata stored in the CXL memory expander <NUM> may reduce the load on the metadata servers <NUM>, particularly if many clients are configured for local caching of metadata.

The computational NIC <NUM> (that is handling local DFS requests and providing local metadata caching) may provide an immediate response to a DFS request of the electronic device <NUM> (e.g., a request relating to or requiring DFS metadata). When receiving a request relating to metadata (e.g., a metadata work request or a file request), the computational NIC <NUM> may sequentially check its local cache storage: whether the metadata is stored in (i) the cache <NUM>, (ii) a cache of the CXL-NIC <NUM> (e.g., a cache <NUM> of <FIG>), (iii) the NIC memory <NUM>, or (iv) in the CXL memory expander <NUM> (other combinations of local storage and other checking orders may be used). When the metadata is found in the local cache storage, the computational NIC <NUM> may provide an immediate response to the electronic device <NUM> without communicating with a metadata server <NUM>. Not all four types of local storage may be used for local metadata caching; any one, or any combination of the types of local storage may be used.

When metadata requested by the electronic device <NUM> is determined to be stored (available) in the local DFS metadata cache (e.g., any one or more of cache <NUM>, the cache <NUM> of the CXL-NIC <NUM>, the NIC memory <NUM>, or the CXL memory expander <NUM>), such a case may be referred to as a "cache hit. " When metadata requested by the electronic device <NUM> is not stored in the local DFS metadata cache, such a case may be referred to as a "cache miss.

To increase a cache hit probability of the computational NIC <NUM>, storage capacity of the local metadata cache may be increased. To do so, the computational NIC <NUM> may use a CXL device (e.g., the CXL-NIC <NUM> or the CXL memory expander <NUM>) supporting the CXL protocol. CXL devices are described next.

<FIG> illustrates an example CXL device included in an electronic device according to one or more example embodiments, and <FIG> illustrates an example electronic device including a CXL device (e.g., the CXL device in <FIG>), according to one or more example embodiments.

A CXL device that supports a CXL protocol (CXL. cache, CXL. mem, and CXL,io) may be classified as type <NUM>, type <NUM>, or type <NUM> device according to a supported type of the CXL protocol. A CXL device that supports CXL. cache through a CXL interface may be a type <NUM> device. A CXL device that supports CXL. mem through the CXL interface may be a type <NUM> device. A CXL device that supports both CXL. cache and CXL. mem through the CXL interface may be a type <NUM> device.

Referring to the first example <NUM> of <FIG>, the computational NIC <NUM> may use the CXL-NIC <NUM>. The CXL-NIC <NUM> may support CXL. cache as defined in a CXL protocol (multiple versions of the CXL protocol specify CXL. cache, and any such version may be used/supported). The computational NIC <NUM> may also support CXL. The computational NIC <NUM> may share the cache <NUM> of the CXL-NIC <NUM> supporting the same CXL protocol. The computational NIC <NUM> may simultaneously use the cache <NUM> and the cache <NUM> of the CXL-NIC <NUM>, which may allow the cache capacity of the computational NIC <NUM> to be increased. The computational NIC <NUM> may be a type <NUM> or type <NUM> device as defined in the CXL protocol.

Referring to the second example <NUM> of <FIG>, the computational NIC <NUM> may use the CXL memory expander <NUM>. The CXL memory expander <NUM> may support CXL. mem as defined in a CXL protocol. The computational NIC <NUM> may also support CXL. The computational NIC <NUM> may use the CXL memory expander <NUM> supporting the same CXL protocol. The memory capacity of the computational NIC <NUM> may be increased. Although the NIC memory <NUM> is illustrated as including a DRAM in <FIG>, the implementation thereof is not limited to the DRAM. The computational NIC <NUM> may be a type <NUM> or type <NUM> device as defined in the CXL protocol.

Referring to <FIG>, the computational NIC <NUM> may be configured to simultaneously use the CXL-NIC <NUM> and the CXL memory expander <NUM> (i.e., a combination of the first and second examples <NUM>, <NUM>). The computational NIC <NUM> may include the CXL-NIC <NUM>. The computational NIC <NUM> may share a storage space with the CXL memory expander <NUM>.

The computational NIC <NUM> may simultaneously support CXL. mem and CXL. cache as defined in a CXL protocol. The computational NIC <NUM> may be a type <NUM> device as defined in the CXL protocol.

The computational NIC <NUM> may receive a request (e.g., a host request) for metadata from the processor <NUM> through the CXL interface. Alternatively, the computation NIC <NUM> may receive a file/object request and may itself generate a corresponding request for DFS metadata. The computational NIC <NUM> may check whether the DFS metadata is locally cached.

When the metadata is locally cached, the computational NIC <NUM> may respond quickly to the request of the processor <NUM> by bypassing accessing a metadata server <NUM>. The computational NIC <NUM> may first check whether the metadata is stored (e.g., cached) in a cache type of memory (e.g., the cache <NUM> or the cache <NUM>) because the cache type of memory (e.g., cache <NUM> and <NUM>) may have a faster data processing speed than other memory included in the local DFS metadata cache (e.g., the NIC memory <NUM> and the CXL memory expander <NUM>). When the metadata is determined to be not stored in the cache/fast type of memory of the local DFS metadata cache (e.g., cache <NUM> and <NUM>), the computational NIC <NUM> may check whether the requested/needed DFS metadata is stored in the ordinary/slower memory of the local DFS metadata cache (e.g., the NIC memory <NUM> or the CXL memory expander <NUM>).

When the requested DFS metadata is determined to be not stored in the local DFS metadata cache, the computational NIC <NUM> may respond to the request of the processor <NUM> by accessing the metadata server <NUM>. Operations performed by the computational NIC <NUM> are described with reference to <FIG> and <FIG>.

<FIG> illustrate examples of connection structure for types of computational NICs according to one or more example embodiments, and <FIG> illustrate examples of a structure of a type <NUM> computational NIC according to one or more example embodiments.

The computational NIC <NUM> may be arranged with a serial or parallel connection structure according to a type of connection between the NIC processor <NUM> and a NIC (e.g., the CXL-NIC <NUM> or a NIC <NUM>). According to the type of connection between the NIC processor <NUM> and the NIC (e.g., the CXL-NIC <NUM> or the NIC <NUM>), a path through which a client device (e.g., the electronic device <NUM> of <FIG>) accesses local metadata may differ.

As described below, a structure of the computational NIC <NUM> may have any of six types of structures (or others). Although the structure of a computational NIC <NUM> may be classified in further detail according to the characteristics (e.g., privately owned and coherence) between a cache included in the NIC processor <NUM> and a cache included in the NIC (e.g., the CXL-NIC <NUM> or the NIC <NUM>), such other features are not considered herein for classification. Accordingly, the structure of the computational NIC <NUM> is not limited to the examples of <FIG>.

Referring to the first example <NUM> shown in <FIG>, a serial structure of a type computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may support CXL. cache and may not support CXL. The CXL-NIC <NUM> and the NIC processor <NUM> may be connected in series, and a client device including the computational NIC <NUM> may access cached DFS metadata via the NIC processor <NUM>.

Referring to the second example <NUM> of <FIG>, illustrated is a parallel structure of a type <NUM> computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may support CXL. cache and may not support CXL. The CXL-NIC <NUM> and the NIC processor <NUM> may be connected in parallel, and a client device including the computational NIC <NUM> may access cached DFS metadata therein without passing through the NIC processor <NUM>.

Referring to the third example <NUM> of <FIG>, illustrated is a serial structure of a type <NUM> computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may not support CXL. cache but may support CXL. The NIC <NUM> and the NIC processor <NUM> may be connected in series, and a client device including the computational NIC <NUM> may access DFS metadata cached therein via the NIC processor <NUM>.

Referring to the fourth example <NUM> of <FIG>, illustrated is a parallel structure of a type <NUM> computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may not support CXL. cache but may support CXL. The NIC <NUM> and the NIC processor <NUM> may be connected in parallel, and a client device (e.g., a host process) including the computational NIC <NUM> may access locally cached DFS metadata without passing through the NIC processor <NUM>.

Referring to the fifth example <NUM> of <FIG> and <FIG>, illustrated is a serial structure of a type <NUM> computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may support both CXL. cache and CXL. The CXL-NIC <NUM> and the NIC processor <NUM> may be connected in series, and a client device including the computational NIC <NUM> may access locally cached DFS metadata via the NIC processor <NUM>.

Referring to the sixth example <NUM> of <FIG> and <FIG>, illustrated is a parallel structure of a type <NUM> computational NIC <NUM> as defined in a CXL protocol. The computational NIC <NUM> may support both CXL. cache and CXL. The CXL-NIC <NUM> and the NIC processor <NUM> may be connected in parallel, and a client device including the computational NIC <NUM> may access locally cached DFS metadata without passing through the NIC processor <NUM>.

When a device (e.g., the electronic device <NUM> of <FIG> or the metadata server <NUM> of <FIG>) or a system (e.g., a distributed file system) supports the CXL. cache protocol, a local cache-type memory area may be used more readily for local caching of DFS metadata. When a device (e.g., the electronic device <NUM> or the metadata server <NUM>) or a system (e.g., the distributed file system) supports the CXL. mem protocol, DFS metadata caching by memory sharing may be facilitated. Since cache coherency may be guaranteed through the CXL. cache protocol, performing shared memory access in a situation where cache coherency is guaranteed may reduce software overhead associated with cache coherency (i.e., there may be less overhead to assure cache coherency). When a device (e.g., the electronic device <NUM> or the metadata server <NUM>) or a system (e.g., the distributed file system) supports both CXL. cache and CXL. mem, shared memory access may be facilitated. Operations of the metadata server <NUM> and the electronic device <NUM> are now described in further detail.

<FIG> illustrates an example operation of a metadata server and an electronic device according to one or more example embodiments, and <FIG> illustrates an example flow of operations performed by an electronic device according to one or more example embodiments.

Referring to <FIG>, a first computational NIC of a first electronic device <NUM> (first client) and a second computational NIC of a second electronic device <NUM> (second client) may manage work permissions for DFS metadata (e.g., metadata A). The first and second computational NICs may be implemented, e.g., as a computational NIC <NUM>. The first computational NIC may manage metadata permissions with respect to metadata in its first local cache <NUM> (which may be a combination of cache-type memory and/or other memory, as described above), for threads or processes running on the first computational NIC (or its host/electronic device) that are using the DFS. The second computational NIC may manage metadata permissions with respect to metadata in its second local cache <NUM> (which may be a combination of cache-type memory and/or other memory), for threads or processes running on the first computational NIC (or its host/electronic device) that are using the DFS. A metadata server (e.g., a metadata server <NUM> of <FIG>) may globally manage work permission for metadata with global scope. The computational NICs may manage work permission for metadata in respective local DFS cache storage. As described next, the metadata server and the computational NICs may thereby cooperatively manage metadata work permission by dividing it therebetween as described above, and coherency (integrity) of the metadata may thus be efficiently maintained. Note that although permission/authority is discussed with respect to metadata, permission may also be with respect to files in the DFS; the practical effect is the same, in that permission of metadata is managed, whether directly or indirectly. Where mention is made of metadata permission management, by extension, the same description applies to managing permissions of files or other DFS filesystem objects.

The metadata server may apply a mechanism for granting and revoking metadata management permissions for metadata (e.g., metadata A) to and from the computational NICs (e.g., NIC processor <NUM> of the first computational NIC and NIC processor <NUM> of the second computational NIC). Permission may be in the form of a transferrable security token. For example, when the metadata (e.g., metadata A) stored in the metadata server is stored (e.g., cached) in the first local cache <NUM> of the first computational NIC, the metadata server may transfer (e.g., assign) a token granting local management permission to the first computational NIC (security tokens may have lifespans and expire). While the local management permission obtained by the first computational NIC remains valid, the first electronic device <NUM> (e.g., a client device) including the first computational NIC may use its locally stored copy of the metadata (e.g., the cached metadata A) without accessing the metadata server.

As discussed next, the nature of the management permission can vary with the type of operation to be performed. In the case of writing, the metadata server may grant only one write-permission token to any of the clients for a piece of metadata (i.e., only one client has permission to locally update that piece of metadata, e.g., metadata A). The client holder of the write-permission token may have exclusive permission to update the corresponding piece of metadata in its local metadata cache. The write-permission token can be pulled back from the current client/holder (revoked) to the metadata server and then the token (or another) may be provided to another client when that other client needs write permission for the corresponding piece of metadata. In the case of reading, the metadata server may grant multiple read-permission tokens to respective clients for a piece of metadata (e.g., metadata A), and the clients with such tokens may manage local reading permission for the relevant metadata (e.g., metadata A) in their corresponding local metadata caches. When needed, e.g., to help maintain cache coherency in the case of a write, the metadata server may revoke any or all of the read-permission tokens. Write permission may be considered "complete" permission in that it also carries read permission. The metadata server(s) may track which tokens/permissions have been granted to which clients/electronic devices for which pieces of metadata, which may enable recall/revocation of same.

When the second electronic device <NUM> (e.g., a client device), for example, is to perform an update operation on (locally update) its local metadata (e.g., its copy of metadata A in the first local cache <NUM>) for which the write-permission management is currently held by the first computational NIC per its possession of a corresponding write-permission token, the metadata server may revoke (e.g., deactivate) the write-management permission assigned to the first computational NIC by pulling back its write-permission token. The metadata server may then transfer (e.g., assign) the write-permission management for metadata A to the second computational NIC by sending it the same (or another) write-permission token for metadata A. Through this mechanism, data coherency (integrity) may be guaranteed in a situation where multiple electronic devices (e.g., the first and second electronic devices <NUM> and <NUM>) are accessing the same metadata (e.g., metadata A). The metadata server may collectively manage, in this fashion, the work permission for all metadata in the global area. A computational NIC may be assigned (e.g., entrusted) with the local management permission for some of the metadata in its local DFS metadata cache area.

As noted, operations by a client on metadata may include reading and writing. As described next, parallel reading may be performed by a plurality of electronic devices (e.g., processes/threads of different clients) on one piece of metadata by allowing those electronic devices to each hold read-permission for that piece of metadata at the same time. As noted, writing may be performed by only allowing one electronic device (e.g., one process) at a time to hold write permission for a corresponding piece of metadata.

For example, the first electronic device <NUM> may request the first computational NIC for a read permission for metadata A required for process <NUM>-<NUM>. Such request may be responsive to, or a part of, a request to read the file system object (e.g., a file) associated with metadata A. When the first computational NIC determines that it does not currently have read-permission for metadata A (e.g., permission to assign read permission for metadata A to local threads/processes), the first computational NIC may request the metadata server for read-permission management for metadata A and obtain the management permission (e.g., a read-permission token). The metadata server may make a record of the granted permission and provide the permission. The first computational NIC may then assign read permission for metadata A to its local process <NUM>-<NUM> (e.g., the first electronic device <NUM> performing process <NUM>-<NUM>).

In a case in which the same metadata (e.g., metadata A) is requested when the first electronic device <NUM> is executing process <NUM>-<NUM> (i.e., when the first electronic device <NUM> is executing process <NUM>-<NUM> and process <NUM>-<NUM> simultaneously), the first electronic device <NUM> may request the first computational NIC for the read permission for metadata A required for process <NUM>-<NUM>. The first computational NIC, having the read-permission management for metadata A (e.g., the permission to locally assign the read permission), may assign the read permission for metadata A to process <NUM>-<NUM> (e.g., the first electronic device <NUM> performing process <NUM>-<NUM>) without communicating with the metadata server. The first electronic device <NUM> may simultaneously execute process <NUM>-<NUM> and process <NUM>-<NUM> and allow them to locally access metadata A, without requiring communication with the metadata server, which may thus reduce locking overhead.

In a case in which the same metadata (e.g., metadata A) is requested when the second electronic device <NUM> is executing process <NUM>-<NUM> (which may be executing in parallel with process <NUM>-<NUM>, process <NUM>-<NUM>, and process <NUM>-<NUM>), the second electronic device <NUM> may request the second computational NIC for the read permission for metadata A required for process <NUM>-<NUM>. The second computational NIC may determine that it does not hold read-permission for metadata A (e.g., permission to locally assign the read permission), and thus the second computational NIC may request the metadata server for read-permission for metadata A and obtain the read-permission (e.g., a read-permission token). The metadata server may make a record of the permission granted and provide the same. The second computational NIC may then assign the read permission for metadata A to process <NUM>-<NUM> (e.g., the second electronic device <NUM> performing process <NUM>-<NUM>). As described above, reading may be performed simultaneously by multiple processes (executing on multiple electronic devices), whereas writing may be performed only by a single process (of a single electronic device) at a time. Note that in the case of a client/device holding write permission for a piece of metadata, that client/device may freely shift the write permission among its local processes (but only one such local process at a time is granted write permission). In addition, a client/device holding the exclusive write permission also has read permission.

In a case in which write permission for the same metadata (e.g., metadata A) is requested by the second electronic device <NUM> is executing process <NUM>-<NUM> (while process <NUM>-<NUM>, process <NUM>-<NUM>, and process <NUM>-<NUM> are also executing) , the second electronic device <NUM> may request the second computational NIC for the write permission for metadata A required for process <NUM>-<NUM>. The second computational NIC may have only limited management permission (e.g., permission to locally assign only read permission), and thus the second computational NIC may request the metadata server for write-permission management (e.g., a permission to assign the write permission) for metadata A. The metadata server may revoke any previously granted management permissions to any other clients based on its recording of such previously granted permissions (e.g., the read permission assigned to the first computational NIC and the read permission assigned to the second computational NIC, or a previously granted write permission). The metadata server may assign, to the second computational NIC, write-permission management (e.g., a write-permission token granting permission to locally assign the read and/or write permission) for metadata A. The second computational NIC may then assign write permission for metadata A to process <NUM>-<NUM> (e.g., the second electronic device <NUM> performing process <NUM>-<NUM>).

In a case in which the write permission for the same metadata (e.g., metadata A) is requested when the second electronic device <NUM> is executing process <NUM>-<NUM> (while process <NUM>-2is executing), the second electronic device <NUM> may request the second computational NIC for write permission for metadata A required for process <NUM>-<NUM>. In response, the second computational NIC may revoke the write permission previously assigned to process <NUM>-<NUM>. The second computational NIC may then assign write permission for metadata A to process <NUM>-<NUM> (e.g., the second electronic device <NUM> executing process <NUM>-<NUM>). As described above, since the work permission (e.g., the write permission) for metadata A is moved only internally/locally, communication with the metadata server may not be required, and locking overhead may thus be reduced.

Generally, when a read or write permission is revoked from a client/device by a metadata server, in response, that client/device's computational NIC will also revoke any corresponding read or write permission that has been granted to its local processes.

<FIG> illustrates operations performed by an electronic device according to one or more embodiments.

In operation <NUM>, a processor (e.g., the processor <NUM> of <FIG>) requests a computational NIC (e. , the NIC <NUM> of <FIG>) for a work permission for metadata required for a first process. The requested work permission may be a read permission or a write permission for the metadata.

In operation <NUM>, when the computational NIC <NUM> determines that it does not currently management permission for the requested work permission for the metadata (e.g., the metadata required for the first process), the computational NIC <NUM> requests a metadata server (e.g., a metadata server <NUM> of <FIG>) for the requested management permission. The management permission may be read-permission or write permission (which includes read permission), which is to be used for a process (e.g., the first process) executed by the processor <NUM>.

In operation <NUM>, the computational NIC <NUM> obtains the management permission (e.g., a read-permission token or a write-permission token) from the metadata server <NUM>, and assign the work permission (e.g., the read and/or write permission for the metadata) to the first process (e.g., the processor <NUM> executing the first process).

The metadata server <NUM> may collectively manage work permission for all metadata in a global area (or a global namespace) of a DFS. The computational NIC <NUM> may be entrusted, by the metadata server <NUM>, with a management permission for some of the metadata in the local DFS metadata cache of the computation NIC <NUM>. As the metadata server <NUM> and the computational NIC <NUM> manage the work permission for metadata by dividing responsibility therebetween as described above, coherency (or integrity) of data (e.g., metadata) may be efficiently maintained. Hereinafter, operations internally performed in the computational NIC <NUM> will be described.

<FIG> illustrates a flow of operations performed by a computational NIC according to one or more example embodiments, and <FIG> illustrates an example flow of operations performed by a computational NIC according to one or more example embodiments.

In operation <NUM>, a NIC processor (e.g., the NIC processor <NUM> of <FIG>) receives a request for a work permission for metadata. The metadata are metadata used in a distributed file system (e.g., a Lustre distributed file system) and may be requested in conjunction with a request directed to a file system object (e.g., a file, directory, etc.) associated with the metadata. The request for the work permission for the metadata may be received from an electronic device (e.g., the electronic device <NUM> of <FIG>) including the NIC processor <NUM>.

In operation <NUM>, depending on the composition of its local DFS metadata cache, the NIC processor <NUM> sequentially checks whether the metadata is stored in in a first cache-type portion of its local DFS metadata cache (e.g., the cache <NUM> of <FIG>) of the NIC processor <NUM>, a second cache-type portion of its local DFS metadata cache (e.g., the cache <NUM> of <FIG>) of a NIC (e.g., the NIC <NUM> of <FIG>), a memory-type portion of its local DFS metadata cache (e.g., the NIC memory <NUM> of <FIG>), or a memory expander portion of its local DFS metadata cache (e.g., the CXL memory expander <NUM> of <FIG>). Depending on implementation or configuration, the local DFS metadata cache may include any combination of one or more of these types of local memory, and cache-checking may proceed accordingly.

The NIC <NUM> may be a CXL-NIC that supports CXL. cache defined in a CXL protocol. The memory expander <NUM> may be a CXL memory expander that supports CXL. mem defined in the CXL protocol. The computational NIC <NUM> may be a device of type <NUM>, type <NUM>, or type <NUM> as defined in the CXL protocol. Moreover, metadata functionality of a computational CXL NIC may be implemented as a core subsystem executing thereon (e.g., an agent, a controller, a driver, etc.). In the case of a computational CXL NIC with. cache functionality, local cache-type portion(s) of the local DFS metadata cache may be accessed using the. cache functionality. In the case of a computation CXL NIC with. mem functionality, a portion of the location DFS metadata cache in a CXL Memory Expander may be accessed through the. mem functionality.

Referring to <FIG>, in operation <NUM>, the NIC processor <NUM> may receive a request for a work permission for metadata. The work permission may refer to a permission to perform reading on the metadata or a permission to perform writing on the metadata. In response to the request, the NIC processor <NUM> may verify it has permission (e.g., a security token) corresponding to the requested work permission. If it does, then the operations of <FIG> may proceed. If it does not, then it may request the work permission from a metadata server <NUM>. If the work permission request is granted by the metadata server <NUM>, then the operations of <FIG> may proceed. I f the work permission is not granted by the metadata server <NUM>, then the request (in operation <NUM>) for work permission may fail.

In operation <NUM>, the NIC processor <NUM> may check whether the requested metadata is stored (e.g., cached) in the cache <NUM> of the NIC processor <NUM>. In operation <NUM>, when the requested metadata is stored (e.g., cached) in the cache <NUM> of the NIC processor <NUM>, the NIC processor <NUM> may verify whether the stored data (e.g., the cached data) is valid. The NIC processor <NUM> may verify a validity period (or flag) of the stored metadata. When the requested metadata is not stored in the cache <NUM> of the NIC processor <NUM> or the stored metadata is invalid, the NIC processor <NUM> may check a next storage space. When the requested metadata stored (e.g., cached) in the cache <NUM> of the NIC processor <NUM> is valid, the NIC processor <NUM> may provide a permission-granting response to the electronic device <NUM> (e.g., a client device) through a CXL interface.

In operation <NUM>, the NIC processor <NUM> may check whether the requested metadata is stored (e.g., cached) in the cache <NUM> of the NIC <NUM>. In operation <NUM>, when the requested metadata is stored (e.g., cached) in the cache <NUM> of the NIC <NUM>, the NIC processor <NUM> may verify whether the stored metadata (e.g., the cached metadata) is valid. When the requested metadata is not stored in the cache <NUM> of the NIC <NUM> or the stored metadata is invalid, the NIC processor <NUM> may check a next storage space.

In operation <NUM>, the NIC processor <NUM> may check whether the requested metadata is stored (e.g., cached) in the NIC memory <NUM>. In operation <NUM>, when the requested metadata is stored (e.g., cached) in the NIC memory <NUM>, the NIC processor <NUM> may verify whether the stored data (e.g., the cached data) is valid. When the requested metadata is not stored in the NIC memory <NUM> or the stored metadata is invalid, the NIC processor <NUM> may check a next storage space.

In operation <NUM>, the NIC processor <NUM> may check whether the requested metadata is stored (e.g., cached) in the memory expander <NUM>. In operation <NUM>, when the requested metadata is stored (e.g., cached) in the memory expander <NUM>, the NIC processor <NUM> may verify whether the stored data (e.g., the cached data) is valid.

In operation <NUM>, when the requested metadata is not stored in the memory expander <NUM> or the stored metadata is invalid, the NIC processor <NUM> may request a metadata server for the appropriate management permission for the requested metadata.

The locally-cached metadata may be managed by a low-power CPU (e.g., the NIC processor <NUM>) included in the computational NIC <NUM>. To reduce latency (e.g., latency that may be caused by access to the metadata server) with only a small cost, the NIC processor <NUM> may be configured to perform only an operation of managing metadata.

<FIG> illustrates a result <NUM> of a latent time-related simulation performed in a distributed file system.

An electronic device (e.g., the electronic device <NUM> of <FIG>) may use locally cached metadata. Using the locally cached metadata, the electronic device <NUM> may reduce a latency time in a distributed file system. The electronic device <NUM> may shorten a network path for access to the metadata in the distributed file system and reduce processing load of a metadata server. To verify the effect that may be achieved by using the stored metadata (e.g., the cached metadata), metadata easy read was performed on IO-<NUM> Mdtest.

Referring to <FIG> and Table <NUM>, a latency time of a device (indicated as baseline) that does not use locally cached metadata may be <NUM> milliseconds (ms) in total. In contrast, a latency time of a device (indicated as mdcache) (e.g., the electronic device <NUM>) using locally cached metadata may be <NUM> in total. As verified above, the latency time of the device (mdcache) that uses locally cached metadata may be reduced to <NUM>/<NUM> of the latency time of the device (baseline) that does not use locally cached metadata.

<FIG> illustrates a graph <NUM> showing performance of distributed file systems for a single client.

Referring to <FIG>, illustrated is a result obtained by performing mdtest-easy-read benchmark, for a system (Tiered MDS(metadata service)) including a plurality of systems (e.g., a typical system (e.g., Lustre)) and an electronic device (e.g., the electronic device <NUM> of <FIG>)), in a single client environment.

In the graph <NUM>, the x-axis indicates the number of processes performed in the system, the y-axis on the left side indicates kilo input/output operations per second (KIOPS) which are scores (e.g., operation processing speed) of a distributed system, and a broken line graph (Lustre, Tiered MDS) indicates a KIOPS score for each system. In the graph <NUM>, the y-axis on the right side indicates a degree of performance improvement, and a bar graph (Gain) indicates a degree of performance improvement of the system (Tiered MDS) including the electronic device <NUM> compared to the typical system (Lustre).

When a small number of processes are performed, the system (Tiered MDS) including the electronic device <NUM> may have higher performance than the typical system (Lustre). When <NUM> to <NUM> processes are performed, the performance improvement of the system (Tiered MDS) compared to the typical system (Lustre) may be approximately <NUM>% on average.

The computing apparatuses, the servers, the clients, the electronic devices, the processors, the memories, the NICs, the storage devices, and other apparatuses, devices, units, modules, and components described herein with respect to <FIG> are implemented by or representative of hardware components. Examples of hardware components that may be used to perform the operations described in this application where appropriate include controllers, sensors, generators, drivers, memories, comparators, arithmetic logic units, adders, subtractors, multipliers, dividers, integrators, and any other electronic components configured to perform the operations described in this application. In other examples, one or more of the hardware components that perform the operations described in this application are implemented by computing hardware, for example, by one or more processors or computers. A processor or computer may be implemented by one or more processing elements, such as an array of logic gates, a controller and an arithmetic logic unit, a digital signal processor, a microcomputer, a programmable logic controller, a field-programmable gate array, a programmable logic array, a microprocessor, or any other device or combination of devices that is configured to respond to and execute instructions in a defined manner to achieve a desired result. In one example, a processor or computer includes, or is connected to, one or more memories storing instructions or software that are executed by the processor or computer. Hardware components implemented by a processor or computer may execute instructions or software, such as an operating system (OS) and one or more software applications that run on the OS, to perform the operations described in this application. The hardware components may also access, manipulate, process, create, and store data in response to execution of the instructions or software. For simplicity, the singular term "processor" or "computer" may be used in the description of the examples described in this application, but in other examples multiple processors or computers may be used, or a processor or computer may include multiple processing elements, or multiple types of processing elements, or both. For example, a single hardware component or two or more hardware components may be implemented by a single processor, or two or more processors, or a processor and a controller. One or more hardware components may be implemented by one or more processors, or a processor and a controller, and one or more other hardware components may be implemented by one or more other processors, or another processor and another controller. One or more processors, or a processor and a controller, may implement a single hardware component, or two or more hardware components. A hardware component may have any one or more of different processing configurations, examples of which include a single processor, independent processors, parallel processors, single-instruction single-data (SISD) multiprocessing, single-instruction multiple-data (SIMD) multiprocessing, multiple-instruction single-data (MISD) multiprocessing, and multiple-instruction multiple-data (MIMD) multiprocessing.

Examples of a non-transitory computer-readable storage medium include read-only memory (ROM), random-access programmable read only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random-access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROMs, CD-Rs, CD+Rs, CD-RWs, CD+RWs, DVD-ROMs, DVD- Rs, DVD+Rs, DVD-RWs, DVD+RWs, DVD-RAMs, BD-ROMs, BD-Rs, BD-R LTHs, BD-REs, blue-ray or optical disk storage, hard disk drive (HDD), solid state drive (SSD), flash memory, a card type memory such as multimedia card micro or a card (for example, secure digital (SD) or extreme digital (XD)), magnetic tapes, floppy disks, magneto-optical data storage devices, optical data storage devices, hard disks, solid-state disks, and any other device that is configured to store the instructions or software and any associated data, data files, and data structures in a non-transitory manner and provide the instructions or software and any associated data, data files, and data structures to one or more processors or computers so that the one or more processors or computers can execute the instructions.

While this disclosure includes specific examples, it will be apparent after an understanding of the disclosure of this application that various changes in form and details may be made in these examples without departing from the scope of the claims. The examples described herein are to be considered in a descriptive sense only, and not for purposes of limitation. Descriptions of features or aspects in each example are to be considered as being applicable to similar features or aspects in other examples. Suitable results may be achieved if the described techniques are performed in a different order, and/or if components in a described system, architecture, device, or circuit are combined in a different manner, and/or replaced or supplemented by other components.

Claim 1:
A computational network interface card, NIC, sharing a storage space with a memory expander (<NUM>) thereof, the memory expander (<NUM>) being a CXL memory expander that supports CXL.mem as defined in a CXL protocol, the computational NIC (<NUM>) comprising:
a NIC memory (<NUM>) comprising instructions;
a NIC processor (<NUM>) comprising a cache (<NUM>) and electrically connected to the NIC memory (<NUM>); and
a NIC (<NUM>) configured to transmit data stored in the NIC memory (<NUM>) or the cache (<NUM>) to a network,
wherein, the instructions are configured to cause the NIC processor (<NUM>) to perform operations comprising:
receiving (<NUM>) a request to read or write metadata, wherein the metadata is used in a distributed file system and a client device (<NUM>) comprising the computational NIC (<NUM>) participates in the distributed file system;
checking (<NUM>) whether the requested metadata is stored in a local metadata cache of the computational NIC (<NUM>) by sequentially checking whether the metadata is stored in the cache (<NUM>) of the NIC processor (<NUM>), a cache (<NUM>) of the NIC, the NIC memory (<NUM>), or the memory expander (<NUM>); and
when the requested metadata is determined to be stored in the local metadata cache, verifying validity of the cached metadata; or
when the requested metadata is determined to not be stored in the local metadata cache, requesting a metadata server (<NUM>) for a metadata management permission of the requested metadata.