.\" Automatically generated by Pandoc 3.8.2.1
.\"
.TH "mlx5dv_reserved_qpn_alloc / dealloc" "3" "2020\-12\-29" "mlx5" "mlx5 Programmer\(cqs Manual"
.SH NAME
mlx5dv_reserved_qpn_alloc \- Allocate a reserved QP number from device
.PP
mlx5dv_reserved_qpn_dealloc \- Release the reserved QP number
.SH SYNOPSIS
.IP
.EX
#include \f[B]<infiniband/mlx5dv.h>\f[R]

int mlx5dv_reserved_qpn_alloc(\f[B]struct\f[R] ibv_context *ctx, uint32_t *qpn);

int mlx5dv_reserved_qpn_dealloc(\f[B]struct\f[R] ibv_context *ctx, uint32_t qpn);
.EE
.SH DESCRIPTION
When work with RDMA_CM RDMA_TCP_PS + external QP support, a client node
needs GUID level unique QP numbers to comply with the CM\(cqs timewait
logic.
.PP
If a real unique QP is not allocated, a device global QPN value is
required and can be allocated via this interface.
.PP
The mlx5 DCI QP is such an example, which could connect to the remote
DCT\(cqs multiple times as long as the application provides unique QPN
for each new RDMA_CM connection.
.PP
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.
.SH ARGUMENTS
.TP
\f[I]ctx\f[R]
The device context to issue the action on.
.TP
\f[I]qpn\f[R]
The allocated QP number (for alloc API), or the QP number to be
deallocated (for dealloc API).
.SH RETURN VALUE
0 on success; EOPNOTSUPP if not supported, or other errno value on other
failures.
.SH AUTHOR
Mark Zhang \c
.MT markzhang@nvidia.com
.ME \c
.PP
Alex Rosenbaum \c
.MT alexr@nvidia.com
.ME \c
