Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Thu, Jul 26, 2018 at 07:35:49AM +0300, Leon Romanovsky wrote: > On Wed, Jul 25, 2018 at 08:35:17AM -0600, Jason Gunthorpe wrote: > > On Wed, Jul 25, 2018 at 08:37:03AM +0300, Leon Romanovsky wrote: > > > > > > Also, I would like to keep the specs consistently formatted according > > > > to clang-format with 'BinPackParameters: true', so I reflowed them as > > > > well. > > > > > > I'm using default VIM clang-format.py without anything in .clang-format. > > > Do you have an extra definitions there, except BinPackParameters? > > > > These days Linux includes a top level .clang-format that does a > > pretty good job. > > > > I have to manually switch BinPackParameters on when working with these > > specs to get the right indenting.. A pain, but maybe there is a better > > way someday.. > > I don't think that it is feasible to ask from people to change some > defaults only for patches that touch those specs. Any change in this > area will change formatting back. Eventually I think we might be able toadd a code comment to tell clang-format, but that would be down the road a bit.. > Jason, bottom line, I won't use BinPackParameters for my patches. Well, you can make sure the specs macro follows the required formatting code style by hand if you prefer.. But, I want to see them in this layout, so they are easier to maintain, not the haphazard layout we had before. Jason
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Wed, Jul 25, 2018 at 08:35:17AM -0600, Jason Gunthorpe wrote: > On Wed, Jul 25, 2018 at 08:37:03AM +0300, Leon Romanovsky wrote: > > > > Also, I would like to keep the specs consistently formatted according > > > to clang-format with 'BinPackParameters: true', so I reflowed them as > > > well. > > > > I'm using default VIM clang-format.py without anything in .clang-format. > > Do you have an extra definitions there, except BinPackParameters? > > These days Linux includes a top level .clang-format that does a > pretty good job. > > I have to manually switch BinPackParameters on when working with these > specs to get the right indenting.. A pain, but maybe there is a better > way someday.. I don't think that it is feasible to ask from people to change some defaults only for patches that touch those specs. Any change in this area will change formatting back. Jason, bottom line, I won't use BinPackParameters for my patches. Thanks > > Jason signature.asc Description: PGP signature
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Wed, Jul 25, 2018 at 08:37:03AM +0300, Leon Romanovsky wrote: > > Also, I would like to keep the specs consistently formatted according > > to clang-format with 'BinPackParameters: true', so I reflowed them as > > well. > > I'm using default VIM clang-format.py without anything in .clang-format. > Do you have an extra definitions there, except BinPackParameters? These days Linux includes a top level .clang-format that does a pretty good job. I have to manually switch BinPackParameters on when working with these specs to get the right indenting.. A pain, but maybe there is a better way someday.. Jason
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Tue, Jul 24, 2018 at 02:13:00PM -0600, Jason Gunthorpe wrote:
> On Tue, Jul 24, 2018 at 08:56:09AM +0300, Leon Romanovsky wrote:
> > On Mon, Jul 23, 2018 at 08:42:36PM -0600, Jason Gunthorpe wrote:
> > > On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky
> > > >
> > > > Changelog:
> > > > v1->v2:
> > > > * Fix matcher to use the correct size.
> > > > * Rephrase commit log of the first patch.
> > > > v0->v1:
> > > > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address.
> > > > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from
> > > > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code.
> > > > * Used ib_dev from uobj when it exists.
> > > > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt
> > > >
> > > > >From Yishai:
> > > >
> > > > This series introduces vendor create and destroy flow methods on the
> > > > uverbs flow object by using the KABI infra-structure.
> > > >
> > > > It's done in a way that enables the driver to get its specific device
> > > > attributes in a raw data to match its underlay specification while still
> > > > using the generic ib_flow object for cleanup and code sharing.
> > > >
> > > > In addition, a specific mlx5 matcher object and its create/destroy
> > > > methods were introduced. This object matches the underlay flow steering
> > > > mask specification and is used as part of mlx5 create flow input data.
> > > >
> > > > This series supports IB_QP/TIR as its flow steering destination as
> > > > applicable today via the ib_create_flow API, however, it adds also an
> > > > option to work with DEVX object which its destination can be both TIR
> > > > and flow table.
> > > >
> > > > Few changes were done in the mlx5 core layer to support forward
> > > > compatible for the device specification raw data and to support flow
> > > > table when the DEVX destination is used.
> > > >
> > > > As part of this series the default IB destroy handler
> > > > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be
> > > > used by the drivers and existing code was refactored to use it.
> > > >
> > > > Thanks
> > > >
> > > > Yishai Hadas (8):
> > > > net/mlx5: Add forward compatible support for the FTE match data
> > > > net/mlx5: Add support for flow table destination number
> > > > IB/mlx5: Introduce flow steering matcher object
> > > > IB: Consider ib_flow creation by the KABI infrastructure
> > > > IB/mlx5: Introduce vendor create and destroy flow methods
> > > > IB/mlx5: Support adding flow steering rule by raw data
> > > > IB/mlx5: Add support for a flow table destination
> > > > IB/mlx5: Expose vendor flow trees
> > >
> > > This seems fine to me. Can you send the mlx5 shared branch for the
> > > first two patches?
> >
> > I applied two first patches with Acked-by from Saeed to mlx5-next
> >
> > 664000b6bb43 net/mlx5: Add support for flow table destination number
> > 2aada6c0c96e net/mlx5: Add forward compatible support for the FTE match data
>
> Okay, I merged the mlx5 branch and applied the series to for-next.
>
> There was a trivial build failure with !CONFIG_INFINIBAND_USER_ACCESS
> and a bunch of annoying check patch warnings regarding tabs and
> leading white space. While I was fixing those I fixed the long lines
> too, they had no reason to be long.
>
> Also, I would like to keep the specs consistently formatted according
> to clang-format with 'BinPackParameters: true', so I reflowed them as
> well.
I'm using default VIM clang-format.py without anything in .clang-format.
Do you have an extra definitions there, except BinPackParameters?
Thanks for fixing.
>
> Please check and let me know if I made an error, diff is below.
>
> Jason
>
> diff --git a/drivers/infiniband/hw/mlx5/flow.c
> b/drivers/infiniband/hw/mlx5/flow.c
> index c94ee1a43e2c3f..ee398a9b5f26b0 100644
> --- a/drivers/infiniband/hw/mlx5/flow.c
> +++ b/drivers/infiniband/hw/mlx5/flow.c
> @@ -50,8 +50,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> int inlen;
> bool dest_devx, dest_qp;
> struct ib_qp *qp = NULL;
> - struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
> - MLX5_IB_ATTR_CREATE_FLOW_HANDLE);
> + struct ib_uobject *uobj =
> + uverbs_attr_get_uobject(attrs, MLX5_IB_ATTR_CREATE_FLOW_HANDLE);
> struct mlx5_ib_dev *dev = to_mdev(uobj->context->device);
>
> if (!capable(CAP_NET_RAW))
> @@ -66,7 +66,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> return -EINVAL;
>
> if (dest_devx) {
> - devx_obj = uverbs_attr_get_obj(attrs,
> MLX5_IB_ATTR_CREATE_FLOW_DEST_DEVX);
> + devx_obj = uverbs_attr_get_obj(
> + attrs, MLX5_IB_ATTR_CREATE_FLOW_DEST_DEVX);
> if (IS_ERR(devx_obj))
> return PTR_ERR(devx_obj);
>
> @@ -97,8 +98,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> if (dev->rep)
>
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Tue, Jul 24, 2018 at 02:13:00PM -0600, Jason Gunthorpe wrote:
> diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> index 5f08b69f8a4f60..ec8410d3c4eb2a 100644
> +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> @@ -1232,11 +1232,9 @@ int mlx5_ib_devx_create(struct mlx5_ib_dev *dev,
> void mlx5_ib_devx_destroy(struct mlx5_ib_dev *dev,
> struct mlx5_ib_ucontext *context);
> const struct uverbs_object_tree_def *mlx5_ib_get_devx_tree(void);
> -struct mlx5_ib_flow_handler *mlx5_ib_raw_fs_rule_add(struct mlx5_ib_dev *dev,
> - struct
> mlx5_ib_flow_matcher *fs_matcher,
> - void *cmd_in,
> - int inlen, int dest_id,
> - int dest_type);
> +struct mlx5_ib_flow_handler *mlx5_ib_raw_fs_rule_add(
> + struct mlx5_ib_dev *dev, struct mlx5_ib_flow_matcher *fs_matcher,
> + void *cmd_in, int inlen, int dest_id, int dest_type);
> bool mlx5_ib_devx_is_flow_dest(void *obj, int *dest_id, int *dest_type);
> int mlx5_ib_get_flow_trees(const struct uverbs_object_tree_def **root);
> #else
> @@ -1247,17 +1245,22 @@ static inline void mlx5_ib_devx_destroy(struct
> mlx5_ib_dev *dev,
> struct mlx5_ib_ucontext *context) {}
> static inline const struct uverbs_object_tree_def *
> mlx5_ib_get_devx_tree(void) { return NULL; }
> -static inline struct mlx5_ib_flow_handler *
> -mlx5_ib_raw_fs_rule_add(struct mlx5_ib_dev *dev,
> - struct mlx5_ib_flow_matcher *fs_matcher,
> - void *cmd_in,
> - int inlen, int dest_id,
> - int dest_type) { return -EOPNOTSUPP; };
> -static inline bool
> -mlx5_ib_devx_is_flow_dest(void *obj, int *dest_id,
> - int *dest_type) { return false; };
> +static inline struct mlx5_ib_flow_handler *mlx5_ib_raw_fs_rule_add(
> + struct mlx5_ib_dev *dev, struct mlx5_ib_flow_matcher *fs_matcher,
> + void *cmd_in, int inlen, int dest_id, int dest_type)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}
Bah, I botched the compile test for this - this entire static inline
should just be removed because the function is defined in main.c which
is always compiled.
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index ec8410d3c4eb2a..462505c8fa25a0 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -1245,12 +1245,6 @@ static inline void mlx5_ib_devx_destroy(struct
mlx5_ib_dev *dev,
struct mlx5_ib_ucontext *context) {}
static inline const struct uverbs_object_tree_def *
mlx5_ib_get_devx_tree(void) { return NULL; }
-static inline struct mlx5_ib_flow_handler *mlx5_ib_raw_fs_rule_add(
- struct mlx5_ib_dev *dev, struct mlx5_ib_flow_matcher *fs_matcher,
- void *cmd_in, int inlen, int dest_id, int dest_type)
-{
- return ERR_PTR(-EOPNOTSUPP);
-}
static inline bool mlx5_ib_devx_is_flow_dest(void *obj, int *dest_id,
int *dest_type)
{
Jason
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Tue, Jul 24, 2018 at 08:56:09AM +0300, Leon Romanovsky wrote:
> On Mon, Jul 23, 2018 at 08:42:36PM -0600, Jason Gunthorpe wrote:
> > On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > Changelog:
> > > v1->v2:
> > > * Fix matcher to use the correct size.
> > > * Rephrase commit log of the first patch.
> > > v0->v1:
> > > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address.
> > > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from
> > > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code.
> > > * Used ib_dev from uobj when it exists.
> > > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt
> > >
> > > >From Yishai:
> > >
> > > This series introduces vendor create and destroy flow methods on the
> > > uverbs flow object by using the KABI infra-structure.
> > >
> > > It's done in a way that enables the driver to get its specific device
> > > attributes in a raw data to match its underlay specification while still
> > > using the generic ib_flow object for cleanup and code sharing.
> > >
> > > In addition, a specific mlx5 matcher object and its create/destroy
> > > methods were introduced. This object matches the underlay flow steering
> > > mask specification and is used as part of mlx5 create flow input data.
> > >
> > > This series supports IB_QP/TIR as its flow steering destination as
> > > applicable today via the ib_create_flow API, however, it adds also an
> > > option to work with DEVX object which its destination can be both TIR
> > > and flow table.
> > >
> > > Few changes were done in the mlx5 core layer to support forward
> > > compatible for the device specification raw data and to support flow
> > > table when the DEVX destination is used.
> > >
> > > As part of this series the default IB destroy handler
> > > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be
> > > used by the drivers and existing code was refactored to use it.
> > >
> > > Thanks
> > >
> > > Yishai Hadas (8):
> > > net/mlx5: Add forward compatible support for the FTE match data
> > > net/mlx5: Add support for flow table destination number
> > > IB/mlx5: Introduce flow steering matcher object
> > > IB: Consider ib_flow creation by the KABI infrastructure
> > > IB/mlx5: Introduce vendor create and destroy flow methods
> > > IB/mlx5: Support adding flow steering rule by raw data
> > > IB/mlx5: Add support for a flow table destination
> > > IB/mlx5: Expose vendor flow trees
> >
> > This seems fine to me. Can you send the mlx5 shared branch for the
> > first two patches?
>
> I applied two first patches with Acked-by from Saeed to mlx5-next
>
> 664000b6bb43 net/mlx5: Add support for flow table destination number
> 2aada6c0c96e net/mlx5: Add forward compatible support for the FTE match data
Okay, I merged the mlx5 branch and applied the series to for-next.
There was a trivial build failure with !CONFIG_INFINIBAND_USER_ACCESS
and a bunch of annoying check patch warnings regarding tabs and
leading white space. While I was fixing those I fixed the long lines
too, they had no reason to be long.
Also, I would like to keep the specs consistently formatted according
to clang-format with 'BinPackParameters: true', so I reflowed them as
well.
Please check and let me know if I made an error, diff is below.
Jason
diff --git a/drivers/infiniband/hw/mlx5/flow.c
b/drivers/infiniband/hw/mlx5/flow.c
index c94ee1a43e2c3f..ee398a9b5f26b0 100644
--- a/drivers/infiniband/hw/mlx5/flow.c
+++ b/drivers/infiniband/hw/mlx5/flow.c
@@ -50,8 +50,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
int inlen;
bool dest_devx, dest_qp;
struct ib_qp *qp = NULL;
- struct ib_uobject *uobj = uverbs_attr_get_uobject(attrs,
- MLX5_IB_ATTR_CREATE_FLOW_HANDLE);
+ struct ib_uobject *uobj =
+ uverbs_attr_get_uobject(attrs, MLX5_IB_ATTR_CREATE_FLOW_HANDLE);
struct mlx5_ib_dev *dev = to_mdev(uobj->context->device);
if (!capable(CAP_NET_RAW))
@@ -66,7 +66,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
return -EINVAL;
if (dest_devx) {
- devx_obj = uverbs_attr_get_obj(attrs,
MLX5_IB_ATTR_CREATE_FLOW_DEST_DEVX);
+ devx_obj = uverbs_attr_get_obj(
+ attrs, MLX5_IB_ATTR_CREATE_FLOW_DEST_DEVX);
if (IS_ERR(devx_obj))
return PTR_ERR(devx_obj);
@@ -97,8 +98,8 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
if (dev->rep)
return -ENOTSUPP;
- cmd_in = uverbs_attr_get_alloced_ptr(attrs,
-
MLX5_IB_ATTR_CREATE_FLOW_MATCH_VALUE);
+ cmd_in = uverbs_attr_get_alloced_ptr(
+ attrs, MLX5_IB_ATTR_CREATE_FLOW_MATCH_VALUE);
inlen = uverbs_attr_get_len(attrs,
MLX5_IB_ATTR_CREATE_FLOW_MATCH_VALUE);
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Mon, Jul 23, 2018 at 08:42:36PM -0600, Jason Gunthorpe wrote: > On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > Changelog: > > v1->v2: > > * Fix matcher to use the correct size. > > * Rephrase commit log of the first patch. > > v0->v1: > > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address. > > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from > > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code. > > * Used ib_dev from uobj when it exists. > > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt > > > > >From Yishai: > > > > This series introduces vendor create and destroy flow methods on the > > uverbs flow object by using the KABI infra-structure. > > > > It's done in a way that enables the driver to get its specific device > > attributes in a raw data to match its underlay specification while still > > using the generic ib_flow object for cleanup and code sharing. > > > > In addition, a specific mlx5 matcher object and its create/destroy > > methods were introduced. This object matches the underlay flow steering > > mask specification and is used as part of mlx5 create flow input data. > > > > This series supports IB_QP/TIR as its flow steering destination as > > applicable today via the ib_create_flow API, however, it adds also an > > option to work with DEVX object which its destination can be both TIR > > and flow table. > > > > Few changes were done in the mlx5 core layer to support forward > > compatible for the device specification raw data and to support flow > > table when the DEVX destination is used. > > > > As part of this series the default IB destroy handler > > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be > > used by the drivers and existing code was refactored to use it. > > > > Thanks > > > > Yishai Hadas (8): > > net/mlx5: Add forward compatible support for the FTE match data > > net/mlx5: Add support for flow table destination number > > IB/mlx5: Introduce flow steering matcher object > > IB: Consider ib_flow creation by the KABI infrastructure > > IB/mlx5: Introduce vendor create and destroy flow methods > > IB/mlx5: Support adding flow steering rule by raw data > > IB/mlx5: Add support for a flow table destination > > IB/mlx5: Expose vendor flow trees > > This seems fine to me. Can you send the mlx5 shared branch for the > first two patches? I applied two first patches with Acked-by from Saeed to mlx5-next 664000b6bb43 net/mlx5: Add support for flow table destination number 2aada6c0c96e net/mlx5: Add forward compatible support for the FTE match data Thanks > > Thanks, > Jason signature.asc Description: PGP signature
Re: [PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
On Mon, Jul 23, 2018 at 03:25:04PM +0300, Leon Romanovsky wrote: > From: Leon Romanovsky > > Changelog: > v1->v2: > * Fix matcher to use the correct size. > * Rephrase commit log of the first patch. > v0->v1: > * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address. > ?* Replaced UA_ALLOC_AND_COPY to regular copy_from > * Added UVERBS_ATTR_NO_DATA new macro for cleaner code. > * Used ib_dev from uobj when it exists. > * ib_is_destroy_retryable was replaced by ib_destroy_usecnt > > >From Yishai: > > This series introduces vendor create and destroy flow methods on the > uverbs flow object by using the KABI infra-structure. > > It's done in a way that enables the driver to get its specific device > attributes in a raw data to match its underlay specification while still > using the generic ib_flow object for cleanup and code sharing. > > In addition, a specific mlx5 matcher object and its create/destroy > methods were introduced. This object matches the underlay flow steering > mask specification and is used as part of mlx5 create flow input data. > > This series supports IB_QP/TIR as its flow steering destination as > applicable today via the ib_create_flow API, however, it adds also an > option to work with DEVX object which its destination can be both TIR > and flow table. > > Few changes were done in the mlx5 core layer to support forward > compatible for the device specification raw data and to support flow > table when the DEVX destination is used. > > As part of this series the default IB destroy handler > (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be > used by the drivers and existing code was refactored to use it. > > Thanks > > Yishai Hadas (8): > net/mlx5: Add forward compatible support for the FTE match data > net/mlx5: Add support for flow table destination number > IB/mlx5: Introduce flow steering matcher object > IB: Consider ib_flow creation by the KABI infrastructure > IB/mlx5: Introduce vendor create and destroy flow methods > IB/mlx5: Support adding flow steering rule by raw data > IB/mlx5: Add support for a flow table destination > IB/mlx5: Expose vendor flow trees This seems fine to me. Can you send the mlx5 shared branch for the first two patches? Thanks, Jason
[PATCH rdma-next v2 0/8] Support mlx5 flow steering with RAW data
From: Leon Romanovsky Changelog: v1->v2: * Fix matcher to use the correct size. * Rephrase commit log of the first patch. v0->v1: * Fixed ADD_UVERBS_ATTRIBUTES_SIMPLE macro to pass the real address. �* Replaced UA_ALLOC_AND_COPY to regular copy_from * Added UVERBS_ATTR_NO_DATA new macro for cleaner code. * Used ib_dev from uobj when it exists. * ib_is_destroy_retryable was replaced by ib_destroy_usecnt - >From Yishai: This series introduces vendor create and destroy flow methods on the uverbs flow object by using the KABI infra-structure. It's done in a way that enables the driver to get its specific device attributes in a raw data to match its underlay specification while still using the generic ib_flow object for cleanup and code sharing. In addition, a specific mlx5 matcher object and its create/destroy methods were introduced. This object matches the underlay flow steering mask specification and is used as part of mlx5 create flow input data. This series supports IB_QP/TIR as its flow steering destination as applicable today via the ib_create_flow API, however, it adds also an option to work with DEVX object which its destination can be both TIR and flow table. Few changes were done in the mlx5 core layer to support forward compatible for the device specification raw data and to support flow table when the DEVX destination is used. As part of this series the default IB destroy handler (i.e. uverbs_destroy_def_handler()) was exposed from IB core to be used by the drivers and existing code was refactored to use it. Thanks Yishai Hadas (8): net/mlx5: Add forward compatible support for the FTE match data net/mlx5: Add support for flow table destination number IB/mlx5: Introduce flow steering matcher object IB: Consider ib_flow creation by the KABI infrastructure IB/mlx5: Introduce vendor create and destroy flow methods IB/mlx5: Support adding flow steering rule by raw data IB/mlx5: Add support for a flow table destination IB/mlx5: Expose vendor flow trees drivers/infiniband/core/uverbs_cmd.c | 4 + drivers/infiniband/core/uverbs_std_types.c | 5 +- .../infiniband/core/uverbs_std_types_flow_action.c | 3 +- drivers/infiniband/hw/mlx5/Makefile| 1 + drivers/infiniband/hw/mlx5/devx.c | 22 ++ drivers/infiniband/hw/mlx5/flow.c | 254 + drivers/infiniband/hw/mlx5/main.c | 230 +-- drivers/infiniband/hw/mlx5/mlx5_ib.h | 31 +++ .../mellanox/mlx5/core/diag/fs_tracepoint.c| 3 + drivers/net/ethernet/mellanox/mlx5/core/fs_cmd.c | 24 +- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 81 +-- include/linux/mlx5/fs.h| 1 + include/linux/mlx5/mlx5_ifc.h | 1 + include/rdma/ib_verbs.h| 15 ++ include/rdma/uverbs_ioctl.h| 2 + include/rdma/uverbs_named_ioctl.h | 29 ++- include/uapi/rdma/mlx5_user_ioctl_cmds.h | 50 +++- 17 files changed, 636 insertions(+), 120 deletions(-) create mode 100644 drivers/infiniband/hw/mlx5/flow.c -- 2.14.4
