Method and system for scalable reliable connection transmission for RDMA

Abstract

The invention relates to a method and system for scalable reliable connection transmission for RDMA. In some embodiments, a system may include one or more processors coupled to a memory, the processors configured to set a shared transmit queue (SSQ) pool in the memory, each SSQ in the SSQ pool configured to serve as a transmit queue (SQ) for one or more queue-to-QPs. The one or more processors may assign at least one of SSQs from the pool of SSQs to the QP, the SSQs being set for a process having a plurality of connections to a plurality of remote processes. The one or more processors may send outgoing messages over the SSQ to individual ones of the plurality of remote processes via the plurality of connections. Moreover, the system may include embodiments in which the pool is set in response to the first number of QPs reaching a threshold. Systems may include embodiments in which a pool of SSQs is pinned in memory.

Description

Technical Field

[0001] The present disclosure relates generally to the field of Remote Direct Memory Access (RDMA) and more particularly to transferring data using queue pairs (QPs). Background Art

[0002] Typically, a high-performance transport service using the InfiniBand protocol and RDMA over Ethernet (ROCE) is a reliable connection (RC). One of the obstacles to using RC transport is the high memory footprint. The high memory footprint reduces the ability of services to scale to serve large clusters of computing devices using RC. Summary of the invention

[0003] Scalable RC (SRC) can reduce memory footprint and retain most RC features.One or more computer programs can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions.

[0004] In one general aspect, a system may include one or more processors coupled to a memory, the processors configured to set up a pool of shared send queues (SSQs) in the memory, each SSQ in the pool of SSQs configured to serve as a send queue (SQ) for one or more queue pairs (QPs). The one or more processors may be configured to assign at least one of the SSQs from the pool of SSQs to the QP, the SSQ being set up for a process having multiple connections to multiple remote processes. The one or more processors may be configured to send an outgoing message to a separate remote process in the multiple remote processes via the multiple connections through the SSQ. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of a method.

[0005] Implementations may include one or more of the following features. The system may include an implementation in which the pool is set in response to the first number of QPs reaching a threshold. The system may include an implementation in which the pool of SSQs is pinned in the memory. The system may include an implementation in which the SSQ is used as an SQ for at least one QP rather than an individual SQ for each QP. The system may include an implementation in which the system uses a pool of incoming read request queues (IRRQs) and the SSQs use corresponding outgoing read request queues (ORRQs). The system may include an implementation in which the QP is set with a pointer to the SSQ in the SSQ pool. The system may include an implementation in which the SSQ is released by the QP in response to identifying that the SQ for the QP is empty. Implementations of the described techniques may include hardware, methods or processes, or computer tangible media.

[0006] In one general aspect, a system may include one or more processors coupled to a memory. The one or more processors may be configured to set a first QP of a plurality of queue pairs (QPs) in response to a first process in a user space, a first set of resources of the first QP allocated from the memory being located in a kernel space. The one or more processors may be configured to set a second QP of the plurality of QPs in response to a second process in the user space, a second set of resources of the second QP allocated from the memory being located in the kernel space. The one or more processors may be configured to set a pool having a shared send queue (SSQ), wherein the SSQ is shared by the first QP and the second QP. The system may include an implementation in which the SSQ is released in response to the number of the plurality of QPs reaching a first threshold. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of a method.

[0007] Implementations may include one or more of the following features. The system may include implementations in which a send queue (SQ) of one of the first QP or the second QP is pinned in the user space of the memory. The system may include implementations in which a QP context of one of the first QP or the second QP is pinned in the kernel space of the memory. The system may include implementations in which QP information is located in a swappable portion of one of the user space or the kernel space of the memory. The system may include implementations in which the pool is set in response to a second number of the plurality of QPs being set reaching a second threshold. The system may include implementations in which the system uses a pool of incoming read request queues (IRRQs) and the SSQ uses a corresponding outgoing read request queue (ORRQ). Implementations of the described techniques may include hardware, methods or processes, or computer tangible media.

[0008] In one general aspect, a method may include setting up, by one or more processors, a pool of shared send queues (SSQs) in a memory, wherein each SSQ in the pool of SSQs may be used as a send queue (SQ) for one or more queue pairs (QPs). The method may also include allocating, by the one or more processors, at least one of the SSQs from the pool of SSQs to the QP, wherein the SSQ may be set up for a process having multiple connections to multiple remote processes. Furthermore, the method may include sending, by the SSQ, an outgoing message to a separate remote process in the multiple remote processes via the multiple connections. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of a method.

[0009] Implementations may include one or more of the following features. The method may include setting the pool in response to the first number of the QPs reaching a threshold. The method may include an implementation in which the pool of SSQs is pinned in the memory. The method may include an implementation in which the SSQ is used as the SQ for at least one QP rather than an individual SQ for each QP. The method may include an implementation in which the system uses a pool of incoming read request queues (IRRQs) and the SSQs use corresponding outgoing read request queues (ORRQs). The method may include an implementation in which the QP is set with a pointer to the SSQ in the pool of SSQs. The method may include an implementation in which the SSQ is released by the QP in response to identifying that the SQ for the QP is empty. Implementations of the described techniques may include hardware, methods or processes, or computer tangible media. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a diagram depicting the structure of a queue pair (QP) according to some embodiments.

[0011] Figure 2 is a block diagram depicting a computer networking system having a network system with a remote direct memory access (RDMA) communication network according to some embodiments.

[0012] Figure 3 is a diagram depicting an RDMA system according to some embodiments.

[0013] Figure 4 is an architectural diagram of an RDMA system according to some embodiments.

[0014] Figure 5 is an architectural diagram of an RDMA network computer system according to some embodiments.

[0015] Figure 6 is a flow chart of a method to handle a work request (WR) from an application, check if a free shared send queue (SSQ) is available, and post the WR to the SSQ or store the WR until a free SSQ is available, according to some embodiments.

[0016] Figure 7 is a flow chart of a method to issue a WR previously stored in a shadow queue to a newly allocated SSQ according to some embodiments.

[0017] Figure 8 is a flow chart of a method for releasing an SSQ to a free pool, checking whether there are connections waiting for SSQ resources, and initiating allocation of the SSQ to the next QP of the waiting connection when there are connections waiting for SSQ resources, according to some embodiments.

[0018] Fig. 9 is a flow chart of a method for establishing a pool of SSQs in memory, assigning SSQs to one or more QPs, and sending outgoing messages according to some embodiments. DETAILED DESCRIPTION

[0019] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific examples of components and arrangements are described below to simplify the disclosure. These are merely examples and are not intended to be limiting. In addition, in various examples, the disclosure may repeat reference numbers and letters. This repetition is for simplicity and clarity and does not in itself indicate the relationship between the various embodiments and configurations discussed.

[0020] Typically, when utilizing a reliable connection (RC) service, each process creates a separate reliable connection for each remote process with which the process establishes a connection. Because the RC service is reliable, each RC connection context contains information related to ordering, completion, or retransmission. Reliability contexts are required on both ends of the RC. A queue pair (QP) refers to a pair of queues used to transmit messages between endpoints in networking. A QP includes a send queue and a receive queue. The send queue (SQ) holds messages waiting to be transmitted. The receive queue (RQ) holds received messages. Pinning resources in memory refers to keeping certain data or executable code locked in RAM so that the pinned resources cannot be paged out to disk. For example, pinned memory can be locked. When an RC QP is created, space (e.g., 512B) is reserved in the kernel pinned memory for the QP context.

[0021] The RDMA system may have an outgoing read request queue (ORRQ) and an incoming read request queue (IRRQ). The ORRQ is a queue responsible for managing and queuing read requests initiated by a device. When a process or application running on a device requests to read data from another device memory, the process or application places the request in the ORRQ. The IRRQ is a queue that can track incoming RDMA read request messages for RDMA connections. When the QP supports read or atomic operations, the IRRQ and ORRQ, each with at least 4kB, can be pinned in the kernel.

[0022] The IRRQ holds read requests received by the RDMA Network Interface Controller (RNIC, which is sometimes collectively referred to herein as a Network Interface Controller (NIC)). When a remote host system needs to read data from a local host system, it sends a read request that is added to the IRRQ. The local RNIC services these requests by extracting the data from the local host memory and sending it back to the remote host. The ORRQ holds read requests that need to be sent from a local process to a remote host system. Read response packets are sent from the remote host and stored by the RNIC in the local host memory at the address specified in the read request.

[0023] User space refers to the storage area in which regular user programs and applications run, such as the space in which user-mode applications execute. Kernel space refers to the privileged memory area in which core kernel code, kernel extensions, drivers, and / or kernel processes run. RQ memory can be allocated, pinned, and mapped to user space (which is reserved for a specific process), and some receive work queue elements (WQEs) (such as buffers) can be posted to the queue. SQ memory can be allocated, pinned, and mapped to user space. When an application needs to communicate with a peer process and post a work request (WR), an SQ can be used. When an SQ or RQ has a relatively small number of WQEs, a single RC QP with an RQ can occupy at least 36kB of pinned memory per QP. If the size of the SQ or RQ increases, the number of WQEs of the SQ or RQ can increase.

[0024] When creating an RC QP with a peer, the above structures (e.g., SQ and RQ) are allocated and the system may consume host memory of a fixed size SQ or RQ depending on the application. When a QP is not in use, the QP is usually not destroyed because the QP can be used the next time the QP is needed. The operations of destroying and creating QPs are computationally intensive, take a long time, and may involve a lot of CPU resources and context switches between kernel and user space on both ends of the RC communication. For example, applications such as the message passing interface (MPI) limit the total number of RC QPs they create because QPs consume a lot of CPU memory. When an RC QP is created, the amount of memory allocated for the RC QP is fixed regardless of how often the QP is used.

[0025] Typically, unreliable datagrams (UD) may have a more scalable service than RC and require only a single QP per process. A single QP may communicate with any other process in the cluster. The WR of a UD QP may specify a destination address and a remote QP identification or index. UD services are unreliable and do not wait for confirmation notifications to maintain progress information, progress is made when the device handles the transmission message. UD may support messages with a single packet size. Applications using UD QP need to manage reliability to ensure that messages sent to peers are received. The size of the host memory for UD QP is relatively small. When a process sends a large message, the application needs to split the send message into multiple WQEs, each of which has a single maximum transmission unit (MTU) size. MTU is a property of the link layer that specifies the maximum allowed packet size. When a process sends a message to multiple destination processes, the message may be serialized unless segmentation or fragmentation is performed in an interleaved manner between the messages.

[0026] Extended Reliable Connection (XRC) may refer to an extended type of RC. XRC may reduce the number of resources required for communication. XRC uses a shared receive queue (SRQ) instead of an RQ. SRQ may refer to a hardware queue implemented in a network controller or adapter that enables incoming network packets to be distributed across multiple protocol processing threads or CPU cores. SRQ may be a message queue that allows multiple receiving processes to pop (or read) messages from it. The term "pop" may indicate extracting an element from, for example, a queue. When utilizing SRQ, all nodes may use the same queue to receive messages. Using a shared queue may simplify the architecture and reduce the number of required queues. A subscriber is an application that is interested in receiving messages from a shared queue. Multiple recipients may subscribe to a shared queue instead of several individual queues.

[0027] XRC splits the QP context into two parts: Initiator QP (INIQP) and Target QP (TGTQP). Each local process has an INIQP associated with each destination node (not each destination process in RC). The process publishes a WR on the INIQP. The WR specifies the TGTQP on the remote node. The reliability context on both ends is maintained in the INIQP and TGTQP. There is a TGTQP for the source process and each source node in the system. If N represents the number of nodes and P represents the number of processes, then on each node, there are N*P number of INIQPs for N*P number of destination processes and N*P number of TGTQPs for N*P number of source processes. In contrast, the number of QPs with RC service is N*P. 2 With such queues in XRC, a process communicating with more than one remote process on the same node serializes the transfers toward the remote processes. XRC can support the operations supported in RC.

[0028] In general, dynamic connections (DC) provide all operations supported in RC and have extensions similar to UD services. For example, there is only a single INIQP per local process to send messages to all other processes on the system, and there is only a single TGTQP per local process to receive messages from any process on the system. DC can use SRQ instead of RQ, one SRQ per process. Because DC does not maintain reliability contexts for all possible connections, each time a process begins communicating with a remote process, both ends establish a new reliability context using sequencing information. Sending messages from one process to multiple processes is serialized in DC. When switching between messages with destinations to different peers (e.g., message A for process n and message B for process m), an acknowledgment notification for message A is received before starting to transmit message B. Each node in DC has at least one global responder to respond to connection requests because a busy TGTQP may currently be responding to an existing connection. DC can use a concurrency higher than one (1), for example, a process can create more than one INIQP and a process can concurrently manage sending messages to more than one destination process to reduce the degree of serialization. Because there is only one TGTQP per process, when the TGTQP is connected, messages from some peers may be delayed due to connection requests being rejected.

[0029] DC can be effectively expanded because DC consumes few connection resources. DC has relatively good performance because DC does not experience cache thrashing. Cache thrashing is characterized by frequent and inefficient exchange of data within the cache memory of a computer system, which causes system performance degradation. Similar to XRC, DC experiences serialization, blocking by large messages, and delaying the delivery of subsequent messages due to congestion toward the destination of the current message. DC connects, disconnects, and waits for confirmation about the current message before switching to another destination. For example, a large read operation can be performed from one destination, followed by a write operation to another destination. The write operation is not performed until the response to the large read operation is completed. Slow or busy read responders can cause further delays. When a process sends requests to multiple processes, DC may be penalized for switching between destinations, and the smaller the message size, the higher this penalty may be.

[0030] Typically, Scalable RC (SRC) employs a dynamic association of resources to QPs. For example, when using SRC, a small set of global resources is pinned and statically allocated. However, a large number of connections (e.g., QPs) use such global resources as needed. A reliability context for the SRC configuration is maintained for each peer process and the total number of QP contexts is essentially the same as in the RC configuration. If N represents the number of nodes and P represents the number of processes, then SRC requires 512B per QP and is N*P 2The other data structures are not allocated per QP, and they grow on the order of one (1) (e.g., a constant) for IRRQ and ORRQ and on the order of P for SQ. One SRQ can be used per process, so the number of RQs can be reduced to the order of P. One Completion Queue (CQ) can be used per process to complete all SQs. Since the CQ is used for completions from multiple QPs, the size of the CQ can be larger than when a CQ is used per QP. The application controls the size of the CQ and can also adjust the size of the CQ as needed. For example, Open (For example, Open Source provided by Software in the Public Interest, a New York-based company ) performs such operations. When a process transmits towards a destination process and issues a WR, the SSQ may be used. The user library allocates a limited number of pinned resources of the SSQ per process and uses them as needed for QPs that have transmit work to perform. When a QP has no outstanding WQEs, the resources may be released. The term "allocation" may refer to the process of setting aside or assigning resources (such as memory, CPU time, storage, or network bandwidth) to a specific task, process, or component within the system. The term "release" refers to the action of making previously allocated or reserved resources available for use by other processes or applications. For example, releasing resources may involve freeing up resources so that the resources are no longer dedicated to a specific task or program, but can be used by other processes as needed.

[0031] The allocated resource pool in a QP may refer to a set of resources available for use by a QP. A global pool of IRRQ entries may be allocated (where each entry holds an incoming read request) and used as needed. When a process submits a WR to a connection (e.g., a QP) with a peer, an ORRQ is allocated along with the SSQ. The user library creates a pinned ORRQ for each SSQ created by the user library. When an SSQ is allocated to a QP, an ORRQ is allocated to the QP. When a read or atomic request is received, an IRRQ entry is required. The RNIC hardware allocates an IRRQ entry from the pool and stores the read or atomic information in the IRRQ. The RNIC may use this information to transmit a response to a storage request. If no IRRQ entry is available, a negative acknowledgement (NAK) of receiver not ready (RNR) is sent in response to an incoming read or atomic request. The requester may handle the RNR in a manner similar to that of handling a RNR for a send request. For example, a retransmission may be issued after waiting for the time specified in the RNR NAK. After sending responses to all requests, the RNIC may release the IRRQ entry back to the pool.

[0032] Swappable resources refer to a portion of data or code that can be moved in and out of physical memory (such as RAM) and secondary storage devices (such as hard disk drives (HDDs) or solid-state drives (SSDs)) as needed. When a program needs to access a specific resource and the resource is not currently in physical memory, the operating system (OS) can swap out some other less used resources from physical memory to make room for the required resource. The swapped out resources can be temporarily stored in secondary storage devices while the required resources are brought into physical memory. The swapping process allows the system to handle more data and code than the physical memory can accommodate.

[0033] Reference Figure 1 , illustrates a diagram depicting the structure of a QP 156. A QP 156 may refer to a data structure used to facilitate communication between processes, such as in an InfiniBand network. A QP 156 may include two queues: a send queue (SQ) 157 and a receive queue (RQ) 158. A QP 156 may be created on each node that communicates with other nodes. A QP 156 allows a process on one node to send and receive messages to and from a process on another node. When an application communicates, the application posts a work request (WR) to the SQ 157 or RQ 158 of its local QP 156. For example, the InfiniBand hardware may handle transferring messages between connected QPs 156.

[0034] The QP 156 may include the following associated components: SQ 157, RQ 158, and Completion Queue (CQ). In some embodiments, the QP 156 may include IRRQ 152 and ORRQ 154. The QP context (QPC) may have various information, such as the destination QP 156, the destination IP address, sequence number, and related communication status, and pointers to the above components. The term "pointer" may refer to a data type used to store a memory address. A pointer may be a variable that "points" to a location in computer memory to provide access to and operate with data stored at that location. Pointers may be used for various tasks, including dynamic memory allocation, data structures, and memory management.

[0035] SQ 157 holds work requests that are transformed into WQEs by user library software to send messages to the remote end of QP 156. The send queue may include send WRs, RDMA read WRs, and RDMA write WRs. RQ 158 holds receive work queue elements that are used when a send message has been received from the remote end of QP 156. Completion Queue Elements (CQEs) are data structures with information about completed work requests, for example, CQ elements may include status information. CQ elements are placed on CQs.

[0036] In some embodiments, active or operational QP 156 may include the following resources pinned in the memory of the computing system: send queue page buffer list (SQ PBL) 153 and SQ 157 including send WQEs, receive queue page buffer list (RQ PBR) 155 and RQ 158 including receive WQEs, IRRQ 152 and ORRQ 154. Other QP data structures used by device drivers and user library software (not shown) can be moved in and out of physical memory and auxiliary storage devices (e.g., sometimes referred to as swap). The page buffer list refers to an array of pointers to memory pages used to store send and receive WQEs. Typically, pages are pre-allocated and pinned by the device driver so that the device (e.g., hardware) can access the pages. WQEs have pointers to buffers that contain application data to be sent or memory locations to store incoming messages. The network adapter can later retrieve from or write to these buffers for transmission and reception, respectively.

[0037] Reference Figure 2 , a block diagram illustrates a computer networking system having a network system 210 having an RDMA communication network 290 according to some embodiments. One or more remote client computers 282A to 282N may be communicatively coupled to one or more servers 200A to 200B of the network system 210 via a local area network (LAN) 280.

[0038] The term "coupled" and its variations include two components being directly or indirectly joined to each other. The term "electrically coupled" and its variations include two components being directly or indirectly joined to each other through a conductive material (e.g., a metal or copper trace). This joining may be static (e.g., permanent or fixed) or movable (e.g., removable or releasable). This joining may be achieved by: two components being directly coupled to each other; two components being coupled to each other using a separate intermediary component and any additional intermediate components that are coupled to each other; or two components being coupled to each other using an intermediary component that is integrally formed as a single entity with one of the two components. If "coupled" or its variations are modified by additional terms (e.g., directly coupled), the general definition of "coupled" provided above is modified by the colloquial language meaning of the additional terms (e.g., "directly coupled" means that the two components are joined without any separate intermediary components), resulting in a narrower definition than the general definition of "coupled" provided above. This coupling may be mechanical, electrical, or fluidic.

[0039] The network system 210 includes one or more server devices 200A-200B and one or more NDs 292A-292D that are communicatively coupled together through an RDMA communication network 290. RDMA message packets are communicated via wires or cables of the RDMA communication network 290, the one or more server devices 200A-200B, and the one or more NDs 292A-292D. To support the communication of RDMA message packets, the one or more servers 200A-200B may each include one or more RDMA network interface controllers (RNICs or sometimes collectively referred to as network interface controllers (NICs)) 211A-211D (sometimes referred to as RDMA host channel adapters), also referred to herein as a network communication computer system 211.

[0040] Reference Figure 3 , a block diagram illustrating an RDMA system 200 that may be exemplified as a server device 200A to 200B of a network system 210 according to some embodiments. In some embodiments, the RDMA system 200 is a server device. In some embodiments, the RDMA system 200 may be any other suitable type of RDMA system, such as, for example, a client device, a network device, a storage device, a smart appliance, a sensor device, a vehicle, and the like. The client device may include, for example, a personal computer, a laptop computer, a tablet computer, a smart phone, and the like. The network device may include, for example, a router, a switch, a firewall, an access point, a modem, an Ethernet card, a load balancer, a domain name system (DNS) server, and the like. The storage device may include, for example, a hard disk drive (HDD), a solid state drive (SSD), a hybrid drive, a network attached storage device (NAS), an optical disk, a redundant array of independent disks (RAID), a storage area network (SAN), a memory card, and the like. The smart appliance may include, for example, a smart thermostat, a smart speaker, a smart lock, a smart light, a smart TV, and the like. The sensor device may include, for example, a temperature sensor, a motion sensor, a proximity sensor, a light sensor, a global positioning system (GPS) sensor, and the like.

[0041] The RDMA system 200 is an RDMA-enabled information processing device that is configured for RDMA communication to transmit and receive RDMA message packets. The RDMA system is designed, implemented and / or configured to communicate messages using any type and form of RMDA protocol (e.g., any standardized RMDA protocol specification and any extensions thereof). The RMDA system is designed / implemented and / or configured to provide read and write services for data transfer to and from applications.

[0042] The RDMA system 200 includes a plurality of processors 201A to 201N communicatively coupled together, a network communication computer system 211, and a main memory 222. Any of the processors 201A to 201N may execute instructions of an operating system (OS) 212, an application 213, an operating system API 214, a user RDMA Verbs API 215, and an RDMA user mode library 216 (user mode module). The OS 212 includes software instructions of an OS kernel 217, an RDMA kernel driver 218, a kernel RDMA application 296, and a kernel RDMAverbs API 297.

[0043] Main memory 222 includes application address space 230 and computer system address space 295. Application address space 230 is accessible by user space processes. Computer system address space 295 is accessible by user space and kernel space processes and computer system firmware module 220.

[0044] The application address space 230 includes buffers 231-234 used for RDMA transactions by the application 213. The buffers include a send buffer 231, a write buffer 232, a read buffer 233, and a receive buffer 234.

[0045] Figure 3 256. For example, RDMA system 200 includes two queue pairs: QP 256a and QP 256n, which are generally referred to as QP 256. In some embodiments, another number of QPs may be used in RDMA system 200, such as more than two QPs or less than two QPs. Figure 3 A certain number of QPs is illustrated, but implementations may use any number of QPs, including a much larger number of QPs than shown. QPs 256a and 256n may be similar in some aspects to Figure 1 256. Thus, similar features may be designated by similar reference numerals, with the leading numerals incremented by "2". Thus, the relevant disclosure set forth above with respect to similarly identified features may not be repeated below. Additionally, specific features of QP 256 may not be shown or identified with reference numerals in the drawings or specifically discussed in the following written description. However, such features may be significantly the same or substantially the same as features depicted in other embodiments of QP 156 or described with respect to such embodiments of QP 156. Thus, the relevant description of such features is equally applicable to features of QP 256. Any suitable combination of features described with respect to QP 156 and variations thereof may be employed with QP 256, and vice versa. This disclosure mode is equally applicable to further embodiments of QP 256 depicted in subsequent figures and described below.

[0046] Queue pair 256a includes a send queue 257a and a receive queue 258a. In some embodiments, an RDMA completion queue (CQ) 275 is used in conjunction with the send queue 257a and the receive queue 258a. Similarly, queue pair 256n includes a send queue 257n and a receive queue 258n.

[0047] In some embodiments, application 213 creates queue pair 256a and 256n by using RDMA verbs application programming interface (API) 215 and RDMA user mode library 216. During creation of queue pair 256a, RDMA user mode library 216 creates computer system send queue 257a and computer system receive queue 258a in computer system address space 295.

[0048] In some embodiments, RDMA verbs API 215, RDMA user mode library 216, RDMA kernel driver 218, kernel RDMA verbs API 297, and network device firmware module 220 provide RDMA functionality according to the InfiniBand Architecture (IBA) specification.

[0049] The RDMA verbs API 215 implements RDMA verbs, an interface for RDMA-enabled network interface controllers. RDMAverbs can be used by user space applications to invoke RDMA functionality. RDMA verbs typically provide access to RDMA queuing and memory management resources and the underlying network layer.

[0050] In some embodiments, the RDMA verbs provided by RDMA Verbs API 215 are RDMA verbs defined in the InfiniBand Architecture (IBA) specification. RDMA verbs may include the following verbs: create queue pair, modify queue pair, destroy queue pair, issue send request, and register memory region.

[0051] Figure 4 2 is an architecture diagram of an RDMA system 200 according to some embodiments. In some embodiments, the RDMA system 200 is a server device. The bus 301 and Figure 3The RDMA system 200 is connected to the processors 201A to 201N, the main memory 222 (such as random access memory (RAM)), the read-only memory (ROM) 304, the processor-readable storage medium 305, the display device 307, the user input device 308, and the network device 211. The processors 201A to 201N can take various forms, such as ARM processors, X86 processors, and the like. In some embodiments, the RDMA system 200 includes at least one of a central processing unit (CPU) and a multi-processor unit (MPU).

[0052] Processors 201A to 201N and main memory 222 form a host processing unit 399. In some embodiments, the host processing unit includes one or more processors communicatively coupled to one or more of RAM, ROM, and machine-readable storage media. In some embodiments, the one or more processors of the host processing unit receive instructions stored by one or more of RAM, ROM, and machine-readable storage media via a bus. In some embodiments, the one or more processors execute the received instructions. In some embodiments, the host processing unit is an application specific integrated circuit (ASIC) device. In some embodiments, the host processing unit is a system on chip (SOC) device. In some embodiments, the host processing unit includes one or more of RDMA kernel driver 218, kernel RDMA verbs API 297, kernel RDMA application 296, RDMA verbs API 215, and RDMA user mode library 216.

[0053] The network computer system 211 provides one or more wired or wireless interfaces for exchanging data and commands between the RDMA system 200 and other devices (e.g., remote RDMA systems). Such wired and wireless interfaces include, for example, Universal Serial Bus (USB) interfaces, Bluetooth interfaces, Wi-Fi interfaces, Ethernet interfaces, Near Field Communication (NFC) interfaces, and the like.

[0054] The machine-executable instructions in the software programs (e.g., OS 212, application programs 313, and device drivers 314) are loaded from the processor-readable storage medium 305, ROM 304, or any other storage location into the memory 222 (of the host processing unit 399). During the execution of these software programs, the corresponding machine-executable instructions are accessed by at least one of the processors 201A-201N (of the host processing unit 399) via the bus 301 and then executed by at least one of the processors 201A-201N. Data used by the software programs is also stored in the memory 222, and this data is accessed by at least one of the processors 201A-201N during the execution of the machine-executable instructions of the software programs.

[0055] The processor readable storage medium 305 may be one (or a combination of two or more) of a hard drive, a flash drive, a DVD, a CD, an optical disk, a floppy disk, a flash memory device, a solid state drive, a ROM, an EEPROM, an electronic circuit, a semiconductor memory device, and the like. The processor readable storage medium 305 includes Figure 3 The application 313, the device driver 314 and the OS 212, the application 213, the OS API 214, the RDMA verbs API 215 and the RDMA user mode library 216. The OS 212 includes Figure 3 OS kernel 217, RDMA kernel driver 218, kernel RDMA application 296 and kernel RDMA verbs API 297.

[0056] The RDMA kernel driver 218 includes a kernel driver that is executed by the host processing unit 399 to perform the following Figures 6 to 9 In some embodiments, the RDMA user mode library 216 includes instructions for executing by the host processing unit 399 to perform the following Figures 6 to 9 More specifically, the RDMA kernel driver 218 includes instructions for controlling the host processing unit 399 to provide computer system commands and in-band RDMA WQEs to the computer system 211.

[0057] As follows about Figure 5 1, the computer system firmware module 220 includes a control path module 498 that includes instructions for processing computer system commands provided by the host processing unit 399 to the computer system 211. The computer system commands are processed by the RDMA control path of the computer system 211. In some embodiments, the host processing unit 399 can provide the computer system commands to the computer system 211 regardless of the queue pair state of the queue pairs of the computer system 211.

[0058] The computer system firmware module 220 also includes a data path module 497, which includes a module for processing queue pairs (eg, Figure 3 The host processing unit 399 may provide an instruction to the RDMA WQE of the computer system 211 by executing one of the queue pairs 256a and 256n of the host processing unit 399. The RDMA WQE includes an in-band RDMA WQE generated by the host processing unit 399 executing instructions of an RDMA driver (e.g., one of the RDMA kernel driver 218 and the RDMA user mode library 216) and an instruction to the RDMA WQE generated by the host processing unit 399 executing an application (e.g., Figure 3 The application RDMA WQE is generated by an instruction from one of the application 213 and the kernel RDMA application 296).

[0059] In some embodiments, the in-band RDMA WQE includes data that can be processed by the RDMA data path of the computer system 211 to implement the configuration of the computer system 211. In some embodiments, the host processing unit 399 can provide the in-band WQE to the computer system 211 via a queue pair in one of the initialization (INIT) state, the ready to receive (RTR) state, and the ready to send (RTS) state. Similarly, the RDMA data path of the computer system 211 can process the in-band RDMA WQE received via the queue pair in one of the initialization (INIT) state, the ready to receive (RTR) state, and the ready to send (RTS) state. In some implementations, the host processing unit 399 cannot provide the in-band WQE to the computer system 211 via a queue pair in the RESET state.

[0060] In some embodiments, the RDMA user mode library 216 includes one or more of the instructions described above as being included in the RDMA kernel driver 218 .

[0061] Figure 5 An architectural diagram of an RDMA network computer system 211 of an RDMA system 200 is provided in FIG. In some embodiments, the RDMA network computer system 211 is a network communication computer system configured to be included in a server device. In some embodiments, an RDMA network device is a network communication computer system 211 configured to be included in one or more different types of RDMA systems (e.g., client devices, network devices, smart appliances, storage devices, sensor devices, vehicles, and the like).

[0062] The bus 401 interfaces with the processor 402 , the random access memory (RAM) 270 , the processor-readable storage medium 405 , the host bus interface 409 , and the network interface 460 .

[0063] Processor 402 may take many forms such as, for example, a central processing unit (CPU), a multi-processor unit (MPU), an ARM processor, and the like.

[0064] The processor 402 and the memory 270 form a computer system processing unit 499. In some embodiments, the computer system processing unit 499 includes one or more processors communicatively coupled to one or more of RAM, ROM, and machine-readable storage media. In some embodiments, the one or more processors of the computer system processing unit 499 receive instructions stored by one or more of RAM, ROM, and machine-readable storage media via a bus. In some embodiments, the one or more processors execute the received instructions. In some embodiments, the computer system processing unit 499 is an ASIC (Application Specific Integrated Circuit). In some embodiments, the computer system processing unit 499 is a SoC (System on Chip). In some embodiments, the computer system processing unit 499 includes a firmware module 220. In some embodiments, the computer system processing unit 499 includes an RDMA driver 422. In some embodiments, the computer system processing unit 499 includes one or more of a control path module 498 and a data path module 497. In some embodiments, the computer system processing unit 499 includes an RDMA stack 420. In some embodiments, the computer system processing unit 499 includes a software transmission interface 450.

[0065] The network interface 460 provides one or more wired or wireless interfaces for exchanging data and commands between the network communication computer system 211 and other devices (e.g., another network communication computer system). Such wired and wireless interfaces include, for example, a universal serial bus (USB) interface, a Bluetooth interface, a Wi-Fi interface, an Ethernet interface, a near field communication (NFC) interface, and the like.

[0066] The host bus interface 409 provides one or more wired or wireless interfaces for exchanging data and commands via the host bus 301 of the RDMA system 200. In some embodiments, the host bus interface 409 is a PCIe host bus interface.

[0067] The machine-executable instructions in the software programs are loaded from the processor-readable storage medium 405 or any other storage location into the memory 270 (of the computer system processing unit 499). During the execution of these software programs, the corresponding machine-executable instructions are accessed by the processor 402 (of the computer system processing unit 499) via the bus 401 and then executed by the processor 402. Data used by the software programs is also stored in the memory 270, and this data is accessed by the processor 402 during the execution of the machine-executable instructions of the software programs.

[0068] The processor readable storage medium 405 may be one of a hard drive, a flash drive, a DVD, a CD, an optical disk, a floppy disk, a flash storage device, a solid state drive, a ROM, an EEPROM, an electronic circuit, a semiconductor memory device, and the like (or a combination of two or more). The processor readable storage medium 405 includes a firmware module 220. The firmware module 220 includes a firmware module for executing the following instructions. Figures 6 to 9 Instructions that describe the process.

[0069] In some embodiments, the firmware module 220 includes a software transport interface 450, an RDMA stack 420, an RDMA driver 422, a TCP / IP stack 430, an Ethernet RNIC driver 432, a Fibre Channel (FC) stack 440, an FCoE (Fibre Channel over Ethernet) driver 442, an RNIC send queue processing module 461, and an RNIC receive queue processing module 462.

[0070] In some embodiments, the RDMA verbs are implemented in the software transport interface 450. In some embodiments, the RDMA protocol stack 420 is an InfiniBand protocol stack. In some embodiments, the RDMA stack 420 handles different protocol layers, such as transport, network, data link, and physical layers.

[0071] In some embodiments, the RDMA network device 211 is configured with full RDMA offload capability, which means that both the RDMA protocol stack 420 and the RDMAverbs (e.g., included in the software transport interface 450) are implemented in the hardware of the RDMA network device 211. In some embodiments, the RDMA network device 211 provides RDMA functionality using the RDMA protocol stack 420, the RDMA driver 422, and the software transport interface 450. The RDMA network device 211 provides Ethernet and TCP / IP functionality using the Ethernet RNIC driver 432 and the corresponding TCP / IP stack 430. The RDMA network device 211 provides Fibre Channel over Ethernet functionality using the Fibre Channel over Ethernet (FCoE) driver 442 and the corresponding Fibre Channel stack 440.

[0072] In operation, the RDMA network device 211 communicates with different protocol stacks through specific protocol drivers. In some embodiments, the RDMA network device 211 communicates by using an RDMA stack 420 in conjunction with an RDMA driver 422, by using a TCP / IP stack 430 in conjunction with an Ethernet RNIC driver 432, and by using a Fibre Channel stack 440 in conjunction with an Ethernet Fibre Channel (FCoE) driver 442.

[0073] In some implementations, the RDMA driver 422 includes a control path module 498 and a data path module 497. The control path module 498 includes instructions to process computer system commands 496 provided by the host processing unit 399 to the computer system 211. In some implementations, the control path module processes the computer system commands (control path commands) 496 by using control path hardware. In some implementations, the computer system 211 receives the computer system commands 496 from the host processing unit 399 via the host bus interface 409.

[0074] The control path module 498 includes instructions for processing the following: an "INIT state create queue pair" computer system command, which is used to create an RDMA queue pair 256 in an initialization (INIT) state; a "RESET state create queue pair" computer system command, which is used to create an RDMA queue pair 256 in a RESET state; an "INIT state queue pair state transition" computer system command, which is used to transition the RDMA queue pair 256 from the RESET state to the initialization state; an "RTS state queue pair state transition" computer system command, which is used to provide the RDMA transmission operation information and the RDMA reception operation information of the RDMA queue pair 256 from the host processing unit 399 to the computer system 211 and transition the RDMA queue pair 256 from the initialization state to the ready to send (RTS) state; an "RTR state queue pair state transition" computer system command, which is used to perform a RDMA transmission operation and an RDMA reception operation of the RDMA queue pair 256 from the host processing unit 399 to the computer system 211. Receive the RDMA receive operation information of the RDMA queue pair 256 and change the RDMA queue pair 256 from the initialized state to the ready to receive (RTR) state; a "recycling queue pair state change" computer system command, which is used to change the RDMA queue pair 256 from the ERROR state to the RESET state; a "recycling queue pair state change" computer system command, which is used to change the RDMA queue pair 256 from the ERROR state to the INIT state; a "ERROR queue pair state change" computer system command, which is used to change the RDMA queue pair 256 from the INIT state to the ERROR state; a "ERROR queue pair state change" computer system command, which is used to change the RDMA queue pair 256 from the RTR state to the ERROR state; a "ERROR queue pair state change" computer system command, which is used to change the RDMA queue pair 256 from the RTS state to the ERROR state.

[0075] The data path module 497 includes instructions for processing RDMA WQEs provided by the host processing unit 399 to the computer system 211 via the QP 256 of the computer system 211. The RDMA WQEs include in-band RDMA WQEs generated by the host processing unit 399 executing instructions of an RDMA kernel or user space driver 218 (e.g., one of the RDMA kernel driver 218 and the RDMA user mode library 216) and instructions generated by the host processing unit 399 executing an application (e.g., Figure 3 The computer system 211 may receive an application RDMA WQE from the host processing unit 399 via the host bus interface 409.

[0076] In some embodiments, the data path module handles RDMA WQE by using data path hardware. In some embodiments, the data path hardware is constructed to provide increased speed and performance via the data path rather than the control path.

[0077] Reference Figure 1 156. In some embodiments, the QP context may be split into two parts, each with a unique index: a scalable or shared SQ (SSQ) and a QP 156. A pool of SSQs may be set up in the memory of a computing system. The term "setup" may refer to the process of creating and initializing required communication structures and resources (e.g., SSQs or SSQ pools) for internal process or network communication, where internal process refers to communication and data exchange that occurs between different processes within a computing system.

[0078] In some embodiments, a first QP of the plurality of QPs may be set in response to a first process in user space, wherein a first set of resources of the first QP allocated from memory is located in kernel space. In some embodiments, a second QP of the plurality of QPs may be set in response to a second process in user space, wherein a second set of resources of the second QP allocated from memory is located in kernel space. In some embodiments, a pool including an SSQ may be set such that the SSQ is shared by the first QP and the second QP.

[0079] SSQ may be a finite resource with index SSQ_ID. SSQ context (SSQC) contains a pointer to the physical pinned memory where the WQE is issued. SSQ context contains reference ORRQ memory and its index. In some embodiments, when SSQ is allocated, ORRQ 154 is allocated.

[0080] In some embodiments, the QP context (QPC) may include other QPC elements, including reference destination address, destination QPN, reliability and congestion context, and SSQ index. IRRQ 152 may be one per read request, and IRRQ entries may be dynamically allocated as needed based on incoming reads or atomic operations.

[0081] According to some embodiments, from the perspective of verbs, there may be a QP number associated with the index of the QP (QP_ID). For example, Drivers (such as those supplied by Broadcom Corporation of Irvine, California) Drivers) and user libraries can control SSQs and attach SSQs to QP 156 as needed and detach SSQs when the SSQs are not in use.

[0082] In some embodiments, the user library may issue WQEs directly to the SSQ or may store work requests (WRs) issued by upper layers into a shadow SQ (eg, according to the software construct of QP 156) and later convert them to WQEs and issue them to the SSQ.

[0083] In some embodiments, the SSQ has a doorbell (DB) operation to update the producer index. The DB triggers the hardware to read the WQE from the SSQ. The SSQ may contain an "Attach WQE" command, which contains the QP_ID. When the hardware reads the "Attach WQE" command, it updates the QP_ID in the SSQC and the SSQ_ID in the QPC to indicate to reattach the SSQ to a new QP 156.

[0084] In some embodiments, the hardware uses a scheduling queue to schedule SSQs (rather than QP 156) for transmissions. The SSQ_ID and the last QP_ID associated with the SSQ_ID are stored in the scheduling queue element. When an SSQ is popped from the scheduling queue, both the SSQC and QPC are extracted. The WQE reads from the SSQ and if the WQE's QP_ID is different than the QP_ID stored in the transmission scheduler, the SSQ with the new QP_ID is pushed to the scheduling queue for future servicing. The term "push" may refer to adding an element to a queue, for example.

[0085] In some embodiments, there may be occasional delays in performing SSQ work when switching the index of the QP. Software manages a free pool of SSQs dedicated to each process. When an acknowledgment is received, the RNIC extracts the QPC and the currently associated SSQC to generate a completion of the WQE for the SSQ. As described herein, QP 156 and CONN may be used interchangeably and refer to an inter-process communication channel.

[0086] In some embodiments, when a process creates a QP 156, SQ 157, RQ 158, or SRQ, they are created on both peers. When executing in parallel on multiple processes, for example, in MPI, there is a state in the application where one process sends a message to another process. Two processes may reach this state in the application, where one process may publish a send buffer 231 and the other process may publish a receive buffer 234. In some embodiments, the sending process reaches the execution state before the receiving process, and the message may arrive at the receiving node before the receive buffer 234 is published. If the RQ buffer is not published in advance, the receiver may send an RNR that requires waiting time and retransmission. The receive buffer 234 may be published when the QP 156 is created, and when the RQ 158 approaches an empty state, more buffers may be published before it is used.

[0087] In some embodiments, there may be RQ resources that may have receive WQEs that require relatively large pinned memory when there are a large number of QPs 156. In some embodiments, to keep the memory footprint small, SRQs are used because RQs 158 cannot be global resources that are allocated as needed. In some embodiments, MPI and middleware libraries may use SRQs instead of RQs 158 to limit resource usage, and processes may post receive WQEs to SRQs in advance.

[0088] In some embodiments, the maximum number of IRRQ entries that a QP 156 can consume is the maximum outstanding reads allowed on the QP 156 (e.g., which are returned to the application query). A relatively small number of QPs 156 sending read requests to the RNIC can consume the entire pool of IRRQ entries. When the pool of IRRQ entries is exhausted, incoming read requests are responded to with RNR NAKs within a specified period of time that allows for retrying the read request. The RNIC throttles the RNR time based on the number of outstanding response bytes on the QP 156 associated with the incoming read request and the total number of QPs 156 waiting for IRRQ resources (e.g., the number of QPs 156 that responded with RNRs on read requests).

[0089] A first-in, first-out (FIFO) is a data structure whose operating principle is to maintain the order of elements based on the time of their arrival or insertion. In a FIFO structure, the element that was inserted or enqueued first is the element that will be removed or dequeued first. In some embodiments, to reduce unnecessary release of SSQ resources that may be needed again, the user library uses three FIFO structures: (i) an idle SSQ FIFO, which contains SSQ resources that are not attached to any QP 156; (ii) a pending QP FIFO, which contains QPs 156 to which WRs are posted but for which no SSQ resources are available; and (iii) a release candidate FIFO, which contains QPs 156 that have an allocated SSQ but have reached an empty SQ 157 at a particular time.

[0090] In some embodiments, the RNIC allocates SSQ resources for the first time when a WR is issued to a QP 156. When this SSQ assigned to this QP 156 becomes empty, the user library does not release the resources immediately after the last WQE that issued the QP 156 completes. The user library may add the QP 156 to a list of release candidates in the FIFO. The user library may update the QP information "qp_info" (e.g., information and attributes associated with the QP 156) to indicate that the QP 156 is located in the FIFO. More QPs 156 may be added to the FIFO release candidates. When the FIFO of release candidates contains more than the configured number of candidate QPs 156 (e.g., 16 QPs 156), each time a QP 156 reaches an empty SSQ state (e.g., calling the pollCq operation of the last WQE, see Figure 8 800 in FIFO), the user library may remove the first QP 156 from the candidate FIFO release. The user library may then check if the SSQ of the candidate QP 156 is still empty and if it is still empty, the user library may release the SSQ resources, push the SSQ resources to the free SSQ FIFO, and update "qp_info" to indicate that the QP 156 no longer owns the SSQ resources.

[0091] In some embodiments, the release candidate FIFO remains at or below a configured threshold (e.g., 16), and the resource is released and available for use after the threshold is reached. In some embodiments, when a candidate QP 156 is removed from the queue, the QP 156 may have new work and the SSQ of the QP 156 is not empty. No further operations are performed in this case. In effect, one QP 156 is popped (or pulled from the release candidate FIFO) and one QP 156 is pushed to the release candidate FIFO, and the resource may or may not be released.

[0092] In some embodiments, when all resources are consumed and more QPs 156 require SSQ resources, the user library may skip pushing QPs 156 to release candidate FIFOs and the user library may release resources to free FIFOs almost immediately. When a state is reached where all resources are consumed, the candidate FIFOs may be emptied first.

[0093] Reference is now made to the global pool of IRRQs 152. In some embodiments, configuration parameters determine the size of each ORRQ 154. The driver creates a pool for the configured number of IRRQ entries and sets a pointer to the pool in an RNIC register. In some embodiments, the RNIC manages the consumption of IRRQ entries and uses a content addressable memory (CAM) to locate the next entry to respond to when a QP responder is scheduled for transmission. The CAM lookup is based on the pfid, qpid, irrq_idx variables, where irrq_idx is the current producer index of the IRRQ 152 of the QP 156.

[0094] The system 200 may perform a read or atomic initiator side operation. The peer receiving the request may not have an IRRQ entry to store the request and may send an RNR with a specified time for the retry operation. When the RNR is received, the QP timer may be started and when the timer expires, the QP 156 may be pushed to the transmission scheduler to schedule the QP for service. The requester may increment the "read RNR received" counter. When the QP 156 is scheduled after the RNR, the read or atomic request and other requests that follow it are retransmitted.

[0095]

[0063] In some embodiments, read or atomic initiator side operations may be performed on the responder side of the SRC QP. The QPC state and chip state associated with these operations may include the following. The pending_irrq flag is used by the QPC to indicate that the QP 156 received a read or atomic request and responded with an RNR due to lack of IRRQ resources. pending_irrq is set when an RNR is sent due to lack of IRRQ resources. pending_irrq is cleared when the QP 156 can allocate resources. pending_response_bytes is the QPC count of the number of pending response bytes for incoming read requests on the QP 156. pending_response_bytes is incremented when a read request based on the read size is received and decremented by the packet size when each response packet is transmitted. num_awaiting_irrq_cnt is an RNIC counter indicating the number of QPs 156 that responded to the read request with an RNR. num_awaiting_irrq_cnt is incremented when a QP 156 first attempts to allocate an IRRQ 152 and fails (eg, when pending_irrq changes state from "cleared" to "set"). num_awaiting_irrq_cnt is decremented when a QP 156 with pending_irrq set can allocate an IRRQ 152.

[0096] Reference is now made to obtaining a free IRRQ entry. When a read or atomic request is made, the RNIC attempts to allocate an IRRQ entry to store the request information. If the allocation is successful, the QPC pending_response_bytes is incremented by the size of the read request. If no free IRRQ 152 is available, the responder sends an RNR with the packet sequence number (PSN) of the incoming read or atomic request with the retry timer value, or if the QP 156 has a pending response, then the pending_NAK is set and the RNRNAK may be sent after all pending responses are sent. The RNIC then discards all incoming requests until a request is received again. A QP flag, such as pending_irrq, is set, and if the QP flag is cleared, the num_awaiting_irrq_cnt is incremented. In some embodiments, the responder increments a "read RNR sent" counter.

[0097] In some embodiments, the RNR SYNDROME may have the following fields: Bit 7 corresponding to 0; Bits 6:5 corresponding to 01 (RNR code); Bits 4:0 corresponding to the configured time for reading the RNR. The default RNR retry timer is set by the application in the "Modify QP" field. The RNIC may use the default or higher value up to a maximum value of 0xb11111.

[0098] In some embodiments, for a QP 156 with pending incoming read requests, an RNR NAK may not be sent immediately, but stored in the QPC pending NAK information. In some embodiments, a NAK is sent when all responses to all currently pending read requests are sent. Until then, all incoming requests on the QP 156 are discarded, including non-read requests.

[0099] Reference is now made to the release of an IRRQ entry by the RNIC hardware. The RNIC releases an IRRQ entry when the IRRQ 152 is no longer in use. When the IRRQ 152 is no longer in use, the last response to a read or atomic request sent may be counted as this event.

[0100] In some embodiments, each process on the host has its own SSQ pool and ORRQ structure of a configured size. All QPs 156 have full RC context and support all RC operations. As described above, the IRRQ and ORRQ pointers in the QPC may be invalid. In some embodiments, the SSQ_ID may be invalid. The combined table of SSQs and ORRQs 154 is allocated as needed (e.g., when a WQE is issued) and may be freed when a WQE for the SSQ is completed. The allocation and freeing may be performed under user library control.

[0101] In some embodiments, a pool of SSQs is generated and a QP 156 is created. As part of a create_src_qp operation, the QP 156 is created in a typical manner, but with invalid IRRQ 152, ORRQ 154, and SSQ pointer (SSQ_ID) fields. When the QP 156 is created, the user space create_src_qp operation checks whether the number of SSQ resources created to that point is below the configured threshold for the number of SSQs per process. If this condition is met, a new pinned pool of SSQs of the configured size is created using the page buffer list (PBL) 153 of the SSQs. The new pinned pool of SSQs stores the index of the SSQ in the free SSQ FIFO maintained by the user library under each process.

[0102] In some embodiments, the driver creates a per-process translation table in kernel space and programs a pointer to the table to the RNIC. When creating an SSQ, the driver allocates pages, pins the pages, and maps the pages to user space. The driver translates the user space address to a physical address in the table and returns an index to the table to the create_src_qp function. The index to the table is used when attaching SSQ resources to the QP 156.

[0103] Figure 6Flowchart illustrating method 600 for handling WRs issued to QP 156. In some embodiments, method 600 may handle WRs from applications, method 600 may check if a free SSQ is available, and method 600 may issue requests to the SSQ or store requests until a free SSQ is available. In some embodiments, QP 156 is created with an invalid SSQ pointer (SSQ_ID). In step 602, method 600 is initiated with an application calling an ibv_post_send operation. When method 600 issues a WR by calling an ibv_post_send operation, an SSQ is required. When a WR is issued, ibv_post_send operation checks if QP 156 has an attached SSQ. In step 604, method 600 determines if SQ 157 is attached. If this condition is met, the operation continues with issuing WQEs to the SSQ and DB rings the bell on SSQ_ID. For example, in step 606, method 600 checks if all SSQ resources are consumed and if there are still pending QPs 156. If not all SQ resources are consumed or there are no pending QPs 156, then at step 612, method 600 may generate a WQE for each WR and write the WQE to the SSQ. At step 614, method 600 may ring the DB and return.

[0104] If the conditions of step 606 are met (e.g., if all SQ resources are consumed and there are still pending QPs 156), then at step 608, the method 600 determines whether the last WQE issued is signaled. If the last WQE issued is signaled, then at step 610, the method 600 stores the WR in the shadow SQ and returns. If the last WQE issued is not signaled, then at step 612, the method 600 may generate a WQE for each WR and write the WQE to the SSQ. At step 614, the method 600 may ring the DB and return.

[0105] If it is determined at step 604 that the QP 156 does not have an additional SSQ, then the ibv_post_send function attempts to allocate a pinned SSQ pool from its free SSQ pool. For example, at step 616, the method 600 determines if SQ resources are available. If SQ resources are available, then at step 618, the method 600 pops the free SSQ resource index. At step 620, the method 600 posts an "additional SSQ" WQE. At step 622, the method 600 generates a WQE for each WR and writes the WQE to the SSQ. At step 614, the method 600 may ring the DB and return.

[0106] If the allocation is unsuccessful due to, for example, lack of free resources, the method 600 stores the WR in the shadow SQ of the QP 156 for future use (step 624). At step 626, if the QP 156 is not already in the pending FIFO, the method 600 pushes the QP 156 to the pending FIFO (e.g., a FIFO of pending QPs 156 maintained by a user library) and returns.

[0107] Figure 7 800 may invoke method 700 by sending a command post_send_pending_qp. In step 704, method 700 may pop an idle SQ resource. In step 706, method 700 may issue an "Attach SSQ" WQE. In step 708, method 700 may generate a WQE for each WR in the shadow SQ and write the WQE to the SSQ. In some embodiments, a list of WRs in the invocation is processed, a WQE for each WR is generated, and the WQE is written to the newly allocated SSQ. In some embodiments, methods 600 and 700 update the shadow SQ of QP 156 to indicate that QP 156 has an additional SSQ with SSQ_ID.

[0108] At step 710, the method 700 determines whether an "SQ attach complete" communication is received. The "no" feedback loop indicates that until an "SQ attach complete" communication is received, the method 700 proceeds to the next step 712. At step 712, the method 700 rings the DB upon receiving the "SQ attach complete" communication and returns. For example, the DB of SSQ_ID rings the producer index according to the number of WQEs generated.

[0109] To reduce or avoid starvation of some QPs 156, the ibv_post_send operation changes behavior under stress conditions. When all SSQ resources are consumed and there are QPs 156 waiting for SSQ resources, if the last WQE generated and posted to the SSQ resources is signaled and additional WRs are stored in the shadow SQ of the QP 156, the system 200 stops generating WQEs for the QP 156 that owns the resources. Under such conditions, when the QP 156 that owns the resources generates the last CQE, pollCq releases the SSQ resources almost immediately and does not push the QP 156 to the FIFO of release candidates.

[0110] Figure 8 Flowchart illustrating a method 800 for releasing SSQ resources and processing WRs of pending QPs 156. In some embodiments, the method 800 may release the SSQ to a free pool, the method 800 may check if there are connections waiting for SSQ resources, and if there are connections waiting for SSQ resources, the method 800 may initiate the allocation of the SSQ to the next waiting connection. At step 802, the application calls the pollCq operation. For each call to the pollCq operation made by the process, the pollCq operation checks if the last outstanding WQE has been executed to completion. If it has been executed, then at step 804, the method 800 processes the CQE. In some embodiments, the pollCq operation processes the CQE and pushes the QP 156 to the FIFO of release candidates. For example, at step 806, the method 800 determines if all WQEs in the SQ 157 are completed. If this condition is met, then at step 808, the method 800 determines if there are pending QPs 156 (e.g., if all SSQ resources are consumed). If there is no pending QP 156 (e.g., not all SSQ resources are consumed), then at step 810, the method 800 pushes the QP 156 to the release candidate FIFO. At step 812, the method 800 determines whether the length of the release candidate FIFO is equal to or greater than a threshold. If the length of the release candidate FIFO is less than the threshold, then at step 814, the method 800 returns.

[0111] If the release candidate FIFO has a configured number of QPs 156 (e.g., 16), the first QP 156 is popped (e.g., pulled from the queue). If the SSQ of a QP 156 is empty, the SSQ resources of that QP 156 are released and pushed to the free resource FIFO or assigned to the QP 156 that was popped (or removed) from the pending list. At step 816, the method 800 determines whether the QP shadow list is empty. If the QP shadow list is not empty, then at step 818, the method 800 pushes the QP 156 to the pending list. If all SSQs are consumed and the user base issues additional WRs to the shadow QP instead of to the SSQ attached to the QP 156, then the QP 156 may have a WQE in the shadow QP.

[0112] If the QP shadow list is empty, then at step 820, the method 800 releases the SSQ resources. For example, when releasing the SSQ, the emptiness of the shadow QP is checked, and if the shadow QP contains a WQE, the QP 156 is pushed to the pending list. For example, releasing the additional SSQ may involve only the user library and not the RNIC hardware. At step 822, the method 800 determines whether the list with pending QPs is empty. At step 824, if the list with pending QPs is empty, the method 800 pushes the SSQ to the free SSQ FIFO. For example, the resource SSQ_ID may be pushed to the free SSQ resource FIFO. In some embodiments, the pollCq operation checks whether there is a pending QP 156, and if so, the pollCq operation pops the first pending QP 156 and calls the post_send_pending_qp operation (e.g., method 700). If the condition of step 822 is not met, then at step 826, the method 800 pops the QP 156 from the pending FIFO, if such a QP 156 exists. For example, SSQ resources may be popped from the free SSQ FIFO and attached to the pending QP 156. At step 828, the method 800 calls the post_send_pending_qp operation and the method 700 may be executed. For example, the post_send_pending_qp operation may then retrieve each WR from the shadow SQ of the pending QP 156, generate a WQE, and write the WQE to the allocation SSQ. At step 830, the method 800 pops the candidate QP 156. At step 832, the method 800 checks whether the SSQ of the popped candidate QP 156 is still empty. If the SSQ of the popped candidate QP 156 is empty, the method 800 continues to step 816 and performs the above operations. Otherwise, if the SSQ from which the candidate QP 156 was popped is not empty, the method 800 returns (step 814).

[0113] Reference is now made to verification and error handling. In some embodiments, when an RNR is received for a read or atomic request, the conventional "SQ RNR Retry" counter is not decremented, but a new "Read RNR Retry" may be decremented. The "Read RNR Retry" initial value is configurable and may accept values ​​up to 256. When the handling of a "Read RNR Retry" is exceeded (e.g., when the count reaches zero (0)), the operation is substantially the same as exceeding a conventional "SQ RNR Retry" and causes the QP 156 to change to an error state. Operations for "Read RNR Retry" that exceed completion are issued for WQEs.

[0114] Fig. 9 is a flow chart of a method process 900 for creating a shared send queue (SSQ) pool in memory, assigning the SSQ to one or more QPs 156, and sending outgoing messages. In some implementations, Fig. 9 One or more steps or blocks of may be performed by the system 200.

[0115] like Fig. 9 , method 900 may include establishing, by one or more processors, a pool of shared send queues (SSQs) in memory (block 910). For example, system 200 may establish, by one or more processors, a pool of shared send queues (SSQs) in memory, each SSQ in the pool of SSQs to be used as a send queue (SQ) 157 for one or more queue pairs (QPs) 156, as described above (block 912).

[0116] Method 900 may include additional implementations, such as any single implementation or any combination of implementations described below or in conjunction with one or more other processes described elsewhere herein. In a first implementation, method 900 may include establishing a pool in response to the number of queue pairs (QPs) 156 reaching a threshold (block 914).

[0117] like Fig. 9 , method 900 may include allocating, by one or more processors, an SSQ from a pool of SSQs to a QP 156 (block 920). For example, system 200 may allocate an SSQ to a QP 156 established for a process (block 922). For example, a process may have multiple connections to multiple remote processes (block 924).

[0118] like Fig. 9 As shown in FIG. 9 , method 900 may include sending an outgoing message to an individual remote process in the plurality of remote processes (block 930 ).

[0119] although Fig. 9 Example blocks of method 900 are shown, but in some embodiments, Fig. 9 The method 900 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks compared to the blocks depicted in the method 900. Two or more blocks of the method 900 may be performed in parallel.

[0120] The term "configured to" may refer to the functional capability of a system or device to perform a specific operation or set of steps. For example, a general purpose processor or a special purpose processor may have the structure, hardware, or software to implement the specified functionality. For example, a general purpose processor may run software that causes the described steps to occur. In addition, a special purpose processor or a specially implemented processor may be designed or adapted to perform a specified task.

[0121] The following IEEE standards (including any draft versions of such standards) are incorporated herein by reference in their entirety and are made part of the present disclosure for all purposes: IEEE 802.3, IEEE 802.11x, IEEE 802.11ad, IEEE 802.11ah, IEEE 802.11aj, IEEE 802.16 and 802.16a, and IEEE 802.11ac. In addition, although the present disclosure may refer to aspects of these standards, the present disclosure is in no way limited by these standards.

[0122] Although the foregoing written description of the methods and systems enables a person of ordinary skill to make and use various embodiments of these methods and systems, a person of ordinary skill should understand and appreciate that there are variations, combinations, and equivalents of the specific embodiments, methods, and examples herein. The methods and systems of the present invention should therefore not be limited by the above-described embodiments, methods, and examples, but should be limited by all embodiments and methods within the scope and spirit of the present disclosure.

Claims

1. A system comprising: One or more processors coupled to the memory, the processors configured to: A shared send queue SSQ pool is set in the memory, each SSQ in the SSQ pool is configured to be used as a send queue SQ for one or more queue pairs QP; assigning at least one of the SSQs from the SSQ pool to the QP, the SSQ being set for a process having a plurality of connections to a plurality of remote processes; and An outgoing message is sent by the SSQ via the plurality of connections to an individual remote process of the plurality of remote processes. 2 . The system of claim 1 , wherein the pool is set in response to the first number of QPs reaching a threshold.

3. The system of claim 1, wherein the SSQ pool is pinned in the memory.

4. The system of claim 1, wherein the SSQ is used as the SQ for at least one QP instead of an individual SQ for each QP.

5. The system of claim 1, wherein the system uses a pool of incoming read request queues (IRRQs) and the SSQ uses a corresponding outgoing read request queue (ORRQ).

6. The system of claim 1, wherein the QP is configured to have a pointer to the SSQ in the SSQ pool.

7. The system of claim 1, wherein the SSQ is released by the QP in response to identifying that the SQ of the QP is empty.

8. A system comprising: One or more processors coupled to the memory, the processors configured to: In response to a first process in a user space, setting a first QP of a plurality of queue pairs QPs, a first set of resources of the first QP allocated from the memory being located in a kernel space; In response to a second process in the user space, setting a second QP among the plurality of QPs, a second set of resources of the second QP allocated from the memory being located in the kernel space; and Setting a pool including a shared send queue SSQ, wherein the SSQ is shared by the first QP and the second QP, The SSQ is released in response to the number of the plurality of QPs reaching a first threshold.

9. The system of claim 8, wherein a send queue (SQ) of one of the first QP or the second QP is pinned in the user space of the memory.

10. The system of claim 8, wherein a QP context of one of the first QP or the second QP is pinned in the kernel space of the memory.

11. The system of claim 8, wherein QP information is located in a swappable portion of one of the user space or the kernel space of the memory.

12. The system of claim 8, wherein the pool is set in response to a second number of the plurality of QPs being set reaching a second threshold.

13. The system of claim 8, wherein the system uses a pool of incoming read request queues (IRRQs) and the SSQ uses a corresponding outgoing read request queue (ORRQ).

14. A method comprising: A shared send queue SSQ pool is set in a memory by one or more processors, each SSQ in the SSQ pool is used as a send queue SQ of one or more queue pairs QP; allocating, by the one or more processors, at least one of the SSQs from the SSQ pool to the QP, the SSQ being set for a process having a plurality of connections to a plurality of remote processes; and An outgoing message is sent by the SSQ via the plurality of connections to an individual remote process of the plurality of remote processes.

15. The method of claim 14, further comprising setting the pool in response to the first number of QPs reaching a threshold.

16. The method of claim 14, wherein the SSQ pool is pinned in the memory.

17. The method of claim 14, wherein the SSQ is used as the SQ for at least one QP instead of an individual SQ for each QP.

18. The method of claim 14, wherein the system uses a pool of incoming read request queues (IRRQs) and the SSQ uses a corresponding outgoing read request queue (ORRQ).

19. The method of claim 14, wherein the QP is set to have a pointer to the SSQ in the SSQ pool.

20. The method of claim 14, wherein the SSQ is released by the QP in response to identifying that the SQ of the QP is empty.

Images