MLX5DV_RESERVED_QPN_DEALLOC(3)

📦
version 62.0 · 8 versions
, in alpine 3.24, centos-stream 10, centos-stream 9, ubuntu jammy

okay bestie, this is the mlx5dv_res...c / dealloc(3) page from the mlx5 Programmer’s Manual — let’s get into it 💅

✨ NAME ✨

  • mlx5dv_reserved_qpn_alloc — allocate a reserved QP number from device
  • mlx5dv_reserved_qpn_dealloc — release the reserved QP number

🛠️ SYNOPSIS 🛠️

#include <infiniband/mlx5dv.h>

int mlx5dv_reserved_qpn_alloc(struct ibv_context *ctx, uint32_t *qpn);

int mlx5dv_reserved_qpn_dealloc(struct ibv_context *ctx, uint32_t qpn);

💖 DESCRIPTION 💖

okay so when you’re working with RDMA_CM RDMA_TCP_PS + external QP support, a client node needs GUID level unique QP numbers to comply with the CM’s timewait logic. no cap, that’s the whole vibe check here 🫶

If a real unique QP is not allocated, a device global QPN value is required and can be allocated via this interface. lowkey iconic ✨

The mlx5 DCI QP is such an example, which could connect to the remote DCT’s multiple times as long as the application provides unique QPN for each new RDMA_CM connection. it’s giving “unique QPN per connection” energy 🔥

These 2 APIs provide the allocation/deallocation of a unique QP number from/to device. This qpn can be used with DC QPN in RDMA_CM connection establishment, which will comply with the CM timewait kernel logic. periodt 💅

🌸 ARGUMENTS 🌸

  • ctx — the device context to issue the action on.
  • qpn — the allocated QP number (for alloc API), or the QP number to be deallocated (for dealloc API).

⭐ RETURN VALUE ⭐

0 on success; EOPNOTSUPP if not supported, or other errno value on other failures.

👑 AUTHOR 👑

  • Mark Zhang <markzhang@nvidia.com>
  • Alex Rosenbaum <alexr@nvidia.com>

Source: mlx5 • Date: 2020-12-29 • Page: mlx5dv_res...c / dealloc(3) — catch u later bestie, mwah 🫶💖

📦 where this page comes from