RDMA_ACCEPT(3)

✨ rdma_accept — the "yes bestie, come in" of the CM world ✨

okay so this is a page from the Librdmacm Programmer's Manual — it's RDMA_ACCEPT(3), and it's literally the function that says "omg hi, you're accepted" to a connection request 💖

🌸 NAME 🌸

rdma_accept — called to accept a connection request.

(that's it. that's the whole job. iconic behavior fr fr 👑)

🦋 SYNOPSIS 🦋

#include <rdma/rdma_cma.h>

int rdma_accept (struct rdma_cm_id *id, struct rdma_conn_param
*conn_param);

🎀 ARGUMENTS 🎀

• id — the connection identifier associated with the request. it's giving "who's knocking at my door" energy 🚪
• conn_param — the info you need to establish the connection. scroll down to CONNECTION PROPERTIES for the deets, bestie 👇

💅 DESCRIPTION 💅

You call this from the listening side to accept a connection, or a datagram service lookup request. that's the vibe. that's the whole thing 🫶

⭐ RETURN VALUE ⭐

• Returns 0 on success ✨
• Returns -1 on error 😭 and if that happens, errno gets set to tell you why it went wrong.

🌈 NOTES 🌈

okay this is the part where it is NOT like the socket accept routine, and you need to hear me on this one:

• rdma_accept is not called on a listening rdma_cm_id. nope. not the move.
• Instead: after you call rdma_listen, you wait for an RDMA_CM_EVENT_CONNECT_REQUEST event to show up.
• Those connection request events hand you a newly created rdma_cm_id — kinda like how a new socket shows up — except this rdma_cm_id is bound to a specific RDMA device 🧚
• Then, and only then, rdma_accept gets called on the new rdma_cm_id.

so: listen → wait for event → accept on the new id. periodt 💅

🍓 CONNECTION PROPERTIES 🍓

These are the properties that configure the communication, and you pass them through the conn_param parameter when you're accepting a connection or datagram communication request.

bestie listen — you should use the rdma_conn_param values reported in the connection request event to figure out what values make sense here when accepting. you can either reference the rdma_conn_param structure in the connection event directly, or bring your own structure. BUT: if you reference the rdma_conn_param structure from an event, that event must not be acked until after this call returns. no cap, that's a real rule 🙈

And if conn_param is NULL? Then the values reported in the connection request event get used, adjusted down based on local hardware restrictions. easy.

• private_data — references a user-controlled data buffer. the contents get copied and transparently passed to the remote side as part of the communication request. may be NULL if private_data isn't required 🎀
• private_data_len — the size of that user-controlled data buffer. note that the actual amount of data transferred to the remote side is transport dependent and may be larger than what you requested 👀
• responder_resources — the max number of outstanding RDMA read and atomic operations that the local side will accept from the remote side. applies only to RDMA_PS_TCP. this value must be less than or equal to the local RDMA device attribute max_qp_rd_atom, but preferably greater than or equal to the responder_resources value reported in the connect request event.
• initiator_depth — the max number of outstanding RDMA read and atomic operations that the local side will have to the remote side. applies only to RDMA_PS_TCP. this value must be less than or equal to the local RDMA device attribute max_qp_init_rd_atom and the initiator_depth value reported in the connect request event.
• flow_control — specifies if hardware flow control is available. this value is exchanged with the remote peer and is not used to configure the QP. applies only to RDMA_PS_TCP.
• retry_count — this value is ignored. yeah. nothing. move along 💀
• rnr_retry_count — the max number of times that a send operation from the remote peer should be retried on a connection after receiving a receiver not ready (RNR) error. RNR errors are generated when a send request arrives before a buffer has been posted to receive the incoming data. applies only to RDMA_PS_TCP.
• srq — specifies if the QP associated with the connection is using a shared receive queue. this field is ignored by the library if a QP has been created on the rdma_cm_id. applies only to RDMA_PS_TCP.
• qp_num — specifies the QP number associated with the connection. this field is ignored by the library if a QP has been created on the rdma_cm_id.

🔥 INFINIBAND SPECIFIC 🔥

on top of all the connection properties above, InfiniBand QPs also get configured with a minimum RNR NAK timer and local ACK timeout value. here's the tea:

• The minimum RNR NAK timer value is set to 0, for a delay of 655 ms.
• The local ACK timeout is calculated based on the packet lifetime and local HCA ACK delay.
• The packet lifetime is determined by the InfiniBand Subnet Administrator and is part of the route (path record) information obtained by the active side of the connection.
• The HCA ACK delay is a property of the locally used HCA.

Also, the RNR retry count is a 3-bit value. tiny but mighty ✨

And the length of the private data provided by the user is limited to 196 bytes for RDMA_PS_TCP, or 136 bytes for RDMA_PS_UDP. don't overdo it bestie, there's a limit 🫶

👑 SEE ALSO 👑

• rdma_listen(3)
• rdma_reject(3)
• rdma_get_cm_event(3)

and that's the whole page, bestie!! this one's from librdmacm, dated 2014-05-27 — go forth and accept those connections, you absolute main character 💖✨🦋