2005-07-08 00:57:12 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2005 Topspin Communications. All rights reserved.
|
2006-01-30 22:29:21 +00:00
|
|
|
* Copyright (c) 2005, 2006 Cisco Systems. All rights reserved.
|
2005-10-14 22:21:44 +00:00
|
|
|
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
|
2006-02-14 00:31:57 +00:00
|
|
|
* Copyright (c) 2006 Mellanox Technologies. All rights reserved.
|
2005-07-08 00:57:12 +00:00
|
|
|
*
|
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
|
* conditions are met:
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer.
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
|
* provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
|
* SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef IB_USER_VERBS_H
|
|
|
|
|
#define IB_USER_VERBS_H
|
|
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Increment this value if any changes that break userspace ABI
|
|
|
|
|
* compatibility are made.
|
|
|
|
|
*/
|
2006-02-23 20:36:18 +00:00
|
|
|
#define IB_USER_VERBS_ABI_VERSION 6
|
2013-08-14 10:58:29 +00:00
|
|
|
#define IB_USER_VERBS_CMD_THRESHOLD 50
|
2005-07-08 00:57:12 +00:00
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
IB_USER_VERBS_CMD_GET_CONTEXT,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_DEVICE,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_PORT,
|
|
|
|
|
IB_USER_VERBS_CMD_ALLOC_PD,
|
|
|
|
|
IB_USER_VERBS_CMD_DEALLOC_PD,
|
|
|
|
|
IB_USER_VERBS_CMD_CREATE_AH,
|
|
|
|
|
IB_USER_VERBS_CMD_MODIFY_AH,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_AH,
|
|
|
|
|
IB_USER_VERBS_CMD_DESTROY_AH,
|
|
|
|
|
IB_USER_VERBS_CMD_REG_MR,
|
|
|
|
|
IB_USER_VERBS_CMD_REG_SMR,
|
|
|
|
|
IB_USER_VERBS_CMD_REREG_MR,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_MR,
|
|
|
|
|
IB_USER_VERBS_CMD_DEREG_MR,
|
|
|
|
|
IB_USER_VERBS_CMD_ALLOC_MW,
|
|
|
|
|
IB_USER_VERBS_CMD_BIND_MW,
|
|
|
|
|
IB_USER_VERBS_CMD_DEALLOC_MW,
|
2005-09-26 20:53:25 +00:00
|
|
|
IB_USER_VERBS_CMD_CREATE_COMP_CHANNEL,
|
2005-07-08 00:57:12 +00:00
|
|
|
IB_USER_VERBS_CMD_CREATE_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_RESIZE_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_DESTROY_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_POLL_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_PEEK_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_REQ_NOTIFY_CQ,
|
|
|
|
|
IB_USER_VERBS_CMD_CREATE_QP,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_QP,
|
|
|
|
|
IB_USER_VERBS_CMD_MODIFY_QP,
|
|
|
|
|
IB_USER_VERBS_CMD_DESTROY_QP,
|
|
|
|
|
IB_USER_VERBS_CMD_POST_SEND,
|
|
|
|
|
IB_USER_VERBS_CMD_POST_RECV,
|
|
|
|
|
IB_USER_VERBS_CMD_ATTACH_MCAST,
|
2005-08-18 19:24:13 +00:00
|
|
|
IB_USER_VERBS_CMD_DETACH_MCAST,
|
|
|
|
|
IB_USER_VERBS_CMD_CREATE_SRQ,
|
|
|
|
|
IB_USER_VERBS_CMD_MODIFY_SRQ,
|
|
|
|
|
IB_USER_VERBS_CMD_QUERY_SRQ,
|
|
|
|
|
IB_USER_VERBS_CMD_DESTROY_SRQ,
|
2011-05-24 15:33:46 +00:00
|
|
|
IB_USER_VERBS_CMD_POST_SRQ_RECV,
|
|
|
|
|
IB_USER_VERBS_CMD_OPEN_XRCD,
|
2011-05-26 00:08:38 +00:00
|
|
|
IB_USER_VERBS_CMD_CLOSE_XRCD,
|
2011-08-11 20:57:43 +00:00
|
|
|
IB_USER_VERBS_CMD_CREATE_XSRQ,
|
2013-08-14 10:58:30 +00:00
|
|
|
IB_USER_VERBS_CMD_OPEN_QP,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-06 22:21:49 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum {
|
2015-02-08 11:28:50 +00:00
|
|
|
IB_USER_VERBS_EX_CMD_QUERY_DEVICE = IB_USER_VERBS_CMD_QUERY_DEVICE,
|
2015-06-11 13:35:23 +00:00
|
|
|
IB_USER_VERBS_EX_CMD_CREATE_CQ = IB_USER_VERBS_CMD_CREATE_CQ,
|
2015-10-21 14:00:42 +00:00
|
|
|
IB_USER_VERBS_EX_CMD_CREATE_QP = IB_USER_VERBS_CMD_CREATE_QP,
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-06 22:21:49 +00:00
|
|
|
IB_USER_VERBS_EX_CMD_CREATE_FLOW = IB_USER_VERBS_CMD_THRESHOLD,
|
2014-12-11 15:04:15 +00:00
|
|
|
IB_USER_VERBS_EX_CMD_DESTROY_FLOW,
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Make sure that all structs defined in this file remain laid out so
|
|
|
|
|
* that they pack the same way on 32-bit and 64-bit architectures (to
|
|
|
|
|
* avoid incompatibility between 32-bit userspace and 64-bit kernels).
|
2005-10-14 22:21:44 +00:00
|
|
|
* Specifically:
|
|
|
|
|
* - Do not use pointer types -- pass pointers in __u64 instead.
|
|
|
|
|
* - Make sure that any structure larger than 4 bytes is padded to a
|
|
|
|
|
* multiple of 8 bytes. Otherwise the structure size will be
|
|
|
|
|
* different between 32-bit and 64-bit architectures.
|
2005-07-08 00:57:12 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_async_event_desc {
|
|
|
|
|
__u64 element;
|
|
|
|
|
__u32 event_type; /* enum ib_event_type */
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_comp_event_desc {
|
|
|
|
|
__u64 cq_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* All commands from userspace should start with a __u32 command field
|
|
|
|
|
* followed by __u16 in_words and out_words fields (which give the
|
|
|
|
|
* length of the command block and response buffer if any in 32-bit
|
|
|
|
|
* words). The kernel driver will read these fields first and read
|
|
|
|
|
* the rest of the command struct based on these value.
|
|
|
|
|
*/
|
|
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-06 22:21:49 +00:00
|
|
|
#define IB_USER_VERBS_CMD_COMMAND_MASK 0xff
|
|
|
|
|
#define IB_USER_VERBS_CMD_FLAGS_MASK 0xff000000u
|
|
|
|
|
#define IB_USER_VERBS_CMD_FLAGS_SHIFT 24
|
|
|
|
|
|
|
|
|
|
#define IB_USER_VERBS_CMD_FLAG_EXTENDED 0x80
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_cmd_hdr {
|
|
|
|
|
__u32 command;
|
|
|
|
|
__u16 in_words;
|
|
|
|
|
__u16 out_words;
|
|
|
|
|
};
|
|
|
|
|
|
IB/core: extended command: an improved infrastructure for uverbs commands
Commit 400dbc96583f ("IB/core: Infrastructure for extensible uverbs
commands") added an infrastructure for extensible uverbs commands
while later commit 436f2ad05a0b ("IB/core: Export ib_create/destroy_flow
through uverbs") exported ib_create_flow()/ib_destroy_flow() functions
using this new infrastructure.
According to the commit 400dbc96583f, the purpose of this
infrastructure is to support passing around provider (eg. hardware)
specific buffers when userspace issue commands to the kernel, so that
it would be possible to extend uverbs (eg. core) buffers independently
from the provider buffers.
But the new kernel command function prototypes were not modified to
take advantage of this extension. This issue was exposed by Roland
Dreier in a previous review[1].
So the following patch is an attempt to a revised extensible command
infrastructure.
This improved extensible command infrastructure distinguish between
core (eg. legacy)'s command/response buffers from provider
(eg. hardware)'s command/response buffers: each extended command
implementing function is given a struct ib_udata to hold core
(eg. uverbs) input and output buffers, and another struct ib_udata to
hold the hw (eg. provider) input and output buffers.
Having those buffers identified separately make it easier to increase
one buffer to support extension without having to add some code to
guess the exact size of each command/response parts: This should make
the extended functions more reliable.
Additionally, instead of relying on command identifier being greater
than IB_USER_VERBS_CMD_THRESHOLD, the proposed infrastructure rely on
unused bits in command field: on the 32 bits provided by command
field, only 6 bits are really needed to encode the identifier of
commands currently supported by the kernel. (Even using only 6 bits
leaves room for about 23 new commands).
So this patch makes use of some high order bits in command field to
store flags, leaving enough room for more command identifiers than one
will ever need (eg. 256).
The new flags are used to specify if the command should be processed
as an extended one or a legacy one. While designing the new command
format, care was taken to make usage of flags itself extensible.
Using high order bits of the commands field ensure that newer
libibverbs on older kernel will properly fail when trying to call
extended commands. On the other hand, older libibverbs on newer kernel
will never be able to issue calls to extended commands.
The extended command header includes the optional response pointer so
that output buffer length and output buffer pointer are located
together in the command, allowing proper parameters checking. This
should make implementing functions easier and safer.
Additionally the extended header ensure 64bits alignment, while making
all sizes multiple of 8 bytes, extending the maximum buffer size:
legacy extended
Maximum command buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
Maximum response buffer: 256KBytes 1024KBytes (512KBytes + 512KBytes)
For the purpose of doing proper buffer size accounting, the headers
size are no more taken in account in "in_words".
One of the odds of the current extensible infrastructure, reading
twice the "legacy" command header, is fixed by removing the "legacy"
command header from the extended command header: they are processed as
two different parts of the command: memory is read once and
information are not duplicated: it's making clear that's an extended
command scheme and not a different command scheme.
The proposed scheme will format input (command) and output (response)
buffers this way:
- command:
legacy header +
extended header +
command data (core + hw):
+----------------------------------------+
| flags | 00 00 | command |
| in_words | out_words |
+----------------------------------------+
| response |
| response |
| provider_in_words | provider_out_words |
| padding |
+----------------------------------------+
| |
. <uverbs input> .
. (in_words * 8) .
| |
+----------------------------------------+
| |
. <provider input> .
. (provider_in_words * 8) .
| |
+----------------------------------------+
- response, if present:
+----------------------------------------+
| |
. <uverbs output space> .
. (out_words * 8) .
| |
+----------------------------------------+
| |
. <provider output space> .
. (provider_out_words * 8) .
| |
+----------------------------------------+
The overall design is to ensure that the extensible infrastructure is
itself extensible while begin more reliable with more input and bound
checking.
Note:
The unused field in the extended header would be perfect candidate to
hold the command "comp_mask" (eg. bit field used to handle
compatibility). This was suggested by Roland Dreier in a previous
review[2]. But "comp_mask" field is likely to be present in the uverb
input and/or provider input, likewise for the response, as noted by
Matan Barak[3], so it doesn't make sense to put "comp_mask" in the
header.
[1]:
http://marc.info/?i=CAL1RGDWxmM17W2o_era24A-TTDeKyoL6u3NRu_=t_dhV_ZA9MA@mail.gmail.com
[2]:
http://marc.info/?i=CAL1RGDXJtrc849M6_XNZT5xO1+ybKtLWGq6yg6LhoSsKpsmkYA@mail.gmail.com
[3]:
http://marc.info/?i=525C1149.6000701@mellanox.com
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://marc.info/?i=cover.1383773832.git.ydroneaud@opteya.com
[ Convert "ret ? ret : 0" to the equivalent "ret". - Roland ]
Signed-off-by: Roland Dreier <roland@purestorage.com>
2013-11-06 22:21:49 +00:00
|
|
|
struct ib_uverbs_ex_cmd_hdr {
|
|
|
|
|
__u64 response;
|
2013-08-14 10:58:29 +00:00
|
|
|
__u16 provider_in_words;
|
|
|
|
|
__u16 provider_out_words;
|
|
|
|
|
__u32 cmd_hdr_reserved;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_get_context {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_get_context_resp {
|
|
|
|
|
__u32 async_fd;
|
2005-09-26 20:53:25 +00:00
|
|
|
__u32 num_comp_vectors;
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_query_device {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_query_device_resp {
|
|
|
|
|
__u64 fw_ver;
|
2005-08-14 04:05:57 +00:00
|
|
|
__be64 node_guid;
|
|
|
|
|
__be64 sys_image_guid;
|
2005-07-08 00:57:12 +00:00
|
|
|
__u64 max_mr_size;
|
|
|
|
|
__u64 page_size_cap;
|
|
|
|
|
__u32 vendor_id;
|
|
|
|
|
__u32 vendor_part_id;
|
|
|
|
|
__u32 hw_ver;
|
|
|
|
|
__u32 max_qp;
|
|
|
|
|
__u32 max_qp_wr;
|
|
|
|
|
__u32 device_cap_flags;
|
|
|
|
|
__u32 max_sge;
|
|
|
|
|
__u32 max_sge_rd;
|
|
|
|
|
__u32 max_cq;
|
|
|
|
|
__u32 max_cqe;
|
|
|
|
|
__u32 max_mr;
|
|
|
|
|
__u32 max_pd;
|
|
|
|
|
__u32 max_qp_rd_atom;
|
|
|
|
|
__u32 max_ee_rd_atom;
|
|
|
|
|
__u32 max_res_rd_atom;
|
|
|
|
|
__u32 max_qp_init_rd_atom;
|
|
|
|
|
__u32 max_ee_init_rd_atom;
|
|
|
|
|
__u32 atomic_cap;
|
|
|
|
|
__u32 max_ee;
|
|
|
|
|
__u32 max_rdd;
|
|
|
|
|
__u32 max_mw;
|
|
|
|
|
__u32 max_raw_ipv6_qp;
|
|
|
|
|
__u32 max_raw_ethy_qp;
|
|
|
|
|
__u32 max_mcast_grp;
|
|
|
|
|
__u32 max_mcast_qp_attach;
|
|
|
|
|
__u32 max_total_mcast_qp_attach;
|
|
|
|
|
__u32 max_ah;
|
|
|
|
|
__u32 max_fmr;
|
|
|
|
|
__u32 max_map_per_fmr;
|
|
|
|
|
__u32 max_srq;
|
|
|
|
|
__u32 max_srq_wr;
|
|
|
|
|
__u32 max_srq_sge;
|
|
|
|
|
__u16 max_pkeys;
|
|
|
|
|
__u8 local_ca_ack_delay;
|
|
|
|
|
__u8 phys_port_cnt;
|
|
|
|
|
__u8 reserved[4];
|
|
|
|
|
};
|
|
|
|
|
|
2015-02-08 11:28:50 +00:00
|
|
|
struct ib_uverbs_ex_query_device {
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
2015-02-08 11:28:51 +00:00
|
|
|
struct ib_uverbs_odp_caps {
|
|
|
|
|
__u64 general_caps;
|
|
|
|
|
struct {
|
|
|
|
|
__u32 rc_odp_caps;
|
|
|
|
|
__u32 uc_odp_caps;
|
|
|
|
|
__u32 ud_odp_caps;
|
|
|
|
|
} per_transport_caps;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
2015-02-08 11:28:50 +00:00
|
|
|
struct ib_uverbs_ex_query_device_resp {
|
|
|
|
|
struct ib_uverbs_query_device_resp base;
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 response_length;
|
2015-02-08 11:28:51 +00:00
|
|
|
struct ib_uverbs_odp_caps odp_caps;
|
2015-06-11 13:35:24 +00:00
|
|
|
__u64 timestamp_mask;
|
|
|
|
|
__u64 hca_core_clock; /* in KHZ */
|
2015-02-08 11:28:50 +00:00
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_query_port {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 reserved[7];
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_query_port_resp {
|
|
|
|
|
__u32 port_cap_flags;
|
|
|
|
|
__u32 max_msg_sz;
|
|
|
|
|
__u32 bad_pkey_cntr;
|
|
|
|
|
__u32 qkey_viol_cntr;
|
|
|
|
|
__u32 gid_tbl_len;
|
|
|
|
|
__u16 pkey_tbl_len;
|
|
|
|
|
__u16 lid;
|
|
|
|
|
__u16 sm_lid;
|
|
|
|
|
__u8 state;
|
|
|
|
|
__u8 max_mtu;
|
|
|
|
|
__u8 active_mtu;
|
|
|
|
|
__u8 lmc;
|
|
|
|
|
__u8 max_vl_num;
|
|
|
|
|
__u8 sm_sl;
|
|
|
|
|
__u8 subnet_timeout;
|
|
|
|
|
__u8 init_type_reply;
|
|
|
|
|
__u8 active_width;
|
|
|
|
|
__u8 active_speed;
|
|
|
|
|
__u8 phys_state;
|
2010-10-18 21:45:20 +00:00
|
|
|
__u8 link_layer;
|
|
|
|
|
__u8 reserved[2];
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_alloc_pd {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_alloc_pd_resp {
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_dealloc_pd {
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2011-05-24 15:33:46 +00:00
|
|
|
struct ib_uverbs_open_xrcd {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 fd;
|
|
|
|
|
__u32 oflags;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_open_xrcd_resp {
|
|
|
|
|
__u32 xrcd_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_close_xrcd {
|
|
|
|
|
__u32 xrcd_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_reg_mr {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 start;
|
|
|
|
|
__u64 length;
|
|
|
|
|
__u64 hca_va;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 access_flags;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_reg_mr_resp {
|
|
|
|
|
__u32 mr_handle;
|
|
|
|
|
__u32 lkey;
|
|
|
|
|
__u32 rkey;
|
|
|
|
|
};
|
|
|
|
|
|
2014-07-31 08:01:28 +00:00
|
|
|
struct ib_uverbs_rereg_mr {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 mr_handle;
|
|
|
|
|
__u32 flags;
|
|
|
|
|
__u64 start;
|
|
|
|
|
__u64 length;
|
|
|
|
|
__u64 hca_va;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 access_flags;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_rereg_mr_resp {
|
|
|
|
|
__u32 lkey;
|
|
|
|
|
__u32 rkey;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_dereg_mr {
|
|
|
|
|
__u32 mr_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2013-02-06 16:19:13 +00:00
|
|
|
struct ib_uverbs_alloc_mw {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u8 mw_type;
|
|
|
|
|
__u8 reserved[3];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_alloc_mw_resp {
|
|
|
|
|
__u32 mw_handle;
|
|
|
|
|
__u32 rkey;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_dealloc_mw {
|
|
|
|
|
__u32 mw_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2005-09-26 20:53:25 +00:00
|
|
|
struct ib_uverbs_create_comp_channel {
|
|
|
|
|
__u64 response;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_create_comp_channel_resp {
|
|
|
|
|
__u32 fd;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_create_cq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 cqe;
|
2005-09-26 20:53:25 +00:00
|
|
|
__u32 comp_vector;
|
|
|
|
|
__s32 comp_channel;
|
|
|
|
|
__u32 reserved;
|
2005-07-08 00:57:12 +00:00
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2015-06-11 13:35:23 +00:00
|
|
|
struct ib_uverbs_ex_create_cq {
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 cqe;
|
|
|
|
|
__u32 comp_vector;
|
|
|
|
|
__s32 comp_channel;
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 flags;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_create_cq_resp {
|
|
|
|
|
__u32 cq_handle;
|
|
|
|
|
__u32 cqe;
|
|
|
|
|
};
|
|
|
|
|
|
2015-06-11 13:35:23 +00:00
|
|
|
struct ib_uverbs_ex_create_cq_resp {
|
|
|
|
|
struct ib_uverbs_create_cq_resp base;
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 response_length;
|
|
|
|
|
};
|
|
|
|
|
|
2006-01-30 22:29:21 +00:00
|
|
|
struct ib_uverbs_resize_cq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 cq_handle;
|
|
|
|
|
__u32 cqe;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_resize_cq_resp {
|
|
|
|
|
__u32 cqe;
|
2006-09-22 22:22:24 +00:00
|
|
|
__u32 reserved;
|
|
|
|
|
__u64 driver_data[0];
|
2006-01-30 22:29:21 +00:00
|
|
|
};
|
|
|
|
|
|
2005-10-14 22:21:44 +00:00
|
|
|
struct ib_uverbs_poll_cq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 cq_handle;
|
|
|
|
|
__u32 ne;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_wc {
|
|
|
|
|
__u64 wr_id;
|
|
|
|
|
__u32 status;
|
|
|
|
|
__u32 opcode;
|
|
|
|
|
__u32 vendor_err;
|
|
|
|
|
__u32 byte_len;
|
2008-07-15 06:48:45 +00:00
|
|
|
union {
|
|
|
|
|
__u32 imm_data;
|
|
|
|
|
__u32 invalidate_rkey;
|
|
|
|
|
} ex;
|
2005-10-14 22:21:44 +00:00
|
|
|
__u32 qp_num;
|
|
|
|
|
__u32 src_qp;
|
|
|
|
|
__u32 wc_flags;
|
|
|
|
|
__u16 pkey_index;
|
|
|
|
|
__u16 slid;
|
|
|
|
|
__u8 sl;
|
|
|
|
|
__u8 dlid_path_bits;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_poll_cq_resp {
|
|
|
|
|
__u32 count;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
struct ib_uverbs_wc wc[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_req_notify_cq {
|
|
|
|
|
__u32 cq_handle;
|
|
|
|
|
__u32 solicited_only;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_destroy_cq {
|
2005-09-09 22:55:08 +00:00
|
|
|
__u64 response;
|
2005-07-08 00:57:12 +00:00
|
|
|
__u32 cq_handle;
|
2005-09-09 22:55:08 +00:00
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_cq_resp {
|
|
|
|
|
__u32 comp_events_reported;
|
|
|
|
|
__u32 async_events_reported;
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
2006-06-18 03:37:27 +00:00
|
|
|
struct ib_uverbs_global_route {
|
|
|
|
|
__u8 dgid[16];
|
|
|
|
|
__u32 flow_label;
|
|
|
|
|
__u8 sgid_index;
|
|
|
|
|
__u8 hop_limit;
|
|
|
|
|
__u8 traffic_class;
|
|
|
|
|
__u8 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_ah_attr {
|
|
|
|
|
struct ib_uverbs_global_route grh;
|
|
|
|
|
__u16 dlid;
|
|
|
|
|
__u8 sl;
|
|
|
|
|
__u8 src_path_bits;
|
|
|
|
|
__u8 static_rate;
|
|
|
|
|
__u8 is_global;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_qp_attr {
|
|
|
|
|
__u32 qp_attr_mask;
|
|
|
|
|
__u32 qp_state;
|
|
|
|
|
__u32 cur_qp_state;
|
|
|
|
|
__u32 path_mtu;
|
|
|
|
|
__u32 path_mig_state;
|
|
|
|
|
__u32 qkey;
|
|
|
|
|
__u32 rq_psn;
|
|
|
|
|
__u32 sq_psn;
|
|
|
|
|
__u32 dest_qp_num;
|
|
|
|
|
__u32 qp_access_flags;
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_ah_attr ah_attr;
|
|
|
|
|
struct ib_uverbs_ah_attr alt_ah_attr;
|
|
|
|
|
|
|
|
|
|
/* ib_qp_cap */
|
|
|
|
|
__u32 max_send_wr;
|
|
|
|
|
__u32 max_recv_wr;
|
|
|
|
|
__u32 max_send_sge;
|
|
|
|
|
__u32 max_recv_sge;
|
|
|
|
|
__u32 max_inline_data;
|
|
|
|
|
|
|
|
|
|
__u16 pkey_index;
|
|
|
|
|
__u16 alt_pkey_index;
|
|
|
|
|
__u8 en_sqd_async_notify;
|
|
|
|
|
__u8 sq_draining;
|
|
|
|
|
__u8 max_rd_atomic;
|
|
|
|
|
__u8 max_dest_rd_atomic;
|
|
|
|
|
__u8 min_rnr_timer;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 timeout;
|
|
|
|
|
__u8 retry_cnt;
|
|
|
|
|
__u8 rnr_retry;
|
|
|
|
|
__u8 alt_port_num;
|
|
|
|
|
__u8 alt_timeout;
|
|
|
|
|
__u8 reserved[5];
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_create_qp {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 send_cq_handle;
|
|
|
|
|
__u32 recv_cq_handle;
|
|
|
|
|
__u32 srq_handle;
|
|
|
|
|
__u32 max_send_wr;
|
|
|
|
|
__u32 max_recv_wr;
|
|
|
|
|
__u32 max_send_sge;
|
|
|
|
|
__u32 max_recv_sge;
|
|
|
|
|
__u32 max_inline_data;
|
|
|
|
|
__u8 sq_sig_all;
|
|
|
|
|
__u8 qp_type;
|
|
|
|
|
__u8 is_srq;
|
|
|
|
|
__u8 reserved;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2015-10-21 14:00:42 +00:00
|
|
|
struct ib_uverbs_ex_create_qp {
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 send_cq_handle;
|
|
|
|
|
__u32 recv_cq_handle;
|
|
|
|
|
__u32 srq_handle;
|
|
|
|
|
__u32 max_send_wr;
|
|
|
|
|
__u32 max_recv_wr;
|
|
|
|
|
__u32 max_send_sge;
|
|
|
|
|
__u32 max_recv_sge;
|
|
|
|
|
__u32 max_inline_data;
|
|
|
|
|
__u8 sq_sig_all;
|
|
|
|
|
__u8 qp_type;
|
|
|
|
|
__u8 is_srq;
|
|
|
|
|
__u8 reserved;
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 create_flags;
|
|
|
|
|
};
|
|
|
|
|
|
2011-08-11 20:57:43 +00:00
|
|
|
struct ib_uverbs_open_qp {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 qpn;
|
|
|
|
|
__u8 qp_type;
|
|
|
|
|
__u8 reserved[7];
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* also used for open response */
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_create_qp_resp {
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u32 qpn;
|
2005-11-09 19:26:07 +00:00
|
|
|
__u32 max_send_wr;
|
|
|
|
|
__u32 max_recv_wr;
|
|
|
|
|
__u32 max_send_sge;
|
|
|
|
|
__u32 max_recv_sge;
|
|
|
|
|
__u32 max_inline_data;
|
2006-02-16 17:26:19 +00:00
|
|
|
__u32 reserved;
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
2015-10-21 14:00:42 +00:00
|
|
|
struct ib_uverbs_ex_create_qp_resp {
|
|
|
|
|
struct ib_uverbs_create_qp_resp base;
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 response_length;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
/*
|
|
|
|
|
* This struct needs to remain a multiple of 8 bytes to keep the
|
|
|
|
|
* alignment of the modify QP parameters.
|
|
|
|
|
*/
|
|
|
|
|
struct ib_uverbs_qp_dest {
|
|
|
|
|
__u8 dgid[16];
|
|
|
|
|
__u32 flow_label;
|
|
|
|
|
__u16 dlid;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
__u8 sgid_index;
|
|
|
|
|
__u8 hop_limit;
|
|
|
|
|
__u8 traffic_class;
|
|
|
|
|
__u8 sl;
|
|
|
|
|
__u8 src_path_bits;
|
|
|
|
|
__u8 static_rate;
|
|
|
|
|
__u8 is_global;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
};
|
|
|
|
|
|
2006-02-14 00:31:25 +00:00
|
|
|
struct ib_uverbs_query_qp {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u32 attr_mask;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_query_qp_resp {
|
|
|
|
|
struct ib_uverbs_qp_dest dest;
|
|
|
|
|
struct ib_uverbs_qp_dest alt_dest;
|
|
|
|
|
__u32 max_send_wr;
|
|
|
|
|
__u32 max_recv_wr;
|
|
|
|
|
__u32 max_send_sge;
|
|
|
|
|
__u32 max_recv_sge;
|
|
|
|
|
__u32 max_inline_data;
|
|
|
|
|
__u32 qkey;
|
|
|
|
|
__u32 rq_psn;
|
|
|
|
|
__u32 sq_psn;
|
|
|
|
|
__u32 dest_qp_num;
|
|
|
|
|
__u32 qp_access_flags;
|
|
|
|
|
__u16 pkey_index;
|
|
|
|
|
__u16 alt_pkey_index;
|
|
|
|
|
__u8 qp_state;
|
|
|
|
|
__u8 cur_qp_state;
|
|
|
|
|
__u8 path_mtu;
|
|
|
|
|
__u8 path_mig_state;
|
2006-10-25 10:54:20 +00:00
|
|
|
__u8 sq_draining;
|
2006-02-14 00:31:25 +00:00
|
|
|
__u8 max_rd_atomic;
|
|
|
|
|
__u8 max_dest_rd_atomic;
|
|
|
|
|
__u8 min_rnr_timer;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 timeout;
|
|
|
|
|
__u8 retry_cnt;
|
|
|
|
|
__u8 rnr_retry;
|
|
|
|
|
__u8 alt_port_num;
|
|
|
|
|
__u8 alt_timeout;
|
|
|
|
|
__u8 sq_sig_all;
|
|
|
|
|
__u8 reserved[5];
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_modify_qp {
|
|
|
|
|
struct ib_uverbs_qp_dest dest;
|
|
|
|
|
struct ib_uverbs_qp_dest alt_dest;
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u32 attr_mask;
|
|
|
|
|
__u32 qkey;
|
|
|
|
|
__u32 rq_psn;
|
|
|
|
|
__u32 sq_psn;
|
|
|
|
|
__u32 dest_qp_num;
|
|
|
|
|
__u32 qp_access_flags;
|
|
|
|
|
__u16 pkey_index;
|
|
|
|
|
__u16 alt_pkey_index;
|
|
|
|
|
__u8 qp_state;
|
|
|
|
|
__u8 cur_qp_state;
|
|
|
|
|
__u8 path_mtu;
|
|
|
|
|
__u8 path_mig_state;
|
|
|
|
|
__u8 en_sqd_async_notify;
|
|
|
|
|
__u8 max_rd_atomic;
|
|
|
|
|
__u8 max_dest_rd_atomic;
|
|
|
|
|
__u8 min_rnr_timer;
|
|
|
|
|
__u8 port_num;
|
|
|
|
|
__u8 timeout;
|
|
|
|
|
__u8 retry_cnt;
|
|
|
|
|
__u8 rnr_retry;
|
|
|
|
|
__u8 alt_port_num;
|
|
|
|
|
__u8 alt_timeout;
|
|
|
|
|
__u8 reserved[2];
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_modify_qp_resp {
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_qp {
|
2005-09-09 22:55:08 +00:00
|
|
|
__u64 response;
|
2005-07-08 00:57:12 +00:00
|
|
|
__u32 qp_handle;
|
2005-09-09 22:55:08 +00:00
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_qp_resp {
|
|
|
|
|
__u32 events_reported;
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
2005-10-14 22:21:44 +00:00
|
|
|
/*
|
|
|
|
|
* The ib_uverbs_sge structure isn't used anywhere, since we assume
|
|
|
|
|
* the ib_sge structure is packed the same way on 32-bit and 64-bit
|
|
|
|
|
* architectures in both kernel and user space. It's just here to
|
|
|
|
|
* document the ABI.
|
|
|
|
|
*/
|
|
|
|
|
struct ib_uverbs_sge {
|
|
|
|
|
__u64 addr;
|
|
|
|
|
__u32 length;
|
|
|
|
|
__u32 lkey;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_send_wr {
|
2006-02-14 00:30:49 +00:00
|
|
|
__u64 wr_id;
|
2005-10-14 22:21:44 +00:00
|
|
|
__u32 num_sge;
|
|
|
|
|
__u32 opcode;
|
|
|
|
|
__u32 send_flags;
|
2008-04-17 04:09:32 +00:00
|
|
|
union {
|
|
|
|
|
__u32 imm_data;
|
|
|
|
|
__u32 invalidate_rkey;
|
|
|
|
|
} ex;
|
2005-10-14 22:21:44 +00:00
|
|
|
union {
|
|
|
|
|
struct {
|
|
|
|
|
__u64 remote_addr;
|
|
|
|
|
__u32 rkey;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
} rdma;
|
|
|
|
|
struct {
|
|
|
|
|
__u64 remote_addr;
|
|
|
|
|
__u64 compare_add;
|
|
|
|
|
__u64 swap;
|
|
|
|
|
__u32 rkey;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
} atomic;
|
|
|
|
|
struct {
|
|
|
|
|
__u32 ah;
|
|
|
|
|
__u32 remote_qpn;
|
|
|
|
|
__u32 remote_qkey;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
} ud;
|
|
|
|
|
} wr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_send {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u32 wr_count;
|
|
|
|
|
__u32 sge_count;
|
|
|
|
|
__u32 wqe_size;
|
|
|
|
|
struct ib_uverbs_send_wr send_wr[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_send_resp {
|
|
|
|
|
__u32 bad_wr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_recv_wr {
|
|
|
|
|
__u64 wr_id;
|
|
|
|
|
__u32 num_sge;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_recv {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u32 wr_count;
|
|
|
|
|
__u32 sge_count;
|
|
|
|
|
__u32 wqe_size;
|
|
|
|
|
struct ib_uverbs_recv_wr recv_wr[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_recv_resp {
|
|
|
|
|
__u32 bad_wr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_srq_recv {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 srq_handle;
|
|
|
|
|
__u32 wr_count;
|
|
|
|
|
__u32 sge_count;
|
|
|
|
|
__u32 wqe_size;
|
|
|
|
|
struct ib_uverbs_recv_wr recv[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_post_srq_recv_resp {
|
|
|
|
|
__u32 bad_wr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_create_ah {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
struct ib_uverbs_ah_attr attr;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_create_ah_resp {
|
|
|
|
|
__u32 ah_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_ah {
|
|
|
|
|
__u32 ah_handle;
|
|
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
struct ib_uverbs_attach_mcast {
|
|
|
|
|
__u8 gid[16];
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u16 mlid;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_detach_mcast {
|
|
|
|
|
__u8 gid[16];
|
|
|
|
|
__u32 qp_handle;
|
|
|
|
|
__u16 mlid;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
__u64 driver_data[0];
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:47 +00:00
|
|
|
struct ib_uverbs_flow_spec_hdr {
|
|
|
|
|
__u32 type;
|
|
|
|
|
__u16 size;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
/* followed by flow_spec */
|
|
|
|
|
__u64 flow_spec_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_eth_filter {
|
2013-08-14 10:58:30 +00:00
|
|
|
__u8 dst_mac[6];
|
|
|
|
|
__u8 src_mac[6];
|
|
|
|
|
__be16 ether_type;
|
|
|
|
|
__be16 vlan_tag;
|
|
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_spec_eth {
|
2013-11-06 22:21:47 +00:00
|
|
|
union {
|
|
|
|
|
struct ib_uverbs_flow_spec_hdr hdr;
|
|
|
|
|
struct {
|
|
|
|
|
__u32 type;
|
|
|
|
|
__u16 size;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
};
|
|
|
|
|
};
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_eth_filter val;
|
|
|
|
|
struct ib_uverbs_flow_eth_filter mask;
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_ipv4_filter {
|
2013-08-14 10:58:30 +00:00
|
|
|
__be32 src_ip;
|
|
|
|
|
__be32 dst_ip;
|
|
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_spec_ipv4 {
|
2013-11-06 22:21:47 +00:00
|
|
|
union {
|
|
|
|
|
struct ib_uverbs_flow_spec_hdr hdr;
|
|
|
|
|
struct {
|
|
|
|
|
__u32 type;
|
|
|
|
|
__u16 size;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
};
|
|
|
|
|
};
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_ipv4_filter val;
|
|
|
|
|
struct ib_uverbs_flow_ipv4_filter mask;
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_tcp_udp_filter {
|
2013-08-14 10:58:30 +00:00
|
|
|
__be16 dst_port;
|
|
|
|
|
__be16 src_port;
|
|
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_spec_tcp_udp {
|
2013-11-06 22:21:47 +00:00
|
|
|
union {
|
|
|
|
|
struct ib_uverbs_flow_spec_hdr hdr;
|
|
|
|
|
struct {
|
|
|
|
|
__u32 type;
|
|
|
|
|
__u16 size;
|
|
|
|
|
__u16 reserved;
|
|
|
|
|
};
|
|
|
|
|
};
|
2013-11-06 22:21:46 +00:00
|
|
|
struct ib_uverbs_flow_tcp_udp_filter val;
|
|
|
|
|
struct ib_uverbs_flow_tcp_udp_filter mask;
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
2013-11-06 22:21:45 +00:00
|
|
|
struct ib_uverbs_flow_attr {
|
2013-08-14 10:58:30 +00:00
|
|
|
__u32 type;
|
|
|
|
|
__u16 size;
|
|
|
|
|
__u16 priority;
|
|
|
|
|
__u8 num_of_specs;
|
|
|
|
|
__u8 reserved[2];
|
|
|
|
|
__u8 port;
|
|
|
|
|
__u32 flags;
|
|
|
|
|
/* Following are the optional layers according to user request
|
|
|
|
|
* struct ib_flow_spec_xxx
|
|
|
|
|
* struct ib_flow_spec_yyy
|
|
|
|
|
*/
|
2013-11-06 22:21:47 +00:00
|
|
|
struct ib_uverbs_flow_spec_hdr flow_specs[0];
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_create_flow {
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 qp_handle;
|
2013-11-06 22:21:45 +00:00
|
|
|
struct ib_uverbs_flow_attr flow_attr;
|
2013-08-14 10:58:30 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_create_flow_resp {
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 flow_handle;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_flow {
|
|
|
|
|
__u32 comp_mask;
|
|
|
|
|
__u32 flow_handle;
|
2005-07-08 00:57:12 +00:00
|
|
|
};
|
|
|
|
|
|
2005-08-18 19:24:13 +00:00
|
|
|
struct ib_uverbs_create_srq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 max_wr;
|
|
|
|
|
__u32 max_sge;
|
|
|
|
|
__u32 srq_limit;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2011-05-26 00:08:38 +00:00
|
|
|
struct ib_uverbs_create_xsrq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u64 user_handle;
|
|
|
|
|
__u32 srq_type;
|
|
|
|
|
__u32 pd_handle;
|
|
|
|
|
__u32 max_wr;
|
|
|
|
|
__u32 max_sge;
|
|
|
|
|
__u32 srq_limit;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
__u32 xrcd_handle;
|
|
|
|
|
__u32 cq_handle;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2005-08-18 19:24:13 +00:00
|
|
|
struct ib_uverbs_create_srq_resp {
|
|
|
|
|
__u32 srq_handle;
|
2006-02-23 20:36:18 +00:00
|
|
|
__u32 max_wr;
|
|
|
|
|
__u32 max_sge;
|
2011-05-26 00:08:38 +00:00
|
|
|
__u32 srqn;
|
2005-08-18 19:24:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_modify_srq {
|
|
|
|
|
__u32 srq_handle;
|
|
|
|
|
__u32 attr_mask;
|
|
|
|
|
__u32 max_wr;
|
|
|
|
|
__u32 srq_limit;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
2006-02-14 00:31:57 +00:00
|
|
|
struct ib_uverbs_query_srq {
|
|
|
|
|
__u64 response;
|
|
|
|
|
__u32 srq_handle;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
__u64 driver_data[0];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_query_srq_resp {
|
|
|
|
|
__u32 max_wr;
|
|
|
|
|
__u32 max_sge;
|
|
|
|
|
__u32 srq_limit;
|
|
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
2005-08-18 19:24:13 +00:00
|
|
|
struct ib_uverbs_destroy_srq {
|
2005-09-09 22:55:08 +00:00
|
|
|
__u64 response;
|
2005-08-18 19:24:13 +00:00
|
|
|
__u32 srq_handle;
|
2005-09-09 22:55:08 +00:00
|
|
|
__u32 reserved;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_destroy_srq_resp {
|
|
|
|
|
__u32 events_reported;
|
2005-08-18 19:24:13 +00:00
|
|
|
};
|
|
|
|
|
|
2005-07-08 00:57:12 +00:00
|
|
|
#endif /* IB_USER_VERBS_H */
|
