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>
|
2018-03-19 21:02:37 +08:00
|
|
|
#include <rdma/uverbs_std_types.h>
|
2005-07-08 08:57:13 +08:00
|
|
|
|
2018-03-19 21:02:33 +08:00
|
|
|
#define UVERBS_MODULE_NAME ib_uverbs
|
|
|
|
|
#include <rdma/uverbs_named_ioctl.h>
|
|
|
|
|
|
2017-09-07 05:34:26 +08:00
|
|
|
static inline void
|
|
|
|
|
ib_uverbs_init_udata(struct ib_udata *udata,
|
|
|
|
|
const void __user *ibuf,
|
|
|
|
|
void __user *obuf,
|
|
|
|
|
size_t ilen, size_t olen)
|
|
|
|
|
{
|
|
|
|
|
udata->inbuf = ibuf;
|
|
|
|
|
udata->outbuf = obuf;
|
|
|
|
|
udata->inlen = ilen;
|
|
|
|
|
udata->outlen = olen;
|
|
|
|
|
}
|
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
|
|
|
|
2017-09-07 05:34:25 +08:00
|
|
|
static inline void
|
|
|
|
|
ib_uverbs_init_udata_buf_or_null(struct ib_udata *udata,
|
|
|
|
|
const void __user *ibuf,
|
|
|
|
|
void __user *obuf,
|
|
|
|
|
size_t ilen, size_t olen)
|
|
|
|
|
{
|
2017-09-07 05:34:26 +08:00
|
|
|
ib_uverbs_init_udata(udata,
|
|
|
|
|
ilen ? ibuf : NULL, olen ? obuf : NULL,
|
|
|
|
|
ilen, olen);
|
2017-09-07 05:34:25 +08:00
|
|
|
}
|
2013-12-20 00:37:03 +08:00
|
|
|
|
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.
|
|
|
|
|
*
|
2017-04-18 17:03:42 +08:00
|
|
|
* struct ib_uverbs_event_queue: Base structure for
|
|
|
|
|
* struct ib_uverbs_async_event_file and struct ib_uverbs_completion_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-10-29 06:38:26 +08:00
|
|
|
*/
|
|
|
|
|
|
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;
|
2015-08-13 23:32:05 +08:00
|
|
|
struct ib_device __rcu *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;
|
2015-08-13 23:32:05 +08:00
|
|
|
struct srcu_struct disassociate_srcu;
|
|
|
|
|
struct mutex lists_mutex; /* protect lists */
|
|
|
|
|
struct list_head uverbs_file_list;
|
|
|
|
|
struct list_head uverbs_events_file_list;
|
2017-08-03 21:07:06 +08:00
|
|
|
struct uverbs_root_spec *specs_root;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
|
2017-04-18 17:03:42 +08:00
|
|
|
struct ib_uverbs_event_queue {
|
2005-07-08 08:57:13 +08:00
|
|
|
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;
|
2017-04-04 18:31:47 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ib_uverbs_async_event_file {
|
2017-04-18 17:03:42 +08:00
|
|
|
struct ib_uverbs_event_queue ev_queue;
|
2017-04-04 18:31:47 +08:00
|
|
|
struct ib_uverbs_file *uverbs_file;
|
|
|
|
|
struct kref ref;
|
2015-08-13 23:32:05 +08:00
|
|
|
struct list_head list;
|
2005-07-08 08:57:13 +08:00
|
|
|
};
|
|
|
|
|
|
2017-04-04 18:31:47 +08:00
|
|
|
struct ib_uverbs_completion_event_file {
|
|
|
|
|
struct ib_uobject_file uobj_file;
|
2017-04-18 17:03:42 +08:00
|
|
|
struct ib_uverbs_event_queue ev_queue;
|
2017-04-04 18:31:47 +08:00
|
|
|
};
|
|
|
|
|
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_uverbs_file {
|
|
|
|
|
struct kref ref;
|
2006-01-14 06:51:39 +08:00
|
|
|
struct mutex mutex;
|
2016-07-03 20:28:18 +08:00
|
|
|
struct mutex cleanup_mutex; /* protect cleanup */
|
2005-07-08 08:57:13 +08:00
|
|
|
struct ib_uverbs_device *device;
|
|
|
|
|
struct ib_ucontext *ucontext;
|
|
|
|
|
struct ib_event_handler event_handler;
|
2017-04-04 18:31:47 +08:00
|
|
|
struct ib_uverbs_async_event_file *async_file;
|
2015-08-13 23:32:05 +08:00
|
|
|
struct list_head list;
|
|
|
|
|
int is_closed;
|
2017-04-04 18:31:41 +08:00
|
|
|
|
|
|
|
|
struct idr idr;
|
|
|
|
|
/* spinlock protects write access to idr */
|
|
|
|
|
spinlock_t idr_lock;
|
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;
|
2017-04-04 18:31:45 +08:00
|
|
|
/* lock for mcast list */
|
|
|
|
|
struct mutex mcast_lock;
|
2005-11-30 08:57:01 +08:00
|
|
|
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
|
|
|
};
|
|
|
|
|
|
2016-05-23 20:20:49 +08:00
|
|
|
struct ib_uwq_object {
|
|
|
|
|
struct ib_uevent_object uevent;
|
|
|
|
|
};
|
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
|
2018-03-28 14:27:46 +08:00
|
|
|
struct ib_uflow_resources;
|
|
|
|
|
struct ib_uflow_object {
|
|
|
|
|
struct ib_uobject uobject;
|
|
|
|
|
struct ib_uflow_resources *resources;
|
|
|
|
|
};
|
|
|
|
|
|
2017-04-04 18:31:47 +08:00
|
|
|
extern const struct file_operations uverbs_event_fops;
|
2017-04-18 17:03:42 +08:00
|
|
|
void ib_uverbs_init_event_queue(struct ib_uverbs_event_queue *ev_queue);
|
2017-04-04 18:31:47 +08:00
|
|
|
struct file *ib_uverbs_alloc_async_event_file(struct ib_uverbs_file *uverbs_file,
|
|
|
|
|
struct ib_device *ib_dev);
|
2015-08-13 23:32:02 +08:00
|
|
|
void ib_uverbs_free_async_event_file(struct ib_uverbs_file *uverbs_file);
|
2018-03-28 14:27:46 +08:00
|
|
|
void ib_uverbs_flow_resources_free(struct ib_uflow_resources *uflow_res);
|
2005-09-27 04:53:25 +08:00
|
|
|
|
2005-10-29 06:38:26 +08:00
|
|
|
void ib_uverbs_release_ucq(struct ib_uverbs_file *file,
|
2017-04-04 18:31:47 +08:00
|
|
|
struct ib_uverbs_completion_event_file *ev_file,
|
2005-10-29 06:38:26 +08:00
|
|
|
struct ib_ucq_object *uobj);
|
|
|
|
|
void ib_uverbs_release_uevent(struct ib_uverbs_file *file,
|
|
|
|
|
struct ib_uevent_object *uobj);
|
2017-04-04 18:31:46 +08:00
|
|
|
void ib_uverbs_release_file(struct kref *ref);
|
2005-10-29 06:38:26 +08:00
|
|
|
|
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);
|
2016-05-23 20:20:49 +08:00
|
|
|
void ib_uverbs_wq_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);
|
2017-04-04 18:31:43 +08:00
|
|
|
int ib_uverbs_dealloc_xrcd(struct ib_uverbs_device *dev, struct ib_xrcd *xrcd,
|
|
|
|
|
enum rdma_remove_reason why);
|
2005-07-08 08:57:13 +08:00
|
|
|
|
2015-12-24 02:12:48 +08:00
|
|
|
int uverbs_dealloc_mw(struct ib_mw *mw);
|
2017-04-04 18:31:43 +08:00
|
|
|
void ib_uverbs_detach_umcast(struct ib_qp *qp,
|
|
|
|
|
struct ib_uqp_object *uobj);
|
2015-12-24 02:12:48 +08:00
|
|
|
|
2018-03-19 21:02:38 +08:00
|
|
|
void create_udata(struct uverbs_attr_bundle *ctx, struct ib_udata *udata);
|
|
|
|
|
extern const struct uverbs_attr_def uverbs_uhw_compat_in;
|
|
|
|
|
extern const struct uverbs_attr_def uverbs_uhw_compat_out;
|
2017-08-03 21:07:07 +08:00
|
|
|
long ib_uverbs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
|
IB/uverbs: Add flow_action create and destroy verbs
A verbs application may receive and transmits packets using a data
path pipeline. Sometimes, the first stage in the receive pipeline or
the last stage in the transmit pipeline involves transforming a
packet, either in order to make it easier for later stages to process
it or to prepare it for transmission over the wire. Such transformation
could be stripping/encapsulating the packet (i.e. vxlan),
decrypting/encrypting it (i.e. ipsec), altering headers, doing some
complex FPGA changes, etc.
Some hardware could do such transformations without software data path
intervention at all. The flow steering API supports steering a
packet (either to a QP or dropping it) and some simple packet
immutable actions (i.e. tagging a packet). Complex actions, that may
change the packet, could bloat the flow steering API extensively.
Sometimes the same action should be applied to several flows.
In this case, it's easier to bind several flows to the same action and
modify it than change all matching flows.
Introducing a new flow_action object that abstracts any packet
transformation (out of a standard and well defined set of actions).
This flow_action object could be tied to a flow steering rule via a
new specification.
Currently, we support esp flow_action, which encrypts or decrypts a
packet according to the given parameters. However, we present a
flexible schema that could be used to other transformation actions tied
to flow rules.
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2018-03-28 14:27:45 +08:00
|
|
|
int uverbs_destroy_def_handler(struct ib_device *ib_dev,
|
|
|
|
|
struct ib_uverbs_file *file,
|
|
|
|
|
struct uverbs_attr_bundle *attrs);
|
2017-08-03 21:07:07 +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;
|
2018-03-28 14:27:49 +08:00
|
|
|
struct ib_uverbs_flow_spec_esp esp;
|
2013-11-07 06:21:48 +08:00
|
|
|
struct ib_uverbs_flow_spec_tcp_udp tcp_udp;
|
2016-06-17 20:14:50 +08:00
|
|
|
struct ib_uverbs_flow_spec_ipv6 ipv6;
|
2017-01-18 20:59:49 +08:00
|
|
|
struct ib_uverbs_flow_spec_action_tag flow_tag;
|
2017-04-03 18:13:51 +08:00
|
|
|
struct ib_uverbs_flow_spec_action_drop drop;
|
2018-03-28 14:27:46 +08:00
|
|
|
struct ib_uverbs_flow_spec_action_handle action;
|
2018-05-31 21:43:37 +08:00
|
|
|
struct ib_uverbs_flow_spec_action_count flow_count;
|
2013-11-07 06:21:48 +08:00
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-28 14:27:44 +08:00
|
|
|
int ib_uverbs_kern_spec_to_ib_spec_filter(enum ib_flow_spec_type type,
|
|
|
|
|
const void *kern_spec_mask,
|
|
|
|
|
const void *kern_spec_val,
|
|
|
|
|
size_t kern_filter_sz,
|
|
|
|
|
union ib_flow_spec *ib_spec);
|
|
|
|
|
|
2018-03-19 21:02:37 +08:00
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_DEVICE);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_PD);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_MR);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_COMP_CHANNEL);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_CQ);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_QP);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_AH);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_MW);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_SRQ);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_FLOW);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_WQ);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_RWQ_IND_TBL);
|
|
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_XRCD);
|
IB/uverbs: Add flow_action create and destroy verbs
A verbs application may receive and transmits packets using a data
path pipeline. Sometimes, the first stage in the receive pipeline or
the last stage in the transmit pipeline involves transforming a
packet, either in order to make it easier for later stages to process
it or to prepare it for transmission over the wire. Such transformation
could be stripping/encapsulating the packet (i.e. vxlan),
decrypting/encrypting it (i.e. ipsec), altering headers, doing some
complex FPGA changes, etc.
Some hardware could do such transformations without software data path
intervention at all. The flow steering API supports steering a
packet (either to a QP or dropping it) and some simple packet
immutable actions (i.e. tagging a packet). Complex actions, that may
change the packet, could bloat the flow steering API extensively.
Sometimes the same action should be applied to several flows.
In this case, it's easier to bind several flows to the same action and
modify it than change all matching flows.
Introducing a new flow_action object that abstracts any packet
transformation (out of a standard and well defined set of actions).
This flow_action object could be tied to a flow steering rule via a
new specification.
Currently, we support esp flow_action, which encrypts or decrypts a
packet according to the given parameters. However, we present a
flexible schema that could be used to other transformation actions tied
to flow rules.
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2018-03-28 14:27:45 +08:00
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_FLOW_ACTION);
|
2018-04-05 23:53:24 +08:00
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_DM);
|
2018-05-31 21:43:32 +08:00
|
|
|
extern const struct uverbs_object_def UVERBS_OBJECT(UVERBS_OBJECT_COUNTERS);
|
2018-03-19 21:02:37 +08:00
|
|
|
|
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);
|
2015-10-21 22:00:42 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(create_qp);
|
2016-05-23 20:20:49 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(create_wq);
|
|
|
|
|
IB_UVERBS_DECLARE_EX_CMD(modify_wq);
|
|
|
|
|
IB_UVERBS_DECLARE_EX_CMD(destroy_wq);
|
2016-05-23 20:20:52 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(create_rwq_ind_table);
|
|
|
|
|
IB_UVERBS_DECLARE_EX_CMD(destroy_rwq_ind_table);
|
2016-12-01 19:43:15 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(modify_qp);
|
2017-11-13 16:51:13 +08:00
|
|
|
IB_UVERBS_DECLARE_EX_CMD(modify_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 */
|