RDMA client and server resource isolation in connectionless environments

Abstract

The invention relates to RDMA client and server resource isolation in a connectionless environment. A system allows a first endpoint to communicate with a plurality of endpoints in a connectionless network environment by enabling a plurality of authentication keys by the first endpoint, respective ones of the plurality of endpoints being associated with respective authentication keys. The first endpoint receives, from a second endpoint of the plurality of endpoints, a first request including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The system verifies the first authentication key by matching the first authentication key with the enabled authentication key. The system performs the indicated action and returns the first authentication key to the completion event queue in response to performing the action. The system retrieves a first authentication key from the completion event queue and transmits data associated with the first request to the second endpoint based on the retrieved first authentication key.

Description

Background Technology Technical Field

[0001] Authentication keys can be used to restrict communication between endpoints. Only peer endpoints programmed with the same authentication key can communicate with each other. In connectionless environments (such as client / server environments with Remote Direct Memory Access (RDM) endpoints), a server may need to communicate securely with multiple clients and may also need to isolate Remote Direct Memory Access (RDMA) traffic between individual clients. Furthermore, the server may need to map incoming RDMA operations to specific authentication keys and respond to clients using client-specific authentication keys. One solution is to use a unique endpoint (with its own authentication key) for each client endpoint to communicate with a single server. However, this solution is not scalable when the server needs to support a large number of authentication keys for multiple clients (e.g., tens of thousands). Attached Figure Description

[0002] Figure 1 An environment that facilitates RDMA endpoint resource isolation in a connectionless environment is shown according to one aspect of this application.

[0003] Figure 2 A diagram illustrating communication that facilitates RDMA endpoint resource isolation (including support for multiple authentication keys in a single endpoint) in a connectionless environment, according to one aspect of this application, is shown.

[0004] Figure 3A An environment according to one aspect of this application is shown that facilitates RDMA endpoint resource isolation (including configuration software and hardware programming) in a connectionless environment.

[0005] Figure 3B An environment according to one aspect of this application is shown that facilitates RDMA endpoint resource isolation (including restricting access to specific resources) in a connectionless environment.

[0006] Figure 4 A diagram is shown that, according to one aspect of this application, facilitates communication for achieving RDMA endpoint resource isolation (including isolated memory regions) in a connectionless environment.

[0007] Figure 5A A flowchart illustrating a method for achieving RDMA endpoint resource isolation in a connectionless environment, according to one aspect of this application, is presented.

[0008] Figure 5B A flowchart illustrating a method according to one aspect of this application that facilitates RDMA endpoint resource isolation (including restricting access to specific resources) in a connectionless environment is presented.

[0009] Figure 5C A flowchart illustrating a method according to one aspect of this application that facilitates RDMA endpoint resource isolation in a connectionless environment (including verifying authentication keys based on access to the configuration of the resources) is presented.

[0010] Figure 6 A computer system according to one aspect of this application is shown that facilitates RDMA endpoint resource isolation in a connectionless environment.

[0011] Figure 7 A computer-readable medium is shown that, according to one aspect of this application, facilitates RDMA endpoint resource isolation in a connectionless environment.

[0012] In the accompanying drawings, similar reference numerals denote the same elements. Detailed Implementation

[0013] Various aspects of this application address the scalability limitations of inter-endpoint communication in connectionless network environments by allowing a single endpoint to support multiple authentication keys. Incoming RDMA operations (requests) can include client-specific authentication keys, and outgoing RDMA operations (responses) can dynamically select client-specific authentication keys. Furthermore, endpoints can restrict access to network resources (such as memory regions) by other specific endpoints in the connectionless network environment based on authentication keys and, in some cases, remote access keys. The described aspects can be implemented by extending existing network APIs (e.g., LibFabric) and modifying the underlying hardware (e.g., data structures in a network interface card (NIC)).

[0014] Connectionless network environments can include multiple endpoints that can communicate with each other based on authentication keys, such as a client / server environment with RDM endpoints. In some aspects, a single server endpoint (EP) may need to support, communicate with, or provide access to multiple client endpoints (EPs). Only peer endpoints programmed with the same authentication key can communicate with each other. Using a unique authentication key for each endpoint prevents client EPs from mistakenly or maliciously issuing RDMA operations to each other.

[0015] In a client / server environment with RDM endpoints (e.g., client EP and server EP), the server EP may need to securely communicate with multiple clients and may also need to isolate Remote Direct Memory Access (RDMA) traffic between individual clients. Furthermore, the server may need to map incoming RDMA operations to specific authentication keys and respond to clients using client-specific authentication keys. One solution is to use a unique endpoint (with its own authentication key) for each client endpoint to communicate with a single server. However, this solution is not scalable when the server needs to support a large number of authentication keys for multiple clients (e.g., tens of thousands).

[0016] The described aspects address these limitations by allowing a single endpoint to use (i.e., bind and enable) multiple authentication keys instead of one endpoint per client. Authentication keys can be associated with the storage region itself (as described below regarding appendices). Figure 1 (As described). The described aspects can use an authentication key container or list referred to as an "authentication key ring". An authentication key ring can define authentication keys upon which an enabled endpoint is based and used to verify whether the first authentication key of a client EP communicating with the server EP matches an enabled authentication key in the authentication key ring. Therefore, in a connectionless client / server network environment with at least one server EP and multiple client EPs, the server EP can configure an authentication key ring by enabling multiple authentication keys. The corresponding EP (in a multi-client EP) can be associated with a corresponding authentication key. This "one-to-many" mapping allows a single server EP to communicate with multiple client server EPs.

[0017] For example, multiple authentication keys per endpoint can be implemented by extending existing network APIs (such as LibFabric) and by modifying the underlying hardware (such as data structures in the NIC). Furthermore, when managing communication from multiple client EPs, including incoming RDMA operations (where each client EP can use a corresponding authentication key enabled in the server EP's authentication key ring), the network API associated with the server EP can report the specific authentication key used for the incoming RDMA operation. Therefore, the server EP can choose which authentication key to use when performing outgoing RDMA operations, as described below. Figure 2 and Figure 5A As described. Furthermore, the server EP can restrict client EP access to network resources (e.g., receive buffers, memory areas, etc.) based on an authentication key ring and, in some respects, on a remote access key configured for a specific memory region, as described below. Figure 3B and Figure 4 As described.

[0018] The term "endpoint" ("EP") refers to a computing entity capable of transmitting or receiving data. An endpoint in this disclosure may include one of multiple endpoints in a client / server connectionless network environment, such as a server EP and client EPs. Furthermore, in this disclosure, a server EP is used as an example of a single EP communicating with multiple client EPs. However, the operations and communications described herein are not limited to a server EP and can be used by any endpoint in a connectionless network environment when communicating with multiple other endpoints.

[0019] An "authentication key" is used to verify that one endpoint can securely communicate with another. In some cases, an authentication key may be referred to as a "tag." An authentication key can be associated with a corresponding "handle." That is, a handle can identify the authentication key for an incoming RDMA operation. See below for more information. Figure 1 As described, the handle can be returned in the target completion event. The handle, along with the source address also returned in the target completion event, allows the server EP to respond to the correct and specific client associated with the incoming RDMA operation in outgoing RDMA operations. That is, the handle can be used to select the authentication key for outgoing RDMA operations. The server EP can change the authentication key on a per-RDMA-operation basis.

[0020] "Authentication key ring" refers to a container, list, table, or group of authentication keys. In this disclosure, the software of the server EP can configure the authentication key ring using multiple authentication keys and subsequently use the configured information to program the hardware of the server EP (e.g., TCAM and CAM), which allows the hardware to verify the authentication keys included in subsequent incoming RDMA operations.

[0021] Figure 1An environment 100, according to one aspect of this application, is illustrated that facilitates RDMA endpoint resource isolation in a connectionless environment. Environment 100 may include multiple clients (102 and 112) communicating with a single server (132). Each client may include a network interface card (NIC) and be associated with an endpoint (EP). For example, client 102 may include NIC 104 at address “0x1” and client EP 106 associated with authentication key “[handle_J]” and process identifier (PID) “0”. Similarly, client 112 may include NIC 114 at address “0x2” and client EP 116 associated with authentication key “[handle_M]” and PID “0”. Server 132 may include NIC 134 at address “0x0” and server EP 136 associated with multiple authentication keys (i.e., authentication key rings), including “[I,J]” and “[M,N]”. EP 136 may also be associated with PID “0”. EP 136 can be, for example, a LibFabric endpoint.

[0022] Server 132 may also include a plurality of receive buffers 138, wherein any one or more of receive buffers 138 may be associated with one or more authentication keys or any authentication key (e.g., as indicated by a "[match any handle]" or wildcard value of the associated authentication key of server 132). Server 132 may further include memory regions that may each be assigned to or allocated to a specific authentication key and remote access key or multiple specific authentication keys and remote access keys. For example, memory region 140 may be associated with authentication key "[handle_J]" and remote key "0x4", while memory region 142 may be associated with authentication key "[handle_M]" and remote key "0x5". Memory regions may also be configured to "match any handle", e.g., allocated to any authentication key or remote access key.

[0023] Server EP 136 can communicate using a software application programming interface (API) (via communication 170). For example, LibFabric EP 136 can utilize LibFabric address vector (AV) 150, which can be used (via communication 172) to construct an authentication key ring, such as authentication key 160 enabled or configured on server EP 136. Authentication key ring 160 can include a mapping of authentication key 164 to corresponding handle 162 of the authentication key. In authentication key ring 160, entry 166 can indicate that authentication key “J” is mapped to handle “0x1” (or “[handle_J]”), while entry 168 can indicate that authentication key “M” is mapped to handle “0x2” (or “[handle_M]”).

[0024] During operation, a single server EP 136 can communicate with multiple client EPs (e.g., 106 and 116) based on multiple authentication keys enabled for the single server EP 136, where each authentication key corresponds to a single client EP. For example, since server EP 136 has multiple authentication keys (including J and M) enabled in authentication key ring 160, client EP 106 can communicate with server EP 136 using a handle (“[handle_J]”) corresponding to authentication key “J” (via communication 180, which can occur between the corresponding NICs 104 and 134 of each entity, as indicated by communications 170 and 174). Similarly, client EP 116 can communicate with server EP 136 using a handle (“[handle_M]”) corresponding to authentication key “M” (via communication 182, which can occur between the corresponding NICs 114 and 134 of each entity, as indicated by communications 172 and 174).

[0025] By enabling multiple authentication keys for server EP 136 (and assuming the network can enforce the association of authentication keys with clients), the described aspects can eliminate or prevent unwanted direct communication between clients 102 and 112. For example, clients 102 and 112 cannot issue RDMA operations to each other, as indicated by the tag “X” 186 on potential communication 184 between clients 102 and 112. Furthermore, the described aspects can restrict server resources and server-associated resources (e.g., receive buffer 138 and memory areas 140 and 142) to specific clients based on authentication keys and remote access keys, as described below regarding… Figure 3B and Figure 4 As described.

[0026] Figure 2 Figure 200 illustrates communication according to one aspect of this application that facilitates RDMA endpoint resource isolation in a connectionless environment, including support for multiple authentication keys in a single endpoint. Figure 200 may include communication between a server EP 204 (“first endpoint”) and a client EP 202 (“second endpoint”). The server EP 204 may correspond to… Figure 1 The server EP 136, and the client EP 202 can correspond to, for example... Figure 1 The client version is EP 106 or 116.

[0027] Prior to the communication depicted in Figure 200, in a connectionless network environment including server EP 204 and multiple client EPs (such as client EP 202), server EP 204 can enable multiple authentication keys, wherein a corresponding EP (among the multiple client EPs) can be associated with a corresponding authentication key. This one-to-many mapping allows a single server EP to communicate with multiple client server EPs.

[0028] Server EP 204 can publish a receive buffer (operation 210). This can include synchronizing incoming RDMA operations or remote procedure calls (RPCs) received from all clients (including client EP 202) and inserting them into the receive buffer. The buffer can be a regular buffer or a flagged buffer, i.e., a buffer specifically allocated to the flag or other tag indicated in the corresponding incoming request. Figure 1 Similar to server EP 136, server EP 204 can be associated with multiple receive buffers, each of which can be configured to allow access based on a single authentication key, multiple authentication keys, or any authentication key (e.g., "[match any handle]" or wildcards), as described below. Figure 3B As described.

[0029] Client EP 202 may send RPC request 212 (to server EP 204) as part of an incoming RDMA request. RPC request 212 may include an action, the RPC, and a first authentication key associated with client EP 202 (e.g., “[handle_J]”). Server EP 204 may process the event for RPC request 212, for example, by performing the action indicated in the RPC request (operation 214). Server EP 204 may return the corresponding handle for the event in a completion queue event (“CQ event”) (operation 216). As part of an outgoing RDMA operation, server EP 204 may obtain the first authentication key by selecting the corresponding handle associated with RPC request 212. Using the selected handle (e.g., “[handle_J]”), server EP 204 may subsequently transmit the data associated with the RPC request (i.e., response data) back to client EP 202 (operation 218). That is, data can be transmitted to the RPC request-sending client EP (e.g., client EP202) based on the corresponding handle (“[handle_J]”). The server EP 204 can determine the completion of the transmission, for example, by receiving the last data packet corresponding to the completion of the transmission (operation 220), and can again send an RPC response message based on the corresponding handle (“[handle_J]”) (operation 222), wherein the response message may indicate that the requested data has been transmitted. In some aspects, the data transmitted in operation 218 may include notification that the requested data has been transmitted, essentially combining operations 218 and 222 into a single message or the same data stream.

[0030] Figure 3A An environment 300, according to one aspect of this application, is illustrated that facilitates RDMA endpoint resource isolation (including configuration software and hardware programming) in a connectionless environment. Environment 300 illustrates modules, components, units, memories, and data structures residing in hardware 302 (e.g., in a network interface card (NIC)) and software 304 (e.g., based on a software API, such as LibFabric). A user or system can use software 304 to configure certain information that can be used to program hardware 302. Hardware 302 can then enforce access (e.g., authentication keys) to incoming RDMA requests and support outgoing RDMA requests.

[0031] In software 304, LibFabric EP 320 can be associated with multiple authentication keys; that is, multiple authentication keys (“[I,J]+[M,N]”) are enabled on EP 320, and EP 320 can be associated with PID “0”. LibFabric EP 320 can be a server EP and can (via communication 350) invoke the software component LibFabric address vector (AV) 322 to store the multiple enabled authentication keys. LibFabric AV 322 can help (via communication 354) maintain the data structure of authentication key 324 (e.g., authentication key ring 324). Authentication key ring 324 can store entries that map authentication keys 328 to corresponding handles 326. For example: handle "0x0" (or "[handle_I]") can correspond to authentication key "I"; handle "size([I,J])-1" (or "[handle_J]") can correspond to authentication key "J"; handle "size([I,J])" (or "[handle_M]") can correspond to authentication key "M". Handle "size([M,N])-1" (or "[handle_N]") can correspond to authentication key "N".

[0032] LibFabric AV 322 can also help (via communication 352) maintain a data structure or table 330 for handling unicast communication. Table 330 may include entries with at least the following fields: handle 332; corresponding authentication key 334; network identifier (NID) 336; and process identifier (PID) 338. For example: handle “0x0” (also referred to as “[handle_I]”) may correspond to authentication key “I”, NID “0x0”, and PID “0x0”; handle “0x1” (also referred to as “[handle_J]”) may correspond to authentication key “J”, NID “0x1”, and PID “0x1”; handle “0x2” (also referred to as “[handle_M]”) may correspond to authentication key “M”, NID “0x2”, and PID “0x2”; and handle “0x3” (also referred to as “[handle_N]”) may correspond to authentication key “N”, NID “0x3”, and PID “0x3”.

[0033] In addition to enabling the authentication key ring 324, EP 320 can also configure resources 340, including but not limited to message queue 324, tag queue 344, memory area 346, and rendezvous resource 348. This is done after software 304 has been created. Figure 3AFollowing the mapping described herein, EP 320 can use the PID (“0”) of EP 320 to program (as indicated by operation 360) PID CAM 310 and program the enable and corresponding multiple authentication keys in TCAM 312 (as indicated by operation 368 and the correspondence 364 from PID CAM 310). Each entry in PID CAM 310 can correspond to PID index CAM 314 (as indicated by correspondence 362). Entries in PID index CAM 314 can be programmed to correspond to entries in resource 340 (as indicated by operation 370). That is, an entry for PID index CAM “0” can correspond to message queue 342, an entry for PID index CAM “1” can correspond to tag queue 344, and an entry for PID index CAM “2” can correspond to memory region 346.

[0034] Figure 3B An environment 380 is shown, according to one aspect of this application, which facilitates RDMA endpoint resource isolation (including restricting access to specific resources) in a connectionless environment. Environment 380 corresponds to Figure 3A Environment 300 and omitted Figure 3A The document describes some data structures and entities to describe restrictions on access to server resources. In environment 380, EP 320 has configured its resources 340 in a specific manner. For example, message queue 342 may include a receive (RX) buffer 385 restricted to an authentication key corresponding to "[handle_M]" and a receive (RX) buffer 386 restricted to an authentication key corresponding to "[handle_J]". The receive buffers can be restricted to a single authentication key (as described above for RX buffers 385 and 386), multiple authentication keys, or any authentication key based on a wildcard handle (as described above for a wildcard handle with "[matches any handle]"). Figure 1 The receive buffer 138 described herein or associated therewith. Furthermore, although not described, the tag queue 344 (and any resources in resource 340) may include resources such as buffers or memory areas, which are also limited to one, some, or all / any authentication keys or associated therewith.

[0035] In environment 380, EP 320 has also configured its memory region 346 in a specific manner. Memory region 387 can be restricted to access only by an endpoint with an authentication key corresponding to "[handle_J]" and using remote key "0x1", and memory region 388 can be restricted to access only by an endpoint with an authentication key corresponding to "[handle_M]" and using remote key "0x2". After EP 320 has configured its resource 340 in software 304, software 304 can use the corresponding information to program hardware 302. For example, in PID index CAM 314, the entry at index "0" can be programmed to correspond to message queue 342 of resource 340 (as indicated by operation 370.1). The entry at index "0" can include an entry indicating that the corresponding receive buffer can be accessed by the authentication keys corresponding to "[handle_J]" (as in matching entry 381) and "[handle_M]" (as in matching entry 382). Subsequently, upon receiving an RPC or RDMA request, hardware 302 can verify access to one or more receive buffers by performing a lookup in the PID index CAM 314 (which can be accessed and associated with PID CAM 310 and tag TCAM 312), as described below. Figures 5A-5C As described.

[0036] Furthermore, in the PID index CAM 314, the entry at index "2" can be programmed to correspond to memory region 346 of resource 340 (as indicated by operation 370.2). The entry at index "2" may include an entry indicating that memory region 388 can only be accessed using the authentication key corresponding to "[handle_J]" and the remote key "0x2" (as in matching entry 383). The entry at index "2" may also include an entry indicating that the memory region can only be accessed using the authentication key corresponding to "[handle_M]" and the remote key "0x1" (as in matching entry 384). Subsequently, upon receiving an RPC or RDMA request, hardware 302 can verify access to the corresponding memory region by performing a lookup in the PID index CAM 314 (which can be accessed and associated with PID CAM 310 and tag TCAM 312), as described below regarding... Figures 5A-5C As described. In some aspects, server EP 320 can return a remote access key (“RKEY”) corresponding to the authentication key provided by client EP to client EP, and client EP can subsequently use the provided remote access key to access the associated memory region in RDMA operations, as described below regarding Figure 4 and 5C As described. In Figure 3A and Figure 3B In this context, although resource 340 is depicted as part of software 304, resource 340 can indicate resources accessed by software 304 but residing in hardware 302.

[0037] Figure 4 Figure 400 illustrates communication that facilitates RDMA endpoint resource isolation (including isolated memory regions) in a connectionless environment, according to one aspect of this application. The connectionless environment depicted in Figure 400 may include client EP408, client EP402 (“second endpoint”, similar to…) Figure 2 Client EP 202), server EP 404 (“first endpoint”, similar to Figure 2 Server EP 204) and memory area 406 (similar to Figure 3A and Figure 3B Communication between memory regions 346). Figure 2 Similar to the communication in Figure 400, prior to the communication depicted in Figure 400, in a connectionless network environment including server EP 404 and multiple client EPs (such as client EPs 402 and 408), server EP 404 can enable multiple authentication keys, wherein the corresponding EP (among the multiple client EPs) can be associated with the corresponding authentication key, which allows server EP 404 to communicate with multiple client server EPs.

[0038] Client EP 402 may send an RDMA request 410 (to server EP 404). RDMA request 410 may include an RDMA action (such as a read or write) and a first authentication key associated with the client (e.g., "[handle_J]"). Server EP 404 may receive RDMA request 410, and the NIC of server EP 404 may verify the first authentication key by matching it against one of the enabled authentication keys (operation 412), for example, by searching or checking for a matching entry for the corresponding PID at PID index CAM 314, including index "0" for a matching entry for the receive buffer. Upon finding a matching entry (e.g., matching entry 381 for the authentication key corresponding to "[handle_J]"), server EP 404 may allocate the obtained receive buffer to client EP 402 based on "[handle_J]" (operation 414).

[0039] The NIC of server EP 404 can also verify access to the memory region by, for example, by searching or checking for matching entries for the corresponding PID at PID index CAM 314 (e.g., index "2" for matching entries for the memory region) (operation 416). Upon finding a matching entry (e.g., matching entry 384 for the authentication key corresponding to "[handle_J]"), server EP 404 can determine the corresponding remote access key (e.g., "RKEY:0x1") from the matching entry and can allocate the obtained memory region 387, which is restricted to client EP 402 based on "[handle_J]" (operation 420).

[0040] Server EP 404 can return the remote access key (“RKEY:0x1”) to client EP 402 (operation 422), and client EP 402 can use the returned remote access key to subsequently perform an RDMA operation on the corresponding allocated memory region (operation 424). That is, since subsequent RDMA requests including the authentication key and remote access key are allowed to access the memory region after verification checks by hardware 302, client EP 402 can use “RKEY:0x1” and its authentication key “[handle_J]” to access memory region 387. The memory region can be part of the same device as server EP 404, or it can be in or part of a separate storage device or storage medium, such as a LibFabric memory region.

[0041] Furthermore, subsequent attempts by other clients to access the memory region may fail or be rejected, as indicated by the dashed line for operation 426 made by client EP 408 (this dashed line is crossed out using the mark "X" 428). Because memory region 387 (in Figure 4 The memory region (described as memory area 406) is restricted to access only by client E 402 using the authentication key “[handle_J]” and the remote access key “RKEY:0x1”. Therefore, authentication performed by hardware 302 will fail because no matching entry exists for this memory region for client EP 404 using the authentication key “[handle_M]” and the remote access key “RKEY:0x2”. It is noted that the remote key can be returned to the client, and the authentication key can be enforced independently by the network layer at or near the injection point. Therefore, the remote key can be visible and usable by any entity that provides it, and the authentication key can be enforced as part of the client identity.

[0042] Therefore, the described aspects can restrict access to resources (e.g., memory regions) to a specific client EP or a group of client EPs (as described above). Figure 4 (as described in the communication), and may also allow any or all client EPs to access resources (e.g., receive buffers) (as described above regarding Figure 1 (As described in the "[Match any handle]" section of the receive buffer 138).

[0043] In outgoing RDMA operations, the authentication key can be referred to as a "tag," and the hardware structure defining the outgoing tag for the RDMA operation can be called a NIC "Communication Configuration Document" (CP). The EP's software can store pointers to handles identifying the Communication Configuration Document, while the Communication Configuration Document structure itself can reside in a data structure within the EP's hardware. When an outgoing RDMA operation is performed, commands can be queued to the hardware via a Transaction Command Queue (TXQ), for example, a command to issue an RDMA operation using a specified CP handle. Each TXQ can be associated with a NIC CP, and each CP can define the traffic category and tag for the RDMA operation. The hardware can query its data structure and determine which CP handle is associated with a specific tag (i.e., the authentication key). TXQs can be limited to supporting only a certain number of Communication Configuration Documents, such as 16. However, the system may need to support thousands of different tags (i.e., authentication keys).

[0044] The described aspects can address this limitation in outgoing RDMA operations by performing multiple checks related to identifying, modifying, and allocating new communication configuration documents. During operation, outgoing RDMA operations can be issued. The system can determine whether a matching CP is available in the cache (e.g., a cached CP+TXQ pair). If the matching CP is available in the cache, the system can queue the outgoing RDMA operation. If the matching CP is not available in the cache, software in the system can modify the attributes of the existing CP (e.g., by querying the driver to change the tag value of the existing CP).

[0045] The hardware can process commands to modify attributes (e.g., change the tag) and verify against the associated CP to determine if the tag is within acceptable limits. The hardware can use "matching under a mask," where verification of certain bits can be selectively disabled, allowing a context or CP to be associated with multiple tags. If the modification is successful (i.e., the tag is within acceptable limits), the system can queue the outgoing RDMA operation. If the modification is unsuccessful (i.e., the tag is not within acceptable limits), the hardware can reject the TXQ tag change, and the system can allocate a new CP (e.g., a new CP+TXQ pair). If the allocation is successful, the system can queue the outgoing RDMA operation. If the allocation is unsuccessful, the system can try again at a later time. By using this TXQ tag change mechanism to select the appropriate tag for outgoing RDMA operations, the described aspects can more efficiently allow software to pipeline RDMA operations to multiple different clients.

[0046] Figure 5A A flowchart 500 presents a method according to one aspect of this application for facilitating RDMA endpoint resource isolation in a connectionless environment. During operation, the system allows a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys by the first endpoint, with each corresponding endpoint associated with a corresponding authentication key (operation 502). The above relates to... Figure 1 and Figure 3A The configuration of authentication key rings 160 and 324 describes an example of enabling multiple authentication keys, where... Figure 1 and Figure 3A Servers EP 136 and 320 (“first endpoint”) respectively map the authentication key ring to the corresponding handle.

[0047] The system receives a first request (operation 504) from a second endpoint among multiple endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint, as described above regarding... Figure 2 The communication 212 from client EP 202 to server EP 204 is described. The first authentication key included in the first request may include a handle to the authentication key. The system verifies the first authentication key by matching it against one of the enabled authentication keys (operation 506). For example, in... Figure 3A In this system, a lookup can be performed on tag TCAM 312, which can be programmed by software 304 using the authentication key in authentication key ring 324. Programming hardware 302 allows hardware 302 to perform authentication and enforce access configured by software 304.

[0048] The system executes the action indicated in the first request (operation 508), as described above regarding the action... Figure 2 The server EP 204 performs operation 214 as described above. In response to this action, the system returns the first authentication key to the completion event queue (operation 510), as described above regarding... Figure 2 As described in operation 216. The system retrieves a first authentication key from the completion event queue (operation 512), as described above regarding modifying or selecting the appropriate authentication key in the outgoing RDMA operation. Based on the retrieved first authentication key, the system transmits the data associated with the first request to the second endpoint (operation 514), as described above regarding... Figure 2 The operation 218 (or a combination of operations 218 and 222) performed by server EP 204 is described.

[0049] Figure 5B A flowchart 520 illustrates a method according to one aspect of this application for enabling RDMA endpoint resource isolation (including restricting access to specific resources) in a connectionless environment. During operation, the system enables multiple authentication keys from a first endpoint, allowing the first endpoint to communicate with multiple endpoints in a connectionless network environment, wherein a corresponding endpoint among the multiple endpoints is associated with a corresponding authentication key (operation 522, similar to...). Figure 5A Operation 502). The above is about Figure 1 and Figure 3A The configurations for authentication key rings 160 and 324 respectively describe examples of enabling multiple authentication keys. The system maps authentication keys to corresponding handles and uses the authentication keys to program the TCAM (operation 524). Software in the endpoint can utilize the configured information (e.g., as described above regarding...) Figure 3A The hardware in the endpoint is programmed using various data structures, including TCAM 312, CAM 310, and 314. The system is configured by the first endpoint to access resources (operation 526) by mapping resources to one or more associated authentication keys (and optionally, remote access keys corresponding to memory region resources), as described above regarding... Figure 3B The message queue 342's receive buffers 385 and 386, and memory regions 387 and 388 of memory region 346 are described above. The system programs the CAM (operation 528) by mapping resources in content-addressable memory (CAM) to associated authentication keys, as described above regarding... Figure 3B As described in 370.1 and 370.2.

[0050] The system receives a first request (Operation 530, similar to Operation 530) from a second endpoint among multiple endpoints, consisting of an action, a remote procedure call, and a first authentication key associated with the second endpoint. Figure 5AOperation 504), as mentioned above regarding Figure 2 The communication 212 from client EP 202 to server EP 204 is described in the first request. The first authentication key included in the first request may include a handle to the authentication key. Operation in Figure 5C Continue at label A.

[0051] Figure 5C A flowchart of a method according to one aspect of this application that facilitates RDMA endpoint resource isolation in a connectionless environment (including verifying authentication keys based on access to the configured resources) is presented. If the system fails to successfully verify the first authentication key against the enabled authentication key (e.g., by performing an unsuccessful TCAM lookup) (decision 542 and "No" result 580), the operation returns. In some aspects, the system may send an error message (not shown) to the second EP. If the system successfully verifies the first authentication key against the enabled authentication key (e.g., by performing a successful TCAM lookup) (decision 542 and "Yes" result 582), the operation continues at decision 544.

[0052] If the system fails to successfully verify the first authentication key based on the configured access to the resource (e.g., by performing an unsuccessful CAM lookup) (Decision 544 and "No" result 584), the operation returns. If the system successfully verifies the first authentication key based on the configured access to the resource (e.g., by performing a successful CAM lookup) (Decision 544) and if the resource is a receive buffer (indicated by "Yes" 586), the system configures the second EP's access to the receive buffer by allocating the receive buffer and allowing the second EP to access it (Operation 550). For example, the system allows the second EP to access the receive buffer by performing a lookup in the CAM for the first authentication key as the associated authentication key of the receive buffer, as described above regarding... Figure 3B The RX buffers 385 and 386 are described.

[0053] If the verification of decision 544 is successful and if the resource is a memory region (“memory / region”) (indicated by “Yes” 588), the system configures the second EP to access the memory region by allocating the memory region and allowing the second EP to access it (operation 560). For example, the system allows the second EP to access the memory region by performing a lookup of the first authentication key in the CAM as the associated authentication key for the memory region, as described above regarding... Figure 3BThe memory region 346 is described above. The system returns the remote access key (RKEY) obtained from the successful CAM lookup (operation 562), as described above with respect to the RKEY associated with memory regions 387 and 388 and indicated in the hardware as matching entries 383 and 384.

[0054] After operations 550 and 562, the system inserts the first request into the receive buffer (operation 570), as described above. Figure 2 Operation 210 and Figure 3B The RX buffers 385 and 386 are described above. The system performs the action indicated in the first request (operation 572, similar to operation 508) by obtaining the first request from the receive buffer, as described above. Figure 2 As described in operation 214 performed by server EP 204. In response to the execution of the action, the system retrieves the first authentication key from the completion event queue (operation 574, similar to operations 510 and 512), as described above regarding... Figure 2 Operation 216 and the description regarding modifying or selecting the appropriate authentication key in the outgoing RDMA operation. Based on the acquired first authentication key, the system transmits data associated with the first request (optionally including the remote access key returned from a successful CAM lookup) to the second endpoint (operation 576, similar to operation 514), as described above regarding... Figure 2 Operation 218 (or a combination of operations 218 and 222) performed by server EP 204 and regarding Figure 3B memory region 346 and Figure 4 The communication described herein. Subsequently, the system may receive an RDMA request from the second EP, which includes a remote access key, and the system may authorize the second EP to access the allocated memory region by verifying and using the remote access key included in the RDMA request. Figure 5C (not shown in the text), as mentioned above regarding Figure 4 Operation 424 describes this. Therefore, the system can restrict access to resources based on a specific access key, such that endpoints attempting to access a given memory region but lacking a successfully authenticated authentication key and configured RKEY can be restricted from accessing that given memory region, as described in [example code]. Figure 4 The failure of communication attempt 426 is indicated by 428.

[0055] Figure 6A computer system 600 according to one aspect of this application is illustrated, which facilitates RDMA endpoint resource isolation in a connectionless environment. The computer system 600 includes a processor 602, a memory 604, and a storage device 606. The memory 604 may include volatile memory (e.g., random access memory (RAM)) that serves as managed memory and can be used to store one or more memory pools. Furthermore, the computer system 600 may be coupled to a peripheral input / output (I / O) user device 610 (e.g., a display device 611, a keyboard 612, and a pointing device 613). The storage device 606 includes a non-transitory computer-readable storage medium and stores an operating system 616, a content processing system 618, and data 632. The computer system 600 may be a first endpoint communicating with other endpoints in a connectionless network environment and may include more than Figure 6 The entities or instructions shown are fewer or more entities or instructions.

[0056] Content processing system 618 may include instructions that, when executed by computer system 600, cause computer system 600 to perform the methods and / or processes described in this disclosure. Specifically, content processing system 618 may include instructions 620 for allowing a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, wherein a corresponding endpoint among the multiple endpoints is associated with a corresponding authentication key, as described above regarding... Figure 1 and Figure 3A The configuration of the authentication key rings 160 and 324 is described above. Content processing system 618 may include instructions 622 for receiving a first request from a second endpoint among a plurality of endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint, as described above. Figure 2 The communication 212 from client EP 202 to server EP 204 is described.

[0057] The content processing system 618 may include instructions 624 for verifying the first authentication key by matching the first authentication key with one of the enabled authentication keys. For example, as described above... Figure 3A As described, hardware 302 (TCAM 312) can be programmed by software 304 using the authentication key in the authentication key ring 324, which can result in a subsequent lookup in tag TCAM 312, thereby allowing hardware 302 to perform verification and enforce the access configured by software 304. Content processing system 618 may include instructions 626 for performing the actions indicated in the first request, as described above regarding... Figure 2The operation 214 performed by server EP 204 is described above. Content processing system 618 may include instructions 628 for retrieving a first authentication key from a completion event queue in response to performing an action, as described above regarding... Figure 2 The operation 216 described above relates to modifying or selecting the appropriate authentication key in the outgoing RDMA operation. Content processing system 618 may include instructions 630 for transferring data associated with the first request to a second endpoint based on the acquired first authentication key, as described above regarding... Figure 2 As described in operation 218 (or a combination of operations 218 and 222) performed by server EP 204.

[0058] Data 632 may include any data required as input by the methods, operations, communications, and / or processes described in this disclosure, or generated as output by the methods, operations, communications, and / or processes described in this disclosure. Specifically, data 632 may store at least: an authentication key; a handle corresponding to the authentication key; a wildcard handle; a request; an RPC; an RDMA operation; a request indicating the type of action, remote operation, and authentication key; a remote access key; a completion event queue; a CAM; a TCAM; an authentication key ring; an entry; a matching entry; a verification result; a mapping; a mapping between authentication keys and resources; multiple enabled authentication keys; a PID; an NID; and an indicator of the source, including a receive buffer and a memory area.

[0059] Content processing system 618 may include more than Figure 6 The instructions shown are further instructions. For example, the content processing system 618 may also store instructions for performing the operations described above with respect to the following: Figure 1 , Figure 3A and Figure 3B The environment; Figure 2 and Figure 4 Communication and operation; Figure 5A , Figure 5B and Figure 5C The operations depicted in the flowchart; and Figure 7 The instructions in the computer-readable medium 700.

[0060] Figure 7A computer-readable medium (CRM) 700 according to one aspect of this application is illustrated, which facilitates RDMA endpoint resource isolation in a connectionless environment. The CRM 700 may be a non-transitory computer-readable medium or device storing instructions that, when executed by a computer or processor, cause the computer or processor to perform a method. The CRM 700 may store instructions 710 for allowing a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys by the first endpoint, wherein each of the multiple endpoints is associated with a corresponding authentication key, as described above regarding... Figure 1 and Figure 3A The configuration of the authentication key rings 160 and 324 is described above. The CRM 700 may additionally store instructions 712 for receiving, from a second endpoint among a plurality of endpoints, a first endpoint a first request including an action, a remote procedure call, and a first authentication key associated with the second endpoint, as described above regarding... Figure 2 The communication 212 from client EP 202 to server EP 204 is described.

[0061] The CRM 700 can also store instructions 714 for verifying the first authentication key by matching it against one of the enabled authentication keys, for example, as described above regarding... Figure 3A As described above, the CRM 700 can store instructions 716 for performing the actions indicated in the first request, as described above. Figure 2 The operation 214 performed by server EP 204 is described. CRM 700 can store instructions 718 for retrieving the first authentication key from the completion event queue in response to the execution of an action, as described above regarding... Figure 2 Operation 216 and the description regarding modifying or selecting the appropriate authentication key in the outgoing RDMA operation. The CRM 700 may additionally store instructions 720 for transferring data associated with the first request to a second endpoint based on the acquired first authentication key, as described above regarding... Figure 2 The operation 218 (or a combination of operations 218 and 222) performed by the server EP 204 is described.

[0062] CRM 700 can include more Figure 7 The instructions shown are further instructions. For example, the CRM 700 can also store instructions for performing the operations described above regarding the following: Figure 1 , Figure 3A and Figure 3B The environment; Figure 2 and Figure 4 Communication and operation; Figure 5A , Figure 5B and Figure 5C The operations depicted in the flowchart; and Figure 6Instructions for the content processing system 618 in the middle.

[0063] In summary, the disclosed aspects provide methods, computer systems, and computer-readable media (CRM) that facilitate RDMA endpoint resource isolation in a connectionless environment. During operation, the system allows a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, each of which is associated with a corresponding authentication key. The system receives a first request from a second endpoint among the multiple endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The system verifies the first authentication key by matching it against one of the enabled authentication keys. The system executes the action indicated in the first request. In response to executing the action, the system returns the first authentication key to a completion event queue. The system retrieves the first authentication key from the completion event queue. Based on the retrieved first authentication key, the system transmits the data associated with the first request to the second endpoint.

[0064] In a variation of this approach, the system enables multiple authentication keys by mapping the authentication key to the corresponding handle from the first endpoint and programming the ternary content-addressable memory (TCAM) using the authentication key.

[0065] In another variation of this aspect, the first authentication key included in the first request comprises a handle. The system further verifies the first authentication key by performing a lookup in the TCAM based on the handle of the first authentication key.

[0066] In another variant, the system configures access to resources from a first endpoint by mapping resources to one or more associated authentication keys. The system programs the Content Addressable Memory (CAM) by mapping resources to associated authentication keys in the CAM.

[0067] In another variant, the system further programs the CAM by mapping resources and the first authentication key to the same process identifier associated with the first and second endpoints.

[0068] In another variation, the resource includes a receive buffer for the first endpoint. The system verifies the second endpoint's access to the receive buffer by performing a lookup of the first authentication key in the CAM as the associated authentication key for the receive buffer. The system configures the second endpoint's access to the receive buffer by allocating the receive buffer and allowing the second endpoint to access it. The system inserts a first request into the receive buffer. The system performs the action indicated in the first request by retrieving the first request from the receive buffer.

[0069] In another variant, the receive buffer is associated with at least one of the following: a single authentication key; multiple authentication keys; or any authentication key based on a wildcard handle.

[0070] In another variant, the resource includes a first memory region associated with the first endpoint. The system further configures access to the resource by mapping the resource to a first authentication key and a remote access key. The system further programs the CAM by mapping the resource to the first authentication key and the remote access key within the CAM.

[0071] In another variant, the system verifies the second endpoint's access to the first memory region by performing a lookup of the first authentication key in the CAM as the associated authentication key for the first memory region. The system obtains a remote access key based on the lookup in the CAM. The system configures the second endpoint's access to the first memory region by allocating the first memory region and allowing the second endpoint to access it. The system returns the remote access key to the second endpoint. The system receives a Remote Direct Memory Access (RDMA) request, including the remote access key, from the second endpoint via the first endpoint. The system allows the second endpoint to access the allocated first memory region by using the remote access key included in the RDMA request.

[0072] In another variation, the first endpoint is associated with the server, and multiple endpoints are associated with the client.

[0073] In another variation, the transmission of data associated with the first request includes selecting the first authentication key obtained.

[0074] In another variation, the system transmits all data associated with the first request, wherein the data includes a notification to transmit the requested data.

[0075] In another variation, the system transmits all data associated with the first request. After transmitting all data associated with the first request, the system transmits a close response message indicating that the requested data has been transmitted.

[0076] On the other hand, the computer system includes a processor and a storage device for storing instructions, which, when executed by the processor, include instructions for performing operations. These instructions are used to allow a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, wherein a corresponding endpoint among the multiple endpoints is associated with a corresponding authentication key. The instructions are further used to receive a first request from a second endpoint among the multiple endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The instructions are further used to verify the first authentication key by matching the first authentication key with one of the enabled authentication keys. The instructions are further used to perform the action indicated in the first request and, in response to performing the action, retrieve the first authentication key from a completion event queue. The instructions are further used to transmit data associated with the first request to the second endpoint based on the retrieved first authentication key. The computer system may include a content processing system that includes further instructions, such as instructions for performing the operations described herein, including instructions regarding: Figure 1 , Figure 3A and Figure 3B The environment; Figure 2 and 4 Communication and operation; Figure 5A , Figure 5B and Figure 5C The operations depicted in the flowchart; and Figure 7 The instructions in the computer-readable medium 700.

[0077] On the other hand, a non-transitory computer-readable storage medium (CRM) stores instructions for allowing a first endpoint to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys by the first endpoint, each of the multiple endpoints being associated with a corresponding authentication key. The instructions are further configured to have the first endpoint receive a first request from a second endpoint of the multiple endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The instructions are further configured to verify the first authentication key by matching it against one of the enabled authentication keys. The instructions are further configured to perform the action indicated in the first request and, in response to performing the action, retrieve the first authentication key from a completion event queue. The instructions are further configured to transmit the data associated with the first request to the second endpoint based on the retrieved first authentication key. The CRM may also store instructions for performing the operations described above with respect to the following: Figure 1 , Figure 3A and Figure 3B The environment; Figure 2 and Figure 4 Communication and operation; Figure 5A , Figure 5B and Figure 5CThe operations depicted in the flowchart; and Figure 6 Instructions for the content processing system 618 in the middle.

[0078] The above description is presented to enable any person skilled in the art to implement and use the aspects and examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described herein are not limited to those shown, but should be given the broadest scope consistent with the principles and features disclosed herein.

[0079] Furthermore, the descriptions of the foregoing aspects are presented for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Moreover, the foregoing disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A method comprising: The first endpoint is allowed to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, wherein each of the multiple endpoints is associated with a corresponding authentication key; The first endpoint receives a first request from a second endpoint among the plurality of endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The first authentication key is verified by matching the first authentication key with one of the enabled authentication keys; Perform the action indicated in the first request; In response to performing the action, the first authentication key is returned to the completion event queue; Retrieve the first authentication key from the completion event queue; as well as The data associated with the first request will be transmitted to the second endpoint based on the obtained first authentication key.

2. The method as described in claim 1, wherein, Enabling the multiple authentication keys includes: The authentication key is mapped to the corresponding handle by the first endpoint; and The ternary content addressable memory (TCAM) is programmed using the authentication key.

3. The method as described in claim 2, wherein, The first authentication key included in the first request includes a handle, and the method further includes: The first authentication key is further verified by performing a lookup in the TCAM based on the handle of the first authentication key.

4. The method of claim 1, further comprising: Access to the resource is configured by the first endpoint by mapping the resource to one or more associated authentication keys; as well as The CAM is programmed by mapping the resource to the associated authentication key in the content addressable memory (CAM).

5. The method as described in claim 4, The CAM is further programmed by mapping the resources and the first authentication key to the same process identifier associated with the first endpoint and the second endpoint.

6. The method of claim 4, wherein, The resource includes the receive buffer of the first endpoint, and the method further includes: Access to the receive buffer by the second endpoint is verified by performing a lookup of the first authentication key in the CAM as the associated authentication key for the receive buffer; Access to the receive buffer by the second endpoint is configured by allocating the receive buffer and allowing the second endpoint to access the receive buffer; Insert the first request into the receive buffer; and The action indicated in the first request is performed by retrieving the first request from the receive buffer.

7. The method of claim 6, wherein, The receive buffer is associated with at least one of the following: Single authentication key; Multiple authentication keys; or Any authentication key based on a wildcard handle.

8. The method of claim 4, wherein, The resource includes a first memory region associated with the first endpoint, and the method further includes: Access to the resource is further configured by mapping the resource to the first authentication key and the remote access key; and The CAM is further programmed by mapping the resources to the first authentication key and the remote access key in the CAM.

9. The method of claim 8, further comprising: Access to the first memory region by the second endpoint is verified by performing a lookup of the first authentication key in the CAM as the associated authentication key for the first memory region. The remote access key is obtained based on a lookup in the CAM. Access to the first memory region by the second endpoint is configured by allocating the first memory region and allowing the second endpoint to access the first memory region. Return the remote access key to the second endpoint; The first endpoint receives a remote direct memory access (RDMA) request, including the remote access key, from the second endpoint; as well as The second endpoint is allowed to access the allocated first memory region by using the remote access key included in the RDMA request.

10. The method as described in claim 1, in, The first endpoint is associated with the server, and The multiple endpoints are associated with the client.

11. The method as described in claim 1, in, Transmitting the data associated with the first request includes selecting the acquired first authentication key.

12. The method of claim 1, further comprising: Transmit all data associated with the first request, wherein the data includes a notification that the requested data has been transmitted.

13. The method of claim 1, further comprising: Transmit all data associated with the first request; as well as After transmitting all data associated with the first request, a close response message indicating that the requested data has been transmitted is transmitted.

14. A computer system, the computer system including a first endpoint and further including: processor; as well as A storage device for storing instructions, which, when executed by the processor, include instructions for performing the following operations: The first endpoint is allowed to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, wherein each of the multiple endpoints is associated with a corresponding authentication key; Receive a first request from the second endpoint of the plurality of endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint; The first authentication key is verified by matching the first authentication key with one of the enabled authentication keys; Perform the action indicated in the first request; In response to performing the action, the first authentication key is retrieved from the completion event queue; and The data associated with the first request will be transmitted to the second endpoint based on the obtained first authentication key.

15. The computer system of claim 14, wherein, The instruction to enable the plurality of authentication keys is further used for: Map the authentication key to the corresponding handle; and The ternary content-addressable memory (TCAM) of the first endpoint is programmed using the authentication key. Wherein, the first authentication key included in the first request includes a handle, and The instructions for verifying the first authentication key are further used to perform a lookup in the TCAM based on the handle of the first authentication key.

16. The computer system of claim 14, wherein the instructions are further configured to: Access to the resource is configured by mapping the resource to one or more associated authentication keys, and optionally to remote access keys corresponding to the memory region resource; and The CAM is programmed by mapping the resource in the content-addressable memory (CAM) to the associated authentication key and optionally to the remote access key; in, After receiving the first request and verifying the first authentication key by matching it with one of the enabled authentication keys, the instruction is further configured to verify the first authentication key based on access to the configuration of the resource in the CAM.

17. The computer system as described in claim 16, in, The resources include a receive buffer associated with at least one of a single authentication key, multiple authentication keys, or any authentication key based on a wildcard handle, and The instructions are further used for: Access to the receive buffer by the second endpoint is configured by allocating the receive buffer and allowing the second endpoint to access the receive buffer; and The first request is inserted into the receive buffer, wherein the instructions for performing the action indicated in the first request are further used to retrieve the first request from the receive buffer.

18. The computer system as described in claim 16, in, The resource includes a first memory region associated with the first endpoint. The instruction for verifying the first authentication key based on access to the configuration of the resource in the CAM is further configured to perform a lookup of the first authentication key as an associated authentication key for the first memory region in the CAM. The instructions are further used for: The remote access key is obtained based on a lookup in the CAM. Access to the first memory region by the second endpoint is configured by allocating the first memory region and allowing the second endpoint to access the first memory region. The remote access key obtained from the lookup in the CAM is returned to the second endpoint; Receive a Remote Direct Memory Access (RDMA) request including the remote access key from the second endpoint; and The second endpoint is allowed to access the allocated first memory region by using the remote access key included in the RDMA request.

19. A non-transitory computer-readable medium storing instructions, the instructions being used for: The first endpoint is allowed to communicate with multiple endpoints in a connectionless network environment by enabling multiple authentication keys, wherein each of the multiple endpoints is associated with a corresponding authentication key; The first endpoint receives a first request from a second endpoint among the plurality of endpoints, including an action, a remote procedure call, and a first authentication key associated with the second endpoint. The first authentication key is verified by matching the first authentication key with one of the enabled authentication keys; Perform the action indicated in the first request; In response to performing the action, the first authentication key is retrieved from the completion event queue; as well as The data associated with the first request will be transmitted to the second endpoint based on the obtained first authentication key.

20. The non-transitory storage medium of claim 19, wherein the instruction is further configured to: The ternary content-addressable memory (TCAM) is programmed using the authentication key; The first authentication key is further verified by performing a lookup in the TCAM based on the handle of the first authentication key; Access to the resource is configured by mapping the resource to one or more associated authentication keys and optionally to remote access keys corresponding to memory regions; The CAM is programmed by mapping the resource in the content-addressable memory (CAM) to the associated authentication key and optionally to the remote access key; After verifying the first authentication key by performing a lookup in the TCAM, the first authentication key is further verified by performing a lookup in the CAM based on the access configuration to the resource. as well as Access to the resource by the second endpoint is configured by allocating the resource and allowing the second endpoint to access the resource. The resources include at least one of a receive buffer and a memory region, and Wherein, in response to the resource including the memory region, the instruction is further configured to: The remote access key is obtained based on a lookup in the CAM. Return the obtained remote access key to the second endpoint; Receive a Remote Direct Memory Access (RDMA) request including the remote access key from the second endpoint; and The second endpoint is allowed to access the memory region by using the remote access key included in the RDMA request.

Images