RE: [PATCH rdma-next] IB/mlx5: Support flow counters offset for bulk counters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mark,

> From: Mark Bloch <markb@xxxxxxxxxxxx>
> Sent: Tuesday, October 29, 2019 08:49
> 
> Hey Leon,
> 
> On 10/28/2019 22:59, Leon Romanovsky wrote:
> > From: Yevgeny Kliteynik <kliteyn@xxxxxxxxxxxx>
> >
> > Add support for flow steering counters action with
> > a non-base counter ID (offset) for bulk counters.
> >
> > When creating a flow counter object, save the bulk value.
> > This value is used when a flow action with a non-base
> > counter ID is requested - to validate that the required
> > offset is in the range of the allocated bulk.
> >
> > Signed-off-by: Yevgeny Kliteynik <kliteyn@xxxxxxxxxxxx>
> > Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx>
> > ---
> >  drivers/infiniband/hw/mlx5/devx.c        | 12 ++++++++-
> >  drivers/infiniband/hw/mlx5/flow.c        | 34 ++++++++++++++++++++++--
> >  drivers/infiniband/hw/mlx5/mlx5_ib.h     |  2 +-
> >  include/uapi/rdma/mlx5_user_ioctl_cmds.h |  1 +
> >  4 files changed, 45 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/devx.c  b/drivers/infiniband/hw/mlx5/devx.c
> > index 6b1fca91d7d3..3900fcb1ccaf 100644
> > --- a/drivers/infiniband/hw/mlx5/devx.c
> > +++ b/drivers/infiniband/hw/mlx5/devx.c
> > @@ -100,6 +100,7 @@ struct devx_obj {
> >  		struct mlx5_ib_devx_mr	devx_mr;
> >  		struct mlx5_core_dct	core_dct;
> >  		struct mlx5_core_cq	core_cq;
> > +		u32			flow_counter_bulk_size;
> >  	};
> >  	struct list_head event_sub; /* holds devx_event_subscription entries */
> >  };
> > @@ -192,7 +193,7 @@ bool mlx5_ib_devx_is_flow_dest(void *obj, int
> *dest_id, int *dest_type)
> >  	}
> >  }
> >
> > -bool mlx5_ib_devx_is_flow_counter(void *obj, u32 *counter_id)
> > +bool mlx5_ib_devx_is_flow_counter(void *obj, u32 *counter_id, u32
> *bulk_size)
> >  {
> >  	struct devx_obj *devx_obj = obj;
> >  	u16 opcode = MLX5_GET(general_obj_in_cmd_hdr, devx_obj->dinbox,
> opcode);
> > @@ -201,6 +202,7 @@ bool mlx5_ib_devx_is_flow_counter(void *obj, u32
> *counter_id)
> >  		*counter_id = MLX5_GET(dealloc_flow_counter_in,
> >  				       devx_obj->dinbox,
> >  				       flow_counter_id);
> > +		*bulk_size = devx_obj->flow_counter_bulk_size;
> >  		return true;
> >  	}
> >
> > @@ -1463,6 +1465,14 @@ static int
> UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_OBJ_CREATE)(
> >  	if (err)
> >  		goto obj_free;
> >
> > +	if (opcode == MLX5_CMD_OP_ALLOC_FLOW_COUNTER) {
> > +		u8 bulk = MLX5_GET(alloc_flow_counter_in,
> > +				   cmd_in,
> > +				   flow_counter_bulk);
> > +		if (bulk)
> > +			obj->flow_counter_bulk_size = 64UL << ffs(bulk);
> 
> Why do you need ffs and not just: 64 << bulk ?
> As this field is a bitmask, only a single bit should be set and that should already
> be validated by the FW.

Because we want the index of bit that is set and not the value of the bitmask.
I can, however, do (128 * bulk) instead, if you don't like ffs.
This probably looks nicer, and I don't need to check 'if (bulk)'.
 
> > +	}
> > +
> >  	uobj->object = obj;
> >  	INIT_LIST_HEAD(&obj->event_sub);
> >  	obj->ib_dev = dev;
> > diff --git a/drivers/infiniband/hw/mlx5/flow.c b/drivers/infiniband/hw/mlx5/flow.c
> > index b198ff10cde9..05637039bcd7 100644
> > --- a/drivers/infiniband/hw/mlx5/flow.c
> > +++ b/drivers/infiniband/hw/mlx5/flow.c
> > @@ -85,6 +85,8 @@ static int
> UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> >  	struct mlx5_ib_dev *dev = mlx5_udata_to_mdev(&attrs->driver_udata);
> >  	int len, ret, i;
> >  	u32 counter_id = 0;
> > +	u32 bulk_size = 0;
> > +	u32 *offset;
> >
> >  	if (!capable(CAP_NET_RAW))
> >  		return -EPERM;
> > @@ -151,8 +153,32 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_CREATE_FLOW)(
> >  	if (len) {
> >  		devx_obj = arr_flow_actions[0]->object;
> >
> > -		if (!mlx5_ib_devx_is_flow_counter(devx_obj, &counter_id))
> > +		if (!mlx5_ib_devx_is_flow_counter(devx_obj,
> > +						  &counter_id,
> > +						  &bulk_size))
> >  			return -EINVAL;
> > +
> > +		if (uverbs_attr_is_valid(
> > +			    attrs,
> > + 
> 	MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET)) {
> > +			int num_offsets = uverbs_attr_ptr_get_array_size(
> > +				attrs,
> > +
> 	MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET,
> > +				sizeof(uint32_t));
> > +
> > +			if (num_offsets != 1)
> > +				return -EINVAL;> +
> > +			offset = uverbs_attr_get_alloced_ptr(
> > +				attrs,
> > +
> 	MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET);
> > +
> > +			if (*offset && *offset >= bulk_size)
> > +				return -EINVAL;
> 
> This logic/validity check should probably be in: mlx5_ib_devx_is_flow_counter().
> you pass it the the offset (or 0) and you get back a counter_id and false/true if
> valid.

Sure, we can go this way as well.

> > +
> > +			counter_id += *offset;
> > +		}
> > +
> >  		flow_act.action |= MLX5_FLOW_CONTEXT_ACTION_COUNT;
> >  	}
> >
> > @@ -598,7 +624,11 @@ DECLARE_UVERBS_NAMED_METHOD(
> >
> 	UVERBS_ATTR_IDRS_ARR(MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX,
> >  			     MLX5_IB_OBJECT_DEVX_OBJ,
> >  			     UVERBS_ACCESS_READ, 1, 1,
> > -			     UA_OPTIONAL));
> > +			     UA_OPTIONAL),
> > +
> 	UVERBS_ATTR_PTR_IN(MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTER
> S_DEVX_OFFSET,
> > +			   UVERBS_ATTR_MIN_SIZE(sizeof(uint32_t)),
> 
> Why uint32_t and not u32?

Oops, here and in other places :)

> > +			   UA_OPTIONAL,
> > +			   UA_ALLOC_AND_COPY));
> side note, both MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET
> and MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX
> are optional, but you should provide
> MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET only
> if you are also passing MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX.
> 
> Which means you can pass
> MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX_OFFSET without
> MLX5_IB_ATTR_CREATE_FLOW_ARR_COUNTERS_DEVX and everything will
> work.

True. You don't have a straight-forward way to do it because rdma-core
provides COUNTERS_DEVX_OFFSET only as part of providing COUNTERS_DEVX,
but nothing prevents you from writing your own code to do so.

> I wonder if we should have a way to define such things.

We can discuss this.
In the meantime, I'll send a V2 of the patch with all the aforementioned fixes.

Thanks!

-- YK

> Mark




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux