Re: [PATCH mlx5-next v2 11/13] IB/mlx5: Add flow counters binding support

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

 



On 5/29/2018 10:56 PM, Jason Gunthorpe wrote:
On Tue, May 29, 2018 at 04:09:15PM +0300, Leon Romanovsky wrote:
diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
index 508ea8c82da7..ef3f430a7050 100644
+++ b/include/uapi/rdma/mlx5-abi.h
@@ -443,4 +443,18 @@ enum {
  enum {
  	MLX5_IB_CLOCK_INFO_V1              = 0,
  };
+
+struct mlx5_ib_flow_counters_data {
+	__aligned_u64   counters_data;
+	__u32   ncounters;
+	__u32   reserved;
+};
+
+struct mlx5_ib_create_flow {
+	__u32   ncounters_data;
+	__u32   reserved;
+	/* Following are counters data based on ncounters_data */
+	struct mlx5_ib_flow_counters_data data[];
+};
+
  #endif /* MLX5_ABI_USER_H */

This uapi thing still needs to be fixed as I pointed out before.

In V3 we can go with below, no change in memory layout but it can clarify the code/usage.

struct mlx5_ib_flow_counters_desc {
        __u32   description;
        __u32   index;
};

struct mlx5_ib_flow_counters_data {
        RDMA_UAPI_PTR(struct mlx5_ib_flow_counters_desc *, counters_data);
        __u32   ncounters;
        __u32   reserved;
};

struct mlx5_ib_create_flow {
        __u32   ncounters_data;
        __u32   reserved;
        /* Following are counters data based on ncounters_data */
        struct mlx5_ib_flow_counters_data data[];


I still can't figure out why this should be a 2d array.

This comes to support the future case of multiple counters objects/specs passed with the same flow. There is a need to differentiate mapping data for each counters object and that is done via the 'ncounters_data' field and the 2d array.

 I think it
should be written simply as:

struct mlx5_ib_flow_counter_desc {
         __u32 description;
         __u32 index;
};

struct mlx5_ib_create_flow {
	RDMA_UAPI_PTR(struct mlx5_ib_flow_counter_desc, counters_data);
	__u32   ncounters;
	__u32   reserved;
};

With the corresponding changes elsewhere.


This doesn't support the above use case.

A flex array at the end of a struct means that the struct can never be
extended again which seems like a terrible idea,

The header [1] has a fixed size and will always exist even if there will be no counters. Future extensions [2] will be added in the memory post the flex array which its size depends on 'ncounters_data'. This pattern is used also in other extended APIs. [3]

struct mlx5_ib_create_flow {
        __u32   ncounters_data;
        __u32   reserved;
[1] /* Header is above ********

        /* Following are counters data based on ncounters_data */
        struct mlx5_ib_flow_counters_data data[];

[2] Future fields.

[3] https://elixir.bootlin.com/linux/latest/source/include/uapi/rdma/ib_user_verbs.h#L1145






--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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