.\" Automatically generated by Pandoc 2.17.1.1
.\"
.\" Define V font for inline verbatim, using C font in formats
.\" that render this, and otherwise B font.
.ie "\f[CB]x\f[]"x" \{\
. ftr V B
. ftr VI BI
. ftr VB B
. ftr VBI BI
.\}
.el \{\
. ftr V CR
. ftr VI CI
. ftr VB CB
. ftr VBI CBI
.\}
.TH "mlx5dv_reserved_qpn_alloc / dealloc" "3" "2020-12-29" "mlx5" "mlx5 Programmer\[cq]s Manual"
.hy
.SH NAME
.PP
mlx5dv_reserved_qpn_alloc - Allocate a reserved QP number from device
.PP
mlx5dv_reserved_qpn_dealloc - Release the reserved QP number
.SH SYNOPSIS
.IP
.nf
\f[C]
#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);
\f[R]
.fi
.SH DESCRIPTION
.PP
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\[cq]s 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\[cq]s 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
.PP
0 on success; EOPNOTSUPP if not supported, or other errno value on other
failures.
.SH AUTHOR
.PP
Mark Zhang <markzhang@nvidia.com>
.PP
Alex Rosenbaum <alexr@nvidia.com>
