2005-07-08 08:57:13 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2005 Topspin Communications. All rights reserved.
|
2006-01-31 06:29:21 +08:00
|
|
|
* Copyright (c) 2005, 2006 Cisco Systems. All rights reserved.
|
2005-08-11 14:03:10 +08:00
|
|
|
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
|
|
|
|
* Copyright (c) 2005 Voltaire, Inc. All rights reserved.
|
2005-10-15 06:26:04 +08:00
|
|
|
* Copyright (c) 2005 PathScale, Inc. All rights reserved.
|
2005-07-08 08:57:13 +08: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 UVERBS_H
|
|
|
|
#define UVERBS_H
|
|
|
|
|
|
|
|
#include <linux/kref.h>
|
|
|
|
#include <linux/idr.h>
|
2006-01-14 06:51:39 +08:00
|
|
|
#include <linux/mutex.h>
|
2006-08-04 01:56:42 +08:00
|
|
|
#include <linux/completion.h>
|
2010-02-03 03:07:49 +08:00
|
|
|
#include <linux/cdev.h>
|
2005-07-08 08:57:13 +08:00
|
|
|
|
2005-08-26 04:40:04 +08:00
|
|
|
#include <rdma/ib_verbs.h>
|
2007-03-05 08:15:11 +08:00
|
|
|
#include <rdma/ib_umem.h>
|
2005-08-26 04:40:04 +08:00
|
|
|
#include <rdma/ib_user_verbs.h>
|
2005-07-08 08:57:13 +08:00
|
|
|
|
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-07 06:21:49 +08:00
|
|
|
#define INIT_UDATA(udata, ibuf, obuf, ilen, olen) \
|
|
|
|
do { \
|
2013-12-12 06:01:44 +08:00
|
|
|
(udata)->inbuf = (const void __user *) (ibuf); \
|
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-07 06:21:49 +08:00
|
|
|
(udata)->outbuf = (void __user *) (obuf); \
|
|
|
|
(udata)->inlen = (ilen); \
|
|
|
|
(udata)->outlen = (olen); \
|
|
|
|
} while (0)
|
|
|
|
|
2013-12-20 00:37:03 +08:00
|
|
|
#define INIT_UDATA_BUF_OR_NULL(udata, ibuf, obuf, ilen, olen) \
|
|
|
|
do { \
|
|
|
|
(udata)->inbuf = (ilen) ? (const void __user *) (ibuf) : NULL; \
|
|
|
|
(udata)->outbuf = (olen) ? (void __user *) (obuf) : NULL; \
|
|
|
|
(udata)->inlen = (ilen); \
|
|
|
|
(udata)->outlen = (olen); \
|
|
|
|
} while (0)
|
|
|
|
|
2005-10-29 06:38:26 +08:00
|
|
|
/*
|
|
|
|
* Our lifetime rules for these structs are the following:
|
|
|
|
*
|
|
|
|
* struct ib_uverbs_device: One reference is held by the module and
|
|
|
|
* released in ib_uverbs_remove_one(). Another reference is taken by
|
|
|
|
* ib_uverbs_open() each time the character special file is opened,
|
|
|
|
* and released in ib_uverbs_release_file() when the file is released.
|
|
|
|
*
|
|
|
|
* struct ib_uverbs_file: One reference is held by the VFS and
|
|
|
|
* released when the file is closed. Another reference is taken when
|
|
|
|
* an asynchronous event queue file is created and released when the
|
|
|
|
* event file is closed.
|
|
|
|
*
|
|
|
|
* struct ib_uverbs_event_file: One reference is held by the VFS and
|
|
|
|
* released when the file is closed. For asynchronous event files,
|
|
|
|
* another reference is held by the corresponding main context file
|
|
|
|
* and released when that file is closed. For completion event files,
|
|
|
|
* a reference is taken when a CQ is created that uses the file, and
|
|
|
|
* released when the CQ is destroyed.
|
|
|
|
*/
|
|
|
|
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_uverbs_device {
|
2015-08-13 23:32:03 +08:00
|
|
|
atomic_t refcount;
|
2010-02-03 03:07:49 +08:00
|
|
|
int num_comp_vectors;
|
2006-08-04 01:56:42 +08:00
|
|
|
struct completion comp;
|
2008-02-22 07:13:36 +08:00
|
|
|
struct device *dev;
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_device *ib_dev;
|
2010-02-03 03:07:49 +08:00
|
|
|
int devnum;
|
|
|
|
struct cdev cdev;
|
2011-05-24 23:33:46 +08:00
|
|
|
struct rb_root xrcd_tree;
|
|
|
|
struct mutex xrcd_tree_mutex;
|
2015-08-13 23:32:03 +08:00
|
|
|
struct kobject kobj;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ib_uverbs_event_file {
|
|
|
|
struct kref ref;
|
2010-02-03 03:08:14 +08:00
|
|
|
int is_async;
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_uverbs_file *uverbs_file;
|
|
|
|
spinlock_t lock;
|
2010-02-03 03:08:14 +08:00
|
|
|
int is_closed;
|
2005-07-08 08:57:13 +08:00
|
|
|
wait_queue_head_t poll_wait;
|
2005-07-28 05:40:00 +08:00
|
|
|
struct fasync_struct *async_queue;
|
2005-07-08 08:57:13 +08:00
|
|
|
struct list_head event_list;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ib_uverbs_file {
|
|
|
|
struct kref ref;
|
2006-01-14 06:51:39 +08:00
|
|
|
struct mutex mutex;
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_uverbs_device *device;
|
|
|
|
struct ib_ucontext *ucontext;
|
|
|
|
struct ib_event_handler event_handler;
|
2005-09-27 04:53:25 +08:00
|
|
|
struct ib_uverbs_event_file *async_file;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
2005-09-10 06:55:08 +08:00
|
|
|
struct ib_uverbs_event {
|
|
|
|
union {
|
|
|
|
struct ib_uverbs_async_event_desc async;
|
|
|
|
struct ib_uverbs_comp_event_desc comp;
|
|
|
|
} desc;
|
2005-07-08 08:57:13 +08:00
|
|
|
struct list_head list;
|
2005-09-10 06:55:08 +08:00
|
|
|
struct list_head obj_list;
|
|
|
|
u32 *counter;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
2005-11-30 08:57:01 +08:00
|
|
|
struct ib_uverbs_mcast_entry {
|
|
|
|
struct list_head list;
|
|
|
|
union ib_gid gid;
|
|
|
|
u16 lid;
|
|
|
|
};
|
|
|
|
|
2005-09-10 06:55:08 +08:00
|
|
|
struct ib_uevent_object {
|
|
|
|
struct ib_uobject uobject;
|
|
|
|
struct list_head event_list;
|
|
|
|
u32 events_reported;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
2011-05-24 23:33:46 +08:00
|
|
|
struct ib_uxrcd_object {
|
|
|
|
struct ib_uobject uobject;
|
|
|
|
atomic_t refcnt;
|
|
|
|
};
|
|
|
|
|
2011-05-26 08:08:38 +08:00
|
|
|
struct ib_usrq_object {
|
|
|
|
struct ib_uevent_object uevent;
|
|
|
|
struct ib_uxrcd_object *uxrcd;
|
|
|
|
};
|
|
|
|
|
2005-11-30 08:57:01 +08:00
|
|
|
struct ib_uqp_object {
|
|
|
|
struct ib_uevent_object uevent;
|
|
|
|
struct list_head mcast_list;
|
2013-08-01 23:49:54 +08:00
|
|
|
struct ib_uxrcd_object *uxrcd;
|
2005-11-30 08:57:01 +08:00
|
|
|
};
|
|
|
|
|
2005-09-10 06:55:08 +08:00
|
|
|
struct ib_ucq_object {
|
|
|
|
struct ib_uobject uobject;
|
2005-10-31 01:50:04 +08:00
|
|
|
struct ib_uverbs_file *uverbs_file;
|
2005-09-10 06:55:08 +08:00
|
|
|
struct list_head comp_list;
|
|
|
|
struct list_head async_list;
|
|
|
|
u32 comp_events_reported;
|
|
|
|
u32 async_events_reported;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 11:44:49 +08:00
|
|
|
extern spinlock_t ib_uverbs_idr_lock;
|
2005-07-08 08:57:13 +08:00
|
|
|
extern struct idr ib_uverbs_pd_idr;
|
|
|
|
extern struct idr ib_uverbs_mr_idr;
|
|
|
|
extern struct idr ib_uverbs_mw_idr;
|
|
|
|
extern struct idr ib_uverbs_ah_idr;
|
|
|
|
extern struct idr ib_uverbs_cq_idr;
|
|
|
|
extern struct idr ib_uverbs_qp_idr;
|
2005-08-19 03:24:13 +08:00
|
|
|
extern struct idr ib_uverbs_srq_idr;
|
2011-05-24 23:33:46 +08:00
|
|
|
extern struct idr ib_uverbs_xrcd_idr;
|
2013-08-14 18:58:30 +08:00
|
|
|
extern struct idr ib_uverbs_rule_idr;
|
2005-07-08 08:57:13 +08:00
|
|
|
|
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2006-06-18 11:44:49 +08:00
|
|
|
void idr_remove_uobj(struct idr *idp, struct ib_uobject *uobj);
|
|
|
|
|
2005-09-27 04:53:25 +08:00
|
|
|
struct file *ib_uverbs_alloc_event_file(struct ib_uverbs_file *uverbs_file,
|
2015-08-13 23:32:04 +08:00
|
|
|
struct ib_device *ib_dev,
|
2010-01-18 14:38:00 +08:00
|
|
|
int is_async);
|
2015-08-13 23:32:02 +08:00
|
|
|
void ib_uverbs_free_async_event_file(struct ib_uverbs_file *uverbs_file);
|
2005-09-27 04:53:25 +08:00
|
|
|
struct ib_uverbs_event_file *ib_uverbs_lookup_comp_file(int fd);
|
|
|
|
|
2005-10-29 06:38:26 +08:00
|
|
|
void ib_uverbs_release_ucq(struct ib_uverbs_file *file,
|
|
|
|
struct ib_uverbs_event_file *ev_file,
|
|
|
|
struct ib_ucq_object *uobj);
|
|
|
|
void ib_uverbs_release_uevent(struct ib_uverbs_file *file,
|
|
|
|
struct ib_uevent_object *uobj);
|
|
|
|
|
2005-07-08 08:57:13 +08:00
|
|
|
void ib_uverbs_comp_handler(struct ib_cq *cq, void *cq_context);
|
|
|
|
void ib_uverbs_cq_event_handler(struct ib_event *event, void *context_ptr);
|
|
|
|
void ib_uverbs_qp_event_handler(struct ib_event *event, void *context_ptr);
|
2005-08-19 03:24:13 +08:00
|
|
|
void ib_uverbs_srq_event_handler(struct ib_event *event, void *context_ptr);
|
2005-09-27 04:53:25 +08:00
|
|
|
void ib_uverbs_event_handler(struct ib_event_handler *handler,
|
|
|
|
struct ib_event *event);
|
2011-05-24 23:33:46 +08:00
|
|
|
void ib_uverbs_dealloc_xrcd(struct ib_uverbs_device *dev, struct ib_xrcd *xrcd);
|
2005-07-08 08:57:13 +08:00
|
|
|
|
2013-11-07 06:21:48 +08:00
|
|
|
struct ib_uverbs_flow_spec {
|
|
|
|
union {
|
|
|
|
union {
|
|
|
|
struct ib_uverbs_flow_spec_hdr hdr;
|
|
|
|
struct {
|
|
|
|
__u32 type;
|
|
|
|
__u16 size;
|
|
|
|
__u16 reserved;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
struct ib_uverbs_flow_spec_eth eth;
|
|
|
|
struct ib_uverbs_flow_spec_ipv4 ipv4;
|
|
|
|
struct ib_uverbs_flow_spec_tcp_udp tcp_udp;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2005-07-08 08:57:13 +08:00
|
|
|
#define IB_UVERBS_DECLARE_CMD(name) \
|
|
|
|
ssize_t ib_uverbs_##name(struct ib_uverbs_file *file, \
|
2015-08-13 23:32:04 +08:00
|
|
|
struct ib_device *ib_dev, \
|
2005-07-08 08:57:13 +08:00
|
|
|
const char __user *buf, int in_len, \
|
|
|
|
int out_len)
|
|
|
|
|
|
|
|
IB_UVERBS_DECLARE_CMD(get_context);
|
|
|
|
IB_UVERBS_DECLARE_CMD(query_device);
|
|
|
|
IB_UVERBS_DECLARE_CMD(query_port);
|
|
|
|
IB_UVERBS_DECLARE_CMD(alloc_pd);
|
|
|
|
IB_UVERBS_DECLARE_CMD(dealloc_pd);
|
|
|
|
IB_UVERBS_DECLARE_CMD(reg_mr);
|
2014-07-31 16:01:28 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(rereg_mr);
|
2005-07-08 08:57:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(dereg_mr);
|
2013-02-07 00:19:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(alloc_mw);
|
|
|
|
IB_UVERBS_DECLARE_CMD(dealloc_mw);
|
2005-09-27 04:53:25 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(create_comp_channel);
|
2005-07-08 08:57:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(create_cq);
|
2006-01-31 06:29:21 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(resize_cq);
|
2005-10-15 06:26:04 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(poll_cq);
|
|
|
|
IB_UVERBS_DECLARE_CMD(req_notify_cq);
|
2005-07-08 08:57:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(destroy_cq);
|
|
|
|
IB_UVERBS_DECLARE_CMD(create_qp);
|
2011-08-12 04:57:43 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(open_qp);
|
2006-02-14 08:31:25 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(query_qp);
|
2005-07-08 08:57:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(modify_qp);
|
|
|
|
IB_UVERBS_DECLARE_CMD(destroy_qp);
|
2005-10-15 06:26:04 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(post_send);
|
|
|
|
IB_UVERBS_DECLARE_CMD(post_recv);
|
|
|
|
IB_UVERBS_DECLARE_CMD(post_srq_recv);
|
|
|
|
IB_UVERBS_DECLARE_CMD(create_ah);
|
|
|
|
IB_UVERBS_DECLARE_CMD(destroy_ah);
|
2005-07-08 08:57:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(attach_mcast);
|
|
|
|
IB_UVERBS_DECLARE_CMD(detach_mcast);
|
2005-08-19 03:24:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(create_srq);
|
|
|
|
IB_UVERBS_DECLARE_CMD(modify_srq);
|
2006-02-14 08:31:57 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(query_srq);
|
2005-08-19 03:24:13 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(destroy_srq);
|
2011-05-26 08:08:38 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(create_xsrq);
|
2011-05-24 23:33:46 +08:00
|
|
|
IB_UVERBS_DECLARE_CMD(open_xrcd);
|
|
|
|
IB_UVERBS_DECLARE_CMD(close_xrcd);
|
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-07 06:21:49 +08:00
|
|
|
|
|
|
|
#define IB_UVERBS_DECLARE_EX_CMD(name) \
|
|
|
|
int ib_uverbs_ex_##name(struct ib_uverbs_file *file, \
|
2015-08-13 23:32:04 +08:00
|
|
|
struct ib_device *ib_dev, \
|
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-07 06:21:49 +08:00
|
|
|
struct ib_udata *ucore, \
|
|
|
|
struct ib_udata *uhw)
|
|
|
|
|
|
|
|
IB_UVERBS_DECLARE_EX_CMD(create_flow);
|
|
|
|
IB_UVERBS_DECLARE_EX_CMD(destroy_flow);
|
2015-02-08 19:28:50 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(query_device);
|
2015-06-11 21:35:23 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(create_cq);
|
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-07 06:21:49 +08:00
|
|
|
|
2005-07-08 08:57:13 +08:00
|
|
|
#endif /* UVERBS_H */
|