.\" Automatically generated by Pandoc 2.0.6
.\"
.TH "mlx5dv_reserved_qpn_alloc / dealloc" "3" "2020\-12\-29" "mlx5" "mlx5 Programmer'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'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'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>
