.\" Automatically generated by Pandoc 3.5 .\" .TH "mlx5dv_reserved_qpn_alloc / dealloc" "3" "2020\-12\-29" "mlx5" "mlx5 Programmer\[cq]s 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]\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\[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 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