Skip to contentSkip to conversation

Introduce Multi-Packet receive work queue

PATCH In review Leon Romanovsky 3 participants 6 messages Oct 17, 2017 – Oct 25, 2017 2 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover Introduce Multi-Packet receive work queue

A Multi-Packet receive WQ comes to improve performance and memory footprint. It is comprised of work requests that can be consumed by multiple packets. Buffers pointed by SGEs of each work request in a multi packet WQ are divided into strides. Both buffer size and stride size must be identical in all work requests of the same multi packet WQ and are set during WQ creation.

A single WR in a Multi-Packet WQ can generate multiple completions, depends on the number of packets consumed. Each packet starts at the beginning of a stride and is written in stride granularity.

Here is an example of a work request comprised of 3 strides. Packet 1 is larger than a stride so it occupies 2 strides. Packet 2 fits in a single stride. Each packet will generate its own completion.

|         |         |[packet2]|
|    [packet1]      |         |
|_________|_________|_________|
 stride      stride     stride
 <--      work request     -->

A Multi-Packet WQ reduces the number of needed post-recv operations thus increasing performance: In the example above, a single post-recv operation was performed instead of 2.

It reduces memory footprint by allowing each packet to consume a different number of strides instead of the whole WR. For example, a large work request with many small strides: If the incoming packet is smaller than a stride, the waste will be <stride size> - <packet size> while for a large packet the waste will be:
<stride size> - (<packet size> % <stride size>)

The patches are available in the git repository at:
git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git tags/rdma-next-2017-10-17

Thanks
---------------------------------------

Noa Osherovich (2):
IB/mlx5: Expose multi-packet RQ capabilities
IB/mlx5: Allow creation of a multi-packet RQ

 drivers/infiniband/hw/mlx5/main.c    | 16 +++++++++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  9 +++++++
 drivers/infiniband/hw/mlx5/qp.c      | 52 ++++++++++++++++++++++++++++++------
 include/linux/mlx5/mlx5_ifc.h        |  1 +
 include/uapi/rdma/mlx5-abi.h         | 22 ++++++++++++++-
 5 files changed, 91 insertions(+), 9 deletions(-)

--
2.14.2

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

A message that is not in the archive (sent off-list or not yet received): 20171017150113.8544-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

#2 lore raw

PATCH 1/2 IB/mlx5: Expose multi-packet RQ capabilities

From: Noa Osherovich <noaos-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch reports the device's striding RQ capabilities to the user-space:
- min/max_single_stride_log_num_of_bytes: Log of min/max number of bytes in a single stride.
- min/max_single_wqe_log_num_of_strides: Log of min/max number of strides in a single WQE.
- supported_qpts: A bit mask to know which QP types support multi- packet RQ, for now only Raw Packet QPs.

---
 drivers/infiniband/hw/mlx5/main.c    | 16 ++++++++++++++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  5 +++++
 include/uapi/rdma/mlx5-abi.h         | 14 ++++++++++++++
 3 files changed, 35 insertions(+)
drivers/infiniband/hw/mlx5/main.c +16 -0
index 552f7bd4ecc3..02da3f58f296 100644
@@ -848,6 +848,22 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
 		}
 	}
 
+	if (field_avail(typeof(resp), striding_rq_caps, uhw->outlen)) {
+		resp.response_length += sizeof(resp.striding_rq_caps);
+		if (MLX5_CAP_GEN(mdev, striding_rq)) {
+			resp.striding_rq_caps.min_single_stride_log_num_of_bytes =
+				MLX5_MIN_SINGLE_STRIDE_LOG_NUM_BYTES;
+			resp.striding_rq_caps.max_single_stride_log_num_of_bytes =
+				MLX5_MAX_SINGLE_STRIDE_LOG_NUM_BYTES;
+			resp.striding_rq_caps.min_single_wqe_log_num_of_strides =
+				MLX5_MIN_SINGLE_WQE_LOG_NUM_STRIDES;
+			resp.striding_rq_caps.max_single_wqe_log_num_of_strides =
+				MLX5_MAX_SINGLE_WQE_LOG_NUM_STRIDES;
+			resp.striding_rq_caps.supported_qpts =
+				BIT(IB_QPT_RAW_PACKET);
+		}
+	}
+
 	if (uhw->outlen) {
 		err = ib_copy_to_udata(uhw, &resp, resp.response_length);
 
drivers/infiniband/hw/mlx5/mlx5_ib.h +5 -0
index 189e80cd6b2f..8de40852818b 100644
@@ -256,6 +256,11 @@ enum mlx5_ib_wq_flags {
 	MLX5_IB_WQ_FLAGS_DELAY_DROP = 0x1,
 };
 
+#define MLX5_MIN_SINGLE_WQE_LOG_NUM_STRIDES 9
+#define MLX5_MAX_SINGLE_WQE_LOG_NUM_STRIDES 16
+#define MLX5_MIN_SINGLE_STRIDE_LOG_NUM_BYTES 6
+#define MLX5_MAX_SINGLE_STRIDE_LOG_NUM_BYTES 13
+
 struct mlx5_ib_rwq {
 	struct ib_wq		ibwq;
 	struct mlx5_core_qp	core_qp;
include/uapi/rdma/mlx5-abi.h +14 -0
index 1791bf123ba9..0832d9502200 100644
@@ -190,6 +190,19 @@ struct mlx5_ib_sw_parsing_caps {
 	__u32 supported_qpts;
 };
 
+struct mlx5_ib_striding_rq_caps {
+	__u32 min_single_stride_log_num_of_bytes;
+	__u32 max_single_stride_log_num_of_bytes;
+	__u32 min_single_wqe_log_num_of_strides;
+	__u32 max_single_wqe_log_num_of_strides;
+
+	/* Corresponding bit will be set if qp type from
+	 * 'enum ib_qp_type' is supported, e.g.
+	 * supported_qpts |= 1 << IB_QPT_RAW_PACKET
+	 */
+	__u32 supported_qpts;
+};
+
 struct mlx5_ib_query_device_resp {
 	__u32	comp_mask;
 	__u32	response_length;
@@ -200,6 +213,7 @@ struct mlx5_ib_query_device_resp {
 	__u32	mlx5_ib_support_multi_pkt_send_wqes;
 	__u32	reserved;
 	struct mlx5_ib_sw_parsing_caps sw_parsing_caps;
+	struct mlx5_ib_striding_rq_caps striding_rq_caps;
 };
 
 struct mlx5_ib_create_cq {
Signature · 6 lines
2.14.2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw

PATCH 2/2 IB/mlx5: Allow creation of a multi-packet RQ

In reply to a message not in the archive

From: Noa Osherovich <noaos-VPRAkNaXOzVWk0Htik3J/[email protected]>

Allow creation of a multi-packet receive queue.

In order to create a multi-packet RQ, the following fields in the mlx5_ib_rwq should be set:
- log_num_strides: Log of number of strides per WQE
- single_stride_log_num_of_bytes: Log of a single stride size
- two_byte_shift_en: When enabled, hardware pads 2 bytes of zeros before writing the message to memory (e.g. for the IP alignment).

---
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  4 +++
 drivers/infiniband/hw/mlx5/qp.c      | 52 ++++++++++++++++++++++++++++++------
 include/linux/mlx5/mlx5_ifc.h        |  1 +
 include/uapi/rdma/mlx5-abi.h         |  8 +++++-
 4 files changed, 56 insertions(+), 9 deletions(-)
drivers/infiniband/hw/mlx5/mlx5_ib.h +4 -0
index 8de40852818b..e7deaa08535b 100644
@@ -254,6 +254,7 @@ struct mlx5_ib_wq {
 
 enum mlx5_ib_wq_flags {
 	MLX5_IB_WQ_FLAGS_DELAY_DROP = 0x1,
+	MLX5_IB_WQ_FLAGS_STRIDING_RQ = 0x2,
 };
 
 #define MLX5_MIN_SINGLE_WQE_LOG_NUM_STRIDES 9
@@ -269,6 +270,9 @@ struct mlx5_ib_rwq {
 	u32			log_rq_size;
 	u32			rq_page_offset;
 	u32			log_page_size;
+	u32			log_num_strides;
+	u32			two_byte_shift_en;
+	u32			single_stride_log_num_of_bytes;
 	struct ib_umem		*umem;
 	size_t			buf_size;
 	unsigned int		page_shift;
drivers/infiniband/hw/mlx5/qp.c +44 -8

74 lines not on this page · raw message

include/linux/mlx5/mlx5_ifc.h +1 -0
index 69772347f866..db655db45b77 100644
@@ -744,6 +744,7 @@ enum {
 	MLX5_WQ_TYPE_LINKED_LIST  = 0x0,
 	MLX5_WQ_TYPE_CYCLIC       = 0x1,
 	MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ = 0x2,
+	MLX5_WQ_TYPE_CYCLIC_STRIDING_RQ = 0x3,
 };
 
 enum {
include/uapi/rdma/mlx5-abi.h +7 -1
index 0832d9502200..b1d5b87ba3fd 100644
@@ -308,6 +308,10 @@ struct mlx5_ib_alloc_mw {
 	__u16	reserved2;
 };
 
+enum mlx5_ib_create_wq_mask {
+	MLX5_IB_CREATE_WQ_STRIDING_RQ	= (1 << 0),
+};
+
 struct mlx5_ib_create_wq {
 	__u64   buf_addr;
 	__u64   db_addr;
@@ -316,7 +320,9 @@ struct mlx5_ib_create_wq {
 	__u32   user_index;
 	__u32   flags;
 	__u32   comp_mask;
-	__u32   reserved;
+	__u32	single_stride_log_num_of_bytes;
+	__u32	single_wqe_log_num_of_strides;
+	__u32	two_byte_shift_en;
 };
 
 struct mlx5_ib_create_ah_resp {
Signature · 6 lines
2.14.2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw
In reply to a message not in the archive
Quoted 22 lines

A Multi-Packet receive WQ comes to improve performance and memory footprint. It is comprised of work requests that can be consumed by multiple packets. Buffers pointed by SGEs of each work request in a multi packet WQ are divided into strides. Both buffer size and stride size must be identical in all work requests of the same multi packet WQ and are set during WQ creation.

A single WR in a Multi-Packet WQ can generate multiple completions, depends on the number of packets consumed. Each packet starts at the beginning of a stride and is written in stride granularity.

Here is an example of a work request comprised of 3 strides. Packet 1 is larger than a stride so it occupies 2 strides. Packet 2 fits in a single stride. Each packet will generate its own completion.

|         |         |[packet2]|
|    [packet1]      |         |
|_________|_________|_________|
  stride      stride     stride
  <--      work request     -->
Quoted 3 lines

A Multi-Packet WQ reduces the number of needed post-recv operations thus increasing performance: In the example above, a single post-recv operation was performed instead of 2.

Looks like a nice feature, would be nice if we could use it... The problem is that adding a different logic in case this feature exists is messy and difficult. Is there any way we can come up with a verbs API that will utilize this feature but hide the implementation details from the ULPs?

Maybe something that wraps post_recv?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 090b4257-daf4-4f90-555c-b048764d1cda-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org

#6 lore raw
Quoted 26 lines · Sagi Grimberg
Quoted 22 lines

A Multi-Packet receive WQ comes to improve performance and memory footprint. It is comprised of work requests that can be consumed by multiple packets. Buffers pointed by SGEs of each work request in a multi packet WQ are divided into strides. Both buffer size and stride size must be identical in all work requests of the same multi packet WQ and are set during WQ creation.

A single WR in a Multi-Packet WQ can generate multiple completions, depends on the number of packets consumed. Each packet starts at the beginning of a stride and is written in stride granularity.

Here is an example of a work request comprised of 3 strides. Packet 1 is larger than a stride so it occupies 2 strides. Packet 2 fits in a single stride. Each packet will generate its own completion.

|         |         |[packet2]|
|    [packet1]      |         |
|_________|_________|_________|
  stride      stride     stride
  <--      work request     -->
Quoted 3 lines

A Multi-Packet WQ reduces the number of needed post-recv operations thus increasing performance: In the example above, a single post-recv operation was performed instead of 2.

Quoted 5 lines

Looks like a nice feature, would be nice if we could use it... The problem is that adding a different logic in case this feature exists is messy and difficult. Is there any way we can come up with a verbs API that will utilize this feature but hide the implementation details from the ULPs?

We will be more than happy to work with the community and update our driver's code if needed, once the community will converge on the proper API. Right now, we are exposing it through our DV interface.

Thanks

#7 lore raw
In reply to a message not in the archive
Quoted 19 lines · Leon Romanovsky

A Multi-Packet receive WQ comes to improve performance and memory footprint. It is comprised of work requests that can be consumed by multiple packets. Buffers pointed by SGEs of each work request in a multi packet WQ are divided into strides. Both buffer size and stride size must be identical in all work requests of the same multi packet WQ and are set during WQ creation.

A single WR in a Multi-Packet WQ can generate multiple completions, depends on the number of packets consumed. Each packet starts at the beginning of a stride and is written in stride granularity.

Here is an example of a work request comprised of 3 strides. Packet 1 is larger than a stride so it occupies 2 strides. Packet 2 fits in a single stride. Each packet will generate its own completion.

Quoted 3 lines
         |         |[packet2]|
    [packet1]      |         |
_________|_________|_________|
Quoted 6 lines

stride stride stride
<-- work request -->

A Multi-Packet WQ reduces the number of needed post-recv operations thus increasing performance: In the example above, a single post-recv operation was performed instead of 2.

Nice. Resolves some of the issues the basic recv queue model has. As you said to Sagi, this is just being exposed in your DV interface right now, so I'm fine with it. Thanks, applied.

Signature · 8 lines
Doug Ledford <[email protected]>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

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