RDMA_CREATE_EP(3)

💖 RDMA_CREATE_EP 💖

okay bestie, sit down, hydrate, and let me tell you about rdma_create_ep from the librdmacm programmer's manual, section 3. it's giving "build me an identifier" and honestly? it ate. 🫶

✨ NAME ✨

rdma_create_ep — allocate a communication identifier and, like, optionally a QP too. two-for-one, no cap.

✨ SYNOPSIS ✨

#include <rdma/rdma_cma.h>

int rdma_create_ep (struct rdma_cm_id **id, struct rdma_addrinfo *res,
struct ibv_pd  *pd, struct ibv_qp_init_attr *qp_init_attr);

✨ ARGUMENTS ✨

• id — a reference where the allocated communication identifier gets returned. it's a pointer-to-a-pointer situation, main character energy, you hand it a spot and it fills the spot 💅
• res — address information associated with the rdma_cm_id, and you got it from rdma_getaddrinfo. yep, that one.
• pd — optional protection domain, but only if a QP is associated with the rdma_cm_id. optional means optional, bestie.
• qp_init_attr — optional initial QP attributes. also optional. we love a chill parameter. 🌸

✨ DESCRIPTION ✨

creates an identifier that's used to track communication information. that's the whole vibe. ✨

✨ RETURN VALUE ✨

returns 0 on success, or -1 on error. and if an error happens, errno gets set to tell you the failure reason, so like, read it, don't ignore it 😭

✨ NOTES ✨

after you resolve address info with rdma_getaddrinfo, you can use this call to allocate an rdma_cm_id based on the results. cute, right?

if the rdma_cm_id is gonna be used on the active side of a connection — meaning res->ai_flag does not have RAI_PASSIVE set — then rdma_create_ep will automatically create a QP on the rdma_cm_id if qp_init_attr is not NULL. the QP gets associated with the protection domain you specified, if you provided one, or with a default protection domain if you didn't. for the details on how pd and qp_init_attr actually work, go peek at rdma_create_qp, okay? after calling rdma_create_ep, the returned rdma_cm_id may be connected by calling rdma_connect. and here's the slay: on the active side, the calls rdma_resolve_addr and rdma_resolve_route are not necessary. we skipped a whole step. iconic. 👑

if the rdma_cm_id is gonna be used on the passive side of a connection — indicated by res->ai_flag having RAI_PASSIVE set — then this call will save the pd and qp_init_attr parameters you gave it. then, when a new connection request is retrieved by calling rdma_get_request, the rdma_cm_id associated with that new connection will automatically be associated with a QP using those pd and qp_init_attr parameters. after calling rdma_create_ep, the returned rdma_cm_id may be placed into a listening state by immediately calling rdma_listen. and on the passive side, the call rdma_bind_addr is not necessary. connection requests may then be retrieved by calling rdma_get_request. look at the pipeline go 🦋

the newly created rdma_cm_id will be set to use synchronous operation. if you want asynchronous operation, you have to migrate the rdma_cm_id to a user created event channel using rdma_migrate_id. no shortcuts, bestie.

🚨 IMPORTANT: users must release the created rdma_cm_id by calling rdma_destroy_ep. don't just leave it there, that's not the vibe, that's a leak 🙈

✨ SEE ALSO ✨

• rdma_cm(7)
• rdma_getaddrinfo(3)
• rdma_create_event_channel(3)
• rdma_connect(3)
• rdma_listen(3)
• rdma_destroy_ep(3)
• rdma_migrate_id(3)

librdmacm wrote this one down on 2010-07-19, and that's the whole page, page RDMA_CREATE_EP(3) — periodt. go build something, you've got this 💖✨🎀