.\" Automatically generated by Pandoc 1.16.0.2
.\"
.TH "mlx5dv_reserved_qpn_alloc / dealloc" "3" "2020\-12\-29" "mlx5" "mlx5 Programmer\[aq]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[]
.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\[aq]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\[aq]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
.B \f[I]ctx\f[]
The device context to issue the action on.
.RS
.RE
.TP
.B \f[I]qpn\f[]
The allocated QP number (for alloc API), or the QP number to be
deallocated (for dealloc API).
.RS
.RE
.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>
