Introduce mlx5 data direct placement (DDP)

PATCH Applied Leon Romanovsky 5 participants 16 messages Sep 3, 2024 – Nov 5, 2024

Subsystems (5)

Networking Network drivers InfiniBand Mellanox mlx5 core +1 more subsystems

lore

Share & tools

lore

Leon Romanovsky

author

2024-09-03 11:37 UTC #0 lore raw

cover Introduce mlx5 data direct placement (DDP)

From: Leon Romanovsky <[email protected]>

Hi,

This series from Edward introduces mlx5 data direct placement (DDP) feature.

This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.

When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.

RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.

Thanks

Edward Srouji (2):
net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption

 drivers/infiniband/hw/mlx5/main.c    |  8 +++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  1 +
 drivers/infiniband/hw/mlx5/qp.c      | 51 +++++++++++++++++++++++++---
 include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++----
 include/uapi/rdma/mlx5-abi.h         |  5 +++
 5 files changed, 78 insertions(+), 11 deletions(-)

Signature · 1 line

2.46.0

Leon Romanovsky

author

2024-09-03 11:38 UTC #1 lore raw

PATCH 1/2 net/mlx5: Introduce data placement ordering bits

From: Edward Srouji <[email protected]>

Introduce out-of-order (OOO) data placement (DP) IFC related bits to support OOO DP QP.

Signed-off-by Edward Srouji <[email protected]>

Reviewed-by Yishai Hadas <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
 include/linux/mlx5/mlx5_ifc.h | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

include/linux/mlx5/mlx5_ifc.h +18 -6

index 970c9d8473ef..691a285f9c1e 100644
@@ -1765,7 +1765,12 @@ struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         reserved_at_328[0x2];
 	u8	   relaxed_ordering_read[0x1];
 	u8         log_max_pd[0x5];
-	u8         reserved_at_330[0x6];
+	u8         dp_ordering_ooo_all_ud[0x1];
+	u8         dp_ordering_ooo_all_uc[0x1];
+	u8         dp_ordering_ooo_all_xrc[0x1];
+	u8         dp_ordering_ooo_all_dc[0x1];
+	u8         dp_ordering_ooo_all_rc[0x1];
+	u8         reserved_at_335[0x1];
 	u8         pci_sync_for_fw_update_with_driver_unload[0x1];
 	u8         vnic_env_cnt_steering_fail[0x1];
 	u8         vport_counter_local_loopback[0x1];

@@ -1986,7 +1991,9 @@ struct mlx5_ifc_cmd_hca_cap_2_bits {
 	u8	   reserved_at_0[0x80];
 
 	u8         migratable[0x1];
-	u8         reserved_at_81[0x11];
+	u8         reserved_at_81[0x7];
+	u8         dp_ordering_force[0x1];
+	u8         reserved_at_89[0x9];
 	u8         query_vuid[0x1];
 	u8         reserved_at_93[0xd];

@@ -3397,7 +3404,8 @@ struct mlx5_ifc_qpc_bits {
 	u8         latency_sensitive[0x1];
 	u8         reserved_at_24[0x1];
 	u8         drain_sigerr[0x1];
-	u8         reserved_at_26[0x2];
+	u8         reserved_at_26[0x1];
+	u8         dp_ordering_force[0x1];
 	u8         pd[0x18];
 
 	u8         mtu[0x3];

@@ -3470,7 +3478,8 @@ struct mlx5_ifc_qpc_bits {
 	u8         rae[0x1];
 	u8         reserved_at_493[0x1];
 	u8         page_offset[0x6];
-	u8         reserved_at_49a[0x3];
+	u8         reserved_at_49a[0x2];
+	u8         dp_ordering_1[0x1];
 	u8         cd_slave_receive[0x1];
 	u8         cd_slave_send[0x1];
 	u8         cd_master[0x1];

@@ -4377,7 +4386,8 @@ struct mlx5_ifc_dctc_bits {
 	u8         state[0x4];
 	u8         reserved_at_8[0x18];
 
-	u8         reserved_at_20[0x8];
+	u8         reserved_at_20[0x7];
+	u8         dp_ordering_force[0x1];
 	u8         user_index[0x18];
 
 	u8         reserved_at_40[0x8];

@@ -4392,7 +4402,9 @@ struct mlx5_ifc_dctc_bits {
 	u8         latency_sensitive[0x1];
 	u8         rlky[0x1];
 	u8         free_ar[0x1];
-	u8         reserved_at_73[0xd];
+	u8         reserved_at_73[0x1];
+	u8         dp_ordering_1[0x1];
+	u8         reserved_at_75[0xb];
 
 	u8         reserved_at_80[0x8];
 	u8         cs_res[0x8];

Signature · 1 line

2.46.0

Leon Romanovsky

author

2024-09-03 11:38 UTC #2 lore raw

PATCH 2/2 RDMA/mlx5: Support OOO RX WQE consumption

In reply to Leon Romanovsky

From: Edward Srouji <[email protected]>

Support QP with out-of-order (OOO) capabilities enabled. This allows WRs on the receiver side of the QP to be consumed OOO, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.

When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.

Atomic operations larger than 8 bytes are currently not supported. Therefore, when this feature is enabled, the created QP restricts its atomic support to 8 bytes at most.

In addition, when querying the device, a new flag is returned in response to indicate that the Kernel supports OOO QP.

Signed-off-by Edward Srouji <[email protected]>

Reviewed-by Yishai Hadas <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/infiniband/hw/mlx5/main.c    |  8 +++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  1 +
 drivers/infiniband/hw/mlx5/qp.c      | 51 +++++++++++++++++++++++++---
 include/uapi/rdma/mlx5-abi.h         |  5 +++
 4 files changed, 60 insertions(+), 5 deletions(-)

drivers/infiniband/hw/mlx5/main.c +8 -0

index b85ad3c0bfa1..6cefefd2b578 100644
@@ -1154,6 +1154,14 @@ static int mlx5_ib_query_device(struct ib_device *ibdev,
 				MLX5_IB_QUERY_DEV_RESP_PACKET_BASED_CREDIT_MODE;
 
 		resp.flags |= MLX5_IB_QUERY_DEV_RESP_FLAGS_SCAT2CQE_DCT;
+
+		if (MLX5_CAP_GEN_2(mdev, dp_ordering_force) &&
+		    (MLX5_CAP_GEN(mdev, dp_ordering_ooo_all_xrc) ||
+		    MLX5_CAP_GEN(mdev, dp_ordering_ooo_all_dc) ||
+		    MLX5_CAP_GEN(mdev, dp_ordering_ooo_all_rc) ||
+		    MLX5_CAP_GEN(mdev, dp_ordering_ooo_all_ud) ||
+		    MLX5_CAP_GEN(mdev, dp_ordering_ooo_all_uc)))
+			resp.flags |= MLX5_IB_QUERY_DEV_RESP_FLAGS_OOO_DP;
 	}
 
 	if (offsetofend(typeof(resp), sw_parsing_caps) <= uhw_outlen) {

drivers/infiniband/hw/mlx5/mlx5_ib.h +1 -0

index 5505eb70939b..926a965e4570 100644
@@ -532,6 +532,7 @@ struct mlx5_ib_qp {
 	struct mlx5_bf	        bf;
 	u8			has_rq:1;
 	u8			is_rss:1;
+	u8			is_ooo_rq:1;
 
 	/* only for user space QPs. For kernel
 	 * we have it from the bf object

drivers/infiniband/hw/mlx5/qp.c +46 -5

109 lines not on this page · raw message

include/uapi/rdma/mlx5-abi.h +5 -0

index d4f6a36dffb0..8a6ad6c6841c 100644
@@ -252,6 +252,7 @@ enum mlx5_ib_query_dev_resp_flags {
 	MLX5_IB_QUERY_DEV_RESP_FLAGS_CQE_128B_PAD  = 1 << 1,
 	MLX5_IB_QUERY_DEV_RESP_PACKET_BASED_CREDIT_MODE = 1 << 2,
 	MLX5_IB_QUERY_DEV_RESP_FLAGS_SCAT2CQE_DCT = 1 << 3,
+	MLX5_IB_QUERY_DEV_RESP_FLAGS_OOO_DP = 1 << 4,
 };
 
 enum mlx5_ib_tunnel_offloads {

@@ -439,6 +440,10 @@ struct mlx5_ib_burst_info {
 	__u16       reserved;
 };
 
+enum mlx5_ib_modify_qp_mask {
+	MLX5_IB_MODIFY_QP_OOO_DP = 1 << 0,
+};
+
 struct mlx5_ib_modify_qp {
 	__u32			   comp_mask;
 	struct mlx5_ib_burst_info  burst_info;

Signature · 1 line

2.46.0

Zhu Yanjun

2024-09-04 06:02 UTC #3 lore raw

In reply to Leon Romanovsky

Quoted 11 lines · Leon Romanovsky

From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.

Quoted 6 lines

When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.

It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.

Any scenario that this feature can be applied and what benefits will be got from this feature?

I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?

Thanks,
Zhu Yanjun

Quoted 14 lines

Thanks

Edward Srouji (2):
net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption

  drivers/infiniband/hw/mlx5/main.c    |  8 +++++
  drivers/infiniband/hw/mlx5/mlx5_ib.h |  1 +
  drivers/infiniband/hw/mlx5/qp.c      | 51 +++++++++++++++++++++++++---
  include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++----
  include/uapi/rdma/mlx5-abi.h         |  5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)

Edward Srouji

2024-09-04 08:27 UTC #4 lore raw

Quoted 18 lines · Zhu Yanjun

External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.

Quoted 8 lines

Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.

Correct.

Quoted 6 lines

Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?

One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing responders to receive packets out of order (OOO).

For example, this can be utilized in devices that support multi-plane functionality, as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane is supported, a single logical mlx5 port aggregates multiple physical plane ports. In this scenario, the requester can "spray" packets across the multiple physical plane ports without guaranteeing packet order, either on the wire or on the receiver (responder) side.

With this approach, no barriers or fences are required to ensure in-order packet reception, which optimizes the data path for performance. This can result in better BW, theoretically achieving line-rate performance equivalent to the sum of the maximum BW of all physical plane ports, with only one QP.

[1] https://lore.kernel.org/lkml/[email protected]/

Quoted 18 lines

Thanks,
Zhu Yanjun
Quoted 14 lines
Thanks
Edward Srouji (2):
net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c | 51 +++++++++++++++++++++++++--- include/linux/mlx5/mlx5_ifc.h | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)

Zhu Yanjun

2024-09-04 11:53 UTC #5 lore raw

Quoted 45 lines · Edward Srouji

Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 6 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality, as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane is supported, a single logical mlx5 port aggregates multiple physical plane ports. In this scenario, the requester can "spray" packets across the multiple physical plane ports without guaranteeing packet order, either on the wire or on the receiver (responder) side.

Quoted 4 lines

With this approach, no barriers or fences are required to ensure in-order packet reception, which optimizes the data path for performance. This can result in better BW, theoretically achieving line-rate performance equivalent to the sum of the maximum BW of all physical plane ports, with only one QP.

Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.

I agree with you.

But how does the receiver get the correct packets from the out-of-order packets efficiently?

The method is implemented in Software or Hardware?

I am just interested in this feature and want to know more about this.

Thanks,

Zhu Yanjun

Quoted 21 lines

[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)

Signature · 2 lines

Best Regards,
Yanjun.Zhu

Edward Srouji

2024-09-05 12:23 UTC #6 lore raw

Quoted 66 lines · Zhu Yanjun

External email: Use caution opening links or attachments
Quoted 51 lines · Edward Srouji
Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 6 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.

Quoted 6 lines

I agree with you.
But how does the receiver get the correct packets from the out-of-order packets efficiently?
The method is implemented in Software or Hardware?

The packets have new field that is used by the HW to understand the correct message order (similar to PSN).

Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.

So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.

The SW/Applications may receive OOO WR_IDs though (because the first CQE may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.

Quoted 32 lines

I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 21 lines
[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
Signature · 2 lines
Best Regards,
Yanjun.Zhu

Zhu Yanjun

2024-09-06 05:02 UTC #7 lore raw

Quoted 76 lines · Edward Srouji

Quoted 66 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 51 lines · Edward Srouji
Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 6 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.
Quoted 6 lines
I agree with you.
But how does the receiver get the correct packets from the out-of-order packets efficiently?
The method is implemented in Software or Hardware?

Quoted 7 lines

The packets have new field that is used by the HW to understand the correct message order (similar to PSN).
Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.
So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.
The SW/Applications may receive OOO WR_IDs though (because the first CQE may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.

Got it. It seems that all the functionalities are implemented in HW. The SW only receives OOO WR_IDs. Thanks a lot. Perhaps it is helpful to RDMA LAG devices. It should enhance the performance^_^

BTW, do you have any performance data with this feature?

Best Regards,
Zhu Yanjun

Quoted 33 lines

Quoted 33 lines
I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 21 lines
[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
Signature · 2 lines
Best Regards,
Yanjun.Zhu

Edward Srouji

2024-09-06 12:18 UTC #8 lore raw

Quoted 96 lines · Zhu Yanjun

External email: Use caution opening links or attachments
Quoted 83 lines · Edward Srouji
Quoted 67 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 52 lines · Edward Srouji
Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 7 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.
Quoted 6 lines
I agree with you.
But how does the receiver get the correct packets from the out-of-order packets efficiently?
The method is implemented in Software or Hardware?
The packets have new field that is used by the HW to understand the correct message order (similar to PSN).
Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.
Quoted 8 lines
So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.
The SW/Applications may receive OOO WR_IDs though (because the first CQE may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.

Quoted 5 lines

Got it. It seems that all the functionalities are implemented in HW. The SW only receives OOO WR_IDs. Thanks a lot. Perhaps it is helpful to RDMA LAG devices. It should enhance the performance^_^
BTW, do you have any performance data with this feature?

Not yet. We tested it functionality wise for now.

But we should be able to measure its performance soon :).

Quoted 38 lines

Best Regards,
Zhu Yanjun
Quoted 33 lines
Quoted 33 lines
I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 21 lines
[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
Signature · 2 lines
Best Regards,
Yanjun.Zhu

Zhu Yanjun

2024-09-06 15:17 UTC #9 lore raw

Quoted 102 lines · Edward Srouji

Quoted 100 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 83 lines · Edward Srouji
Quoted 67 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 52 lines · Edward Srouji
Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 7 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.
Quoted 6 lines
I agree with you.
But how does the receiver get the correct packets from the out-of-order packets efficiently?
The method is implemented in Software or Hardware?
The packets have new field that is used by the HW to understand the correct message order (similar to PSN).
Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.
Quoted 8 lines
So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.
The SW/Applications may receive OOO WR_IDs though (because the first CQE may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.
Got it. It seems that all the functionalities are implemented in HW. The SW only receives OOO WR_IDs. Thanks a lot. Perhaps it is helpful to RDMA LAG devices. It should enhance the performance^_^

Quoted 5 lines

Quoted 1 line
BTW, do you have any performance data with this feature?
Not yet. We tested it functionality wise for now.
But we should be able to measure its performance soon :).

Thanks a lot. It is an interesting feature. If performance reports, please share them with us.

IMO, perhaps this feature can be used in random read/write devices, for example, hard disk?

Just my idea. Not sure if you have applied this feature with hard disk or not.

Best Regards,

Zhu Yanjun

Quoted 40 lines

Quoted 40 lines
Best Regards,
Zhu Yanjun
Quoted 33 lines
Quoted 33 lines
I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 21 lines
[1] https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
Signature · 2 lines
Best Regards,
Yanjun.Zhu

Signature · 2 lines

Best Regards,
Yanjun.Zhu

Edward Srouji

2024-09-08 08:47 UTC #10 lore raw

Quoted 115 lines · Zhu Yanjun

External email: Use caution opening links or attachments
Quoted 111 lines · Edward Srouji
Quoted 109 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 96 lines · Edward Srouji
Quoted 74 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 59 lines · Edward Srouji
Quoted 25 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 13 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed
out of order, permitting the sender side to transmit messages without
guaranteeing arrival order on the receiver side.
Quoted 7 lines
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
RDMA Read and RDMA Atomic operations on the responder side continue to
be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
Quoted 5 lines
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write
and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 9 lines
Any scenario that this feature can be applied and what benefits will be
got from this feature?
I am just curious about this. Normally the users will consume the data
in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth
(BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.
Quoted 7 lines
I agree with you.
But how does the receiver get the correct packets from the out-of-order
packets efficiently?
The method is implemented in Software or Hardware?
The packets have new field that is used by the HW to understand the correct message order (similar to PSN).
Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.
So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.
Quoted 4 lines
The SW/Applications may receive OOO WR_IDs though (because the first CQE
may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.
Got it. It seems that all the functionalities are implemented in HW. The SW only receives OOO WR_IDs. Thanks a lot. Perhaps it is helpful to RDMA LAG devices. It should enhance the performance^_^

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
BTW, do you have any performance data with this feature?
Not yet. We tested it functionality wise for now.
But we should be able to measure its performance soon :).
Thanks a lot. It is an interesting feature. If performance reports, please share them with us.

Sure, will do.

Quoted 7 lines

IMO, perhaps this feature can be used in random read/write devices, for example, hard disk?
Just my idea. Not sure if you have applied this feature with hard disk or not.

You're right, it can be used with storage and we're planning to do this integration and usage in the near future.

Quoted 50 lines

Best Regards,
Zhu Yanjun
Quoted 41 lines
Quoted 41 lines
Best Regards,
Zhu Yanjun
Quoted 34 lines
Quoted 34 lines
I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 22 lines
[1]
https://lore.kernel.org/lkml/[email protected]/
Quoted 19 lines
Thanks,
Zhu Yanjun
Quoted 15 lines
Thanks
Edward Srouji (2):
   net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
drivers/infiniband/hw/mlx5/main.c    | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c      | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h         | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
Signature · 2 lines
Best Regards,
Yanjun.Zhu
Signature · 2 lines
Best Regards,
Yanjun.Zhu

Bernard Metzler

2024-09-06 13:03 UTC #11 lore raw

In reply to Edward Srouji

Quoted 85 lines

-----Original Message-----
From: Edward Srouji <[email protected]>
Sent: Thursday, September 5, 2024 2:23 PM
To: Zhu Yanjun <[email protected]>; Leon Romanovsky <[email protected]>; Jason Gunthorpe <[email protected]>
Cc: Leon Romanovsky <[email protected]>; [email protected]; [email protected]; [email protected]; Saeed Mahameed <[email protected]>; Tariq Toukan <[email protected]>; Yishai Hadas <[email protected]>
Subject: [EXTERNAL] Re: [PATCH rdma-next 0/2] Introduce mlx5 data direct placement (DDP)
Quoted 69 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 52 lines · Edward Srouji
Quoted 18 lines · Zhu Yanjun
External email: Use caution opening links or attachments
Quoted 14 lines · Leon Romanovsky
From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.
Quoted 8 lines
Quoted 3 lines
RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
It is an interesting feature. If I got this feature correctly, this feature permits the user consumes the data out of order when RDMA Write and Send operations. But its completiong ordering is still in order.
Correct.
Quoted 7 lines
Any scenario that this feature can be applied and what benefits will be got from this feature?
I am just curious about this. Normally the users will consume the data in order. In what scenario, the user will consume the data out of order?
One of the main benefits of this feature is achieving higher bandwidth (BW) by allowing
responders to receive packets out of order (OOO).
For example, this can be utilized in devices that support multi-plane functionality,
as introduced in the "Multi-plane support for mlx5" series [1]. When mlx5 multi-plane
is supported, a single logical mlx5 port aggregates multiple physical plane ports.
In this scenario, the requester can "spray" packets across the multiple physical
plane ports without guaranteeing packet order, either on the wire or on the receiver
(responder) side.
Quoted 7 lines
With this approach, no barriers or fences are required to ensure in-order packet
reception, which optimizes the data path for performance. This can result in better
BW, theoretically achieving line-rate performance equivalent to the sum of
the maximum BW of all physical plane ports, with only one QP.
Thanks a lot for your quick reply. Without ensuring in-order packet reception, this does optimize the data path for performance.
I agree with you.

Quoted 9 lines

Quoted 4 lines
But how does the receiver get the correct packets from the out-of-order packets efficiently?
The method is implemented in Software or Hardware?
The packets have new field that is used by the HW to understand the correct message order (similar to PSN).

Interesting feature! Reminds me somehow on iWarp RDMA with its DDP sub-layer 😉
But can that extra field be compliant with the standardized wire protocol?

Thanks,
Bernard.

Quoted 48 lines

Once the packets arrive OOO to the receiver side, the data is scattered directly (hence the DDP - "Direct Data Placement" name) by the HW.
So the efficiency is achieved by the HW, as it also saves the required context and metadata so it can deliver the correct completion to the user (in-order) once we have some WQEs that can be considered an "in-order window" and be delivered to the user.
The SW/Applications may receive OOO WR_IDs though (because the first CQE may have consumed Recv WQE of any index on the receiver side), and it's their responsibility to handle it from this point, if it's required.
Quoted 9 lines
I am just interested in this feature and want to know more about this.
Thanks,
Zhu Yanjun
Quoted 2 lines
[1] INVALID URI REMOVED
3A__lore.kernel.org_lkml_cover.1718553901.git.leon- 40kernel.org_&d=DwIDaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=4ynb4Sj_4MUcZXbhvovE4tYSb qxyOwdSiLedP4yO55g&m=v7mstcYLoga4Ed_laSGpqjuQbnScgHCiflwmA4TzvXgi9x64qGYB4C ZGFrxQviQF&s=a-4dG1bvzL3dPsLsCSkubdHg_9eDKHIt-rEGQdaXvgU&e=
Quoted 23 lines
Quoted 10 lines
Quoted 10 lines
Thanks,
Zhu Yanjun
Quoted 7 lines
Thanks
Edward Srouji (2):
net/mlx5: Introduce data placement ordering bits RDMA/mlx5: Support OOO RX WQE consumption
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
drivers/infiniband/hw/mlx5/main.c | 8 +++++ drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + drivers/infiniband/hw/mlx5/qp.c | 51
+++++++++++++++++++++++++---
include/linux/mlx5/mlx5_ifc.h | 24 +++++++++---- include/uapi/rdma/mlx5-abi.h | 5 +++
  5 files changed, 78 insertions(+), 11 deletions(-)
--
Best Regards,
Yanjun.Zhu

Leon Romanovsky

author Applied

2024-11-04 08:20 UTC #12 lore raw

Re: (subset) [PATCH rdma-next 0/2] Introduce mlx5 data direct placement (DDP)

In reply to Leon Romanovsky

Quoted 8 lines · Leon Romanovsky

From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
[...]

Applied, thanks!

[2/2] RDMA/mlx5: Support OOO RX WQE consumption

      https://git.kernel.org/rdma/rdma/c/ded397366b5540

Best regards,

Signature · 1 line

Leon Romanovsky <[email protected]>

Leon Romanovsky

author

2024-11-04 08:27 UTC #13 lore raw

In reply to Leon Romanovsky

Quoted 14 lines · Leon Romanovsky

From: Leon Romanovsky <[email protected]>
Hi,
This series from Edward introduces mlx5 data direct placement (DDP) feature.
This feature allows WRs on the receiver side of the QP to be consumed out of order, permitting the sender side to transmit messages without guaranteeing arrival order on the receiver side.
When enabled, the completion ordering of WRs remains in-order, regardless of the Receive WRs consumption order.

Quoted 8 lines

RDMA Read and RDMA Atomic operations on the responder side continue to be executed in-order, while the ordering of data placement for RDMA Write and Send operations is not guaranteed.
Thanks
Edward Srouji (2):
net/mlx5: Introduce data placement ordering bits

Jakub,

We applied this series to RDMA and first patch generates merge conflicts in include/linux/mlx5/mlx5_ifc.h between netdev and RDMA trees.

Can you please pull shared mlx5-next branch to avoid it?

Thanks

Quoted 13 lines

RDMA/mlx5: Support OOO RX WQE consumption

 drivers/infiniband/hw/mlx5/main.c    |  8 +++++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  1 +
 drivers/infiniband/hw/mlx5/qp.c      | 51 +++++++++++++++++++++++++---
 include/linux/mlx5/mlx5_ifc.h        | 24 +++++++++----
 include/uapi/rdma/mlx5-abi.h         |  5 +++
 5 files changed, 78 insertions(+), 11 deletions(-)

Signature · 1 line

2.46.0

Jakub Kicinski

maintainer

2024-11-05 02:53 UTC #14 lore raw

Quoted 6 lines · On Mon, 4 Nov 2024 10:27:10 +0200 Leon Romanovsky wrote:

Jakub,
We applied this series to RDMA and first patch generates merge conflicts in include/linux/mlx5/mlx5_ifc.h between netdev and RDMA trees.
Can you please pull shared mlx5-next branch to avoid it?

Sorry I don't have the context, the thread looks 2 months old. If you'd like us to pull something please sense a pull request targeting net-next...

Leon Romanovsky

author

2024-11-05 06:26 UTC #15 lore raw

Quoted 11 lines · Jakub Kicinski

Quoted 6 lines · On Mon, 4 Nov 2024 10:27:10 +0200 Leon Romanovsky wrote:
Jakub,
We applied this series to RDMA and first patch generates merge conflicts in include/linux/mlx5/mlx5_ifc.h between netdev and RDMA trees.
Can you please pull shared mlx5-next branch to avoid it?
Sorry I don't have the context, the thread looks 2 months old. If you'd like us to pull something please sense a pull request targeting net-next...

Sure, will do.

Thanks