1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
.\" Automatically generated by Pandoc 2.9.2.1
.\"
.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>
|
