[PATCH rdma-next 0/2] Real time/free running timestamp support

[PATCH rdma-next 0/2] Real time/free running timestamp support

[Leon Romanovsky]

From: Leon Romanovsky <leonro@nvidia.com>

Add an extra timestamp format for mlx5_ib device.

Thanks

Aharon Landau (2):
  net/mlx5: Add new timestamp mode bits
  RDMA/mlx5: Fail QP creation if the device can not support the CQE TS

 drivers/infiniband/hw/mlx5/qp.c | 104 +++++++++++++++++++++++++++++---
 include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
 2 files changed, 145 insertions(+), 13 deletions(-)

--
2.29.2

[PATCH mlx5-next 1/2] net/mlx5: Add new timestamp mode bits

[Leon Romanovsky]

From: Aharon Landau <aharonl@nvidia.com>

These fields declare which timestamp mode is supported by the device
per RQ/SQ/QP.

In addiition add the ts_format field to the select the mode for
RQ/SQ/QP.

Signed-off-by: Aharon Landau <aharonl@nvidia.com>
Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 include/linux/mlx5/mlx5_ifc.h | 54 +++++++++++++++++++++++++++++++----
 1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index b96f99f1198e..77051bd5c1cf 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -932,11 +932,18 @@ struct mlx5_ifc_per_protocol_networking_offload_caps_bits {
 	u8         reserved_at_200[0x600];
 };

+enum {
+	MLX5_QP_TIMESTAMP_FORMAT_CAP_FREE_RUNNING               = 0x0,
+	MLX5_QP_TIMESTAMP_FORMAT_CAP_REAL_TIME                  = 0x1,
+	MLX5_QP_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME = 0x2,
+};
+
 struct mlx5_ifc_roce_cap_bits {
 	u8         roce_apm[0x1];
 	u8         reserved_at_1[0x3];
 	u8         sw_r_roce_src_udp_port[0x1];
-	u8         reserved_at_5[0x1b];
+	u8         reserved_at_5[0x19];
+	u8	   qp_ts_format[0x2];

 	u8         reserved_at_20[0x60];

@@ -1258,6 +1265,18 @@ enum {
 	MLX5_STEERING_FORMAT_CONNECTX_6DX = 1,
 };

+enum {
+	MLX5_SQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING               = 0x0,
+	MLX5_SQ_TIMESTAMP_FORMAT_CAP_REAL_TIME                  = 0x1,
+	MLX5_SQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME = 0x2,
+};
+
+enum {
+	MLX5_RQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING               = 0x0,
+	MLX5_RQ_TIMESTAMP_FORMAT_CAP_REAL_TIME                  = 0x1,
+	MLX5_RQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME = 0x2,
+};
+
 struct mlx5_ifc_cmd_hca_cap_bits {
 	u8         reserved_at_0[0x1f];
 	u8         vhca_resource_manager[0x1];
@@ -1569,7 +1588,8 @@ struct mlx5_ifc_cmd_hca_cap_bits {

 	u8         general_obj_types[0x40];

-	u8         reserved_at_440[0x4];
+	u8         sq_ts_format[0x2];
+	u8         rq_ts_format[0x2];
 	u8         steering_format_version[0x4];
 	u8         create_qp_start_hint[0x18];

@@ -2873,6 +2893,12 @@ enum {
 	MLX5_QPC_CS_RES_UP_TO_64B  = 0x2,
 };

+enum {
+	MLX5_QPC_TIMESTAMP_FORMAT_FREE_RUNNING = 0x0,
+	MLX5_QPC_TIMESTAMP_FORMAT_DEFAULT      = 0x1,
+	MLX5_QPC_TIMESTAMP_FORMAT_REAL_TIME    = 0x2,
+};
+
 struct mlx5_ifc_qpc_bits {
 	u8         state[0x4];
 	u8         lag_tx_port_affinity[0x4];
@@ -2901,7 +2927,9 @@ struct mlx5_ifc_qpc_bits {
 	u8         log_rq_stride[0x3];
 	u8         no_sq[0x1];
 	u8         log_sq_size[0x4];
-	u8         reserved_at_55[0x6];
+	u8         reserved_at_55[0x3];
+	u8	   ts_format[0x2];
+	u8         reserved_at_5a[0x1];
 	u8         rlky[0x1];
 	u8         ulp_stateless_offload_mode[0x4];

@@ -3317,6 +3345,12 @@ enum {
 	MLX5_SQC_STATE_ERR  = 0x3,
 };

+enum {
+	MLX5_SQC_TIMESTAMP_FORMAT_FREE_RUNNING = 0x0,
+	MLX5_SQC_TIMESTAMP_FORMAT_DEFAULT      = 0x1,
+	MLX5_SQC_TIMESTAMP_FORMAT_REAL_TIME    = 0x2,
+};
+
 struct mlx5_ifc_sqc_bits {
 	u8         rlky[0x1];
 	u8         cd_master[0x1];
@@ -3328,7 +3362,9 @@ struct mlx5_ifc_sqc_bits {
 	u8         reg_umr[0x1];
 	u8         allow_swp[0x1];
 	u8         hairpin[0x1];
-	u8         reserved_at_f[0x11];
+	u8         reserved_at_f[0xb];
+	u8	   ts_format[0x2];
+	u8	   reserved_at_1c[0x4];

 	u8         reserved_at_20[0x8];
 	u8         user_index[0x18];
@@ -3419,6 +3455,12 @@ enum {
 	MLX5_RQC_STATE_ERR  = 0x3,
 };

+enum {
+	MLX5_RQC_TIMESTAMP_FORMAT_FREE_RUNNING = 0x0,
+	MLX5_RQC_TIMESTAMP_FORMAT_DEFAULT      = 0x1,
+	MLX5_RQC_TIMESTAMP_FORMAT_REAL_TIME    = 0x2,
+};
+
 struct mlx5_ifc_rqc_bits {
 	u8         rlky[0x1];
 	u8	   delay_drop_en[0x1];
@@ -3429,7 +3471,9 @@ struct mlx5_ifc_rqc_bits {
 	u8         reserved_at_c[0x1];
 	u8         flush_in_error_en[0x1];
 	u8         hairpin[0x1];
-	u8         reserved_at_f[0x11];
+	u8         reserved_at_f[0xb];
+	u8	   ts_format[0x2];
+	u8	   reserved_at_1c[0x4];

 	u8         reserved_at_20[0x8];
 	u8         user_index[0x18];
--
2.29.2

[PATCH rdma-next 2/2] RDMA/mlx5: Fail QP creation if the device can not support the CQE TS

[Leon Romanovsky]

From: Aharon Landau <aharonl@nvidia.com>

In ConnectX6Dx device, HW can work in real time timestamp mode according
to the device capabilities per RQ/SQ/QP.

When the flag IB_UVERBS_CQ_FLAGS_TIMESTAMP_COMPLETION is set, the user
expect to get TS on the CQEs in free running format, so we need to fail
the QP creation if the current mode of the device doesn't support it.

Signed-off-by: Aharon Landau <aharonl@nvidia.com>
Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/infiniband/hw/mlx5/qp.c | 104 +++++++++++++++++++++++++++++---
 1 file changed, 96 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 38df809a1bd5..72105146ab1e 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1079,6 +1079,7 @@ static int _create_kernel_qp(struct mlx5_ib_dev *dev,

 	qpc = MLX5_ADDR_OF(create_qp_in, *in, qpc);
 	MLX5_SET(qpc, qpc, uar_page, uar_index);
+	MLX5_SET(qpc, qpc, ts_format, MLX5_QPC_TIMESTAMP_FORMAT_DEFAULT);
 	MLX5_SET(qpc, qpc, log_page_size, qp->buf.page_shift - MLX5_ADAPTER_PAGE_SHIFT);

 	/* Set "fast registration enabled" for all kernel QPs */
@@ -1173,10 +1174,72 @@ static void destroy_flow_rule_vport_sq(struct mlx5_ib_sq *sq)
 	sq->flow_rule = NULL;
 }

+static int get_rq_ts_format(struct mlx5_ib_dev *dev, struct mlx5_ib_cq *send_cq)
+{
+	bool fr_supported =
+		MLX5_CAP_GEN(dev->mdev, rq_ts_format) ==
+			MLX5_RQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING ||
+		MLX5_CAP_GEN(dev->mdev, rq_ts_format) ==
+			MLX5_RQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME;
+
+	if (send_cq->create_flags & IB_UVERBS_CQ_FLAGS_TIMESTAMP_COMPLETION) {
+		if (!fr_supported) {
+			mlx5_ib_dbg(dev, "Free running TS format is not supported\n");
+			return -EOPNOTSUPP;
+		}
+		return MLX5_RQC_TIMESTAMP_FORMAT_FREE_RUNNING;
+	}
+	return MLX5_RQC_TIMESTAMP_FORMAT_DEFAULT;
+}
+
+static int get_sq_ts_format(struct mlx5_ib_dev *dev, struct mlx5_ib_cq *send_cq)
+{
+	bool fr_supported =
+		MLX5_CAP_GEN(dev->mdev, sq_ts_format) ==
+			MLX5_SQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING ||
+		MLX5_CAP_GEN(dev->mdev, sq_ts_format) ==
+			MLX5_SQ_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME;
+
+	if (send_cq->create_flags & IB_UVERBS_CQ_FLAGS_TIMESTAMP_COMPLETION) {
+		if (!fr_supported) {
+			mlx5_ib_dbg(dev, "Free running TS format is not supported\n");
+			return -EOPNOTSUPP;
+		}
+		return MLX5_SQC_TIMESTAMP_FORMAT_FREE_RUNNING;
+	}
+	return MLX5_SQC_TIMESTAMP_FORMAT_DEFAULT;
+}
+
+static int get_qp_ts_format(struct mlx5_ib_dev *dev, struct mlx5_ib_cq *send_cq,
+			    struct mlx5_ib_cq *recv_cq)
+{
+	bool fr_supported =
+		MLX5_CAP_ROCE(dev->mdev, qp_ts_format) ==
+			MLX5_QP_TIMESTAMP_FORMAT_CAP_FREE_RUNNING ||
+		MLX5_CAP_ROCE(dev->mdev, qp_ts_format) ==
+			MLX5_QP_TIMESTAMP_FORMAT_CAP_FREE_RUNNING_AND_REAL_TIME;
+	int ts_format = MLX5_QPC_TIMESTAMP_FORMAT_DEFAULT;
+
+	if (recv_cq &&
+	    recv_cq->create_flags & IB_UVERBS_CQ_FLAGS_TIMESTAMP_COMPLETION)
+		ts_format = MLX5_QPC_TIMESTAMP_FORMAT_FREE_RUNNING;
+
+	if (send_cq &&
+	    send_cq->create_flags & IB_UVERBS_CQ_FLAGS_TIMESTAMP_COMPLETION)
+		ts_format = MLX5_QPC_TIMESTAMP_FORMAT_FREE_RUNNING;
+
+	if (ts_format == MLX5_QPC_TIMESTAMP_FORMAT_FREE_RUNNING &&
+	    !fr_supported) {
+		mlx5_ib_dbg(dev, "Free running TS format is not supported\n");
+		return -EOPNOTSUPP;
+	}
+	return ts_format;
+}
+
 static int create_raw_packet_qp_sq(struct mlx5_ib_dev *dev,
 				   struct ib_udata *udata,
 				   struct mlx5_ib_sq *sq, void *qpin,
-				   struct ib_pd *pd)
+				   struct ib_pd *pd, struct mlx5_ib_cq *cq)
 {
 	struct mlx5_ib_ubuffer *ubuffer = &sq->ubuffer;
 	__be64 *pas;
@@ -1188,6 +1251,11 @@ static int create_raw_packet_qp_sq(struct mlx5_ib_dev *dev,
 	int err;
 	unsigned int page_offset_quantized;
 	unsigned long page_size;
+	int ts_format;
+
+	ts_format = get_sq_ts_format(dev, cq);
+	if (ts_format < 0)
+		return ts_format;

 	sq->ubuffer.umem = ib_umem_get_peer(&dev->ib_dev, ubuffer->buf_addr,
 				       ubuffer->buf_size, 0, 0);
@@ -1216,6 +1284,7 @@ static int create_raw_packet_qp_sq(struct mlx5_ib_dev *dev,
 	if (MLX5_CAP_ETH(dev->mdev, multi_pkt_send_wqe))
 		MLX5_SET(sqc, sqc, allow_multi_pkt_send_wqe, 1);
 	MLX5_SET(sqc, sqc, state, MLX5_SQC_STATE_RST);
+	MLX5_SET(sqc, sqc, ts_format, ts_format);
 	MLX5_SET(sqc, sqc, user_index, MLX5_GET(qpc, qpc, user_index));
 	MLX5_SET(sqc, sqc, cqn, MLX5_GET(qpc, qpc, cqn_snd));
 	MLX5_SET(sqc, sqc, tis_lst_sz, 1);
@@ -1264,7 +1333,7 @@ static void destroy_raw_packet_qp_sq(struct mlx5_ib_dev *dev,

 static int create_raw_packet_qp_rq(struct mlx5_ib_dev *dev,
 				   struct mlx5_ib_rq *rq, void *qpin,
-				   struct ib_pd *pd)
+				   struct ib_pd *pd, struct mlx5_ib_cq *cq)
 {
 	struct mlx5_ib_qp *mqp = rq->base.container_mibqp;
 	__be64 *pas;
@@ -1275,9 +1344,14 @@ static int create_raw_packet_qp_rq(struct mlx5_ib_dev *dev,
 	struct ib_umem *umem = rq->base.ubuffer.umem;
 	unsigned int page_offset_quantized;
 	unsigned long page_size = 0;
+	int ts_format;
 	size_t inlen;
 	int err;

+	ts_format = get_rq_ts_format(dev, cq);
+	if (ts_format < 0)
+		return ts_format;
+
 	page_size = mlx5_umem_find_best_quantized_pgoff(umem, wq, log_wq_pg_sz,
 							MLX5_ADAPTER_PAGE_SHIFT,
 							page_offset, 64,
@@ -1297,6 +1371,7 @@ static int create_raw_packet_qp_rq(struct mlx5_ib_dev *dev,
 		MLX5_SET(rqc, rqc, vsd, 1);
 	MLX5_SET(rqc, rqc, mem_rq_type, MLX5_RQC_MEM_RQ_TYPE_MEMORY_RQ_INLINE);
 	MLX5_SET(rqc, rqc, state, MLX5_RQC_STATE_RST);
+	MLX5_SET(rqc, rqc, ts_format, ts_format);
 	MLX5_SET(rqc, rqc, flush_in_error_en, 1);
 	MLX5_SET(rqc, rqc, user_index, MLX5_GET(qpc, qpc, user_index));
 	MLX5_SET(rqc, rqc, cqn, MLX5_GET(qpc, qpc, cqn_rcv));
@@ -1394,10 +1469,10 @@ static int create_raw_packet_qp_tir(struct mlx5_ib_dev *dev,
 }

 static int create_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
-				u32 *in, size_t inlen,
-				struct ib_pd *pd,
+				u32 *in, size_t inlen, struct ib_pd *pd,
 				struct ib_udata *udata,
-				struct mlx5_ib_create_qp_resp *resp)
+				struct mlx5_ib_create_qp_resp *resp,
+				struct ib_qp_init_attr *init_attr)
 {
 	struct mlx5_ib_raw_packet_qp *raw_packet_qp = &qp->raw_packet_qp;
 	struct mlx5_ib_sq *sq = &raw_packet_qp->sq;
@@ -1416,7 +1491,8 @@ static int create_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
 		if (err)
 			return err;

-		err = create_raw_packet_qp_sq(dev, udata, sq, in, pd);
+		err = create_raw_packet_qp_sq(dev, udata, sq, in, pd,
+					      to_mcq(init_attr->send_cq));
 		if (err)
 			goto err_destroy_tis;

@@ -1438,7 +1514,8 @@ static int create_raw_packet_qp(struct mlx5_ib_dev *dev, struct mlx5_ib_qp *qp,
 			rq->flags |= MLX5_IB_RQ_CVLAN_STRIPPING;
 		if (qp->flags & IB_QP_CREATE_PCI_WRITE_END_PADDING)
 			rq->flags |= MLX5_IB_RQ_PCI_WRITE_END_PADDING;
-		err = create_raw_packet_qp_rq(dev, rq, in, pd);
+		err = create_raw_packet_qp_rq(dev, rq, in, pd,
+					      to_mcq(init_attr->recv_cq));
 		if (err)
 			goto err_destroy_sq;

@@ -1908,6 +1985,7 @@ static int create_user_qp(struct mlx5_ib_dev *dev, struct ib_pd *pd,
 	struct mlx5_ib_cq *recv_cq;
 	unsigned long flags;
 	struct mlx5_ib_qp_base *base;
+	int ts_format;
 	int mlx5_st;
 	void *qpc;
 	u32 *in;
@@ -1945,6 +2023,13 @@ static int create_user_qp(struct mlx5_ib_dev *dev, struct ib_pd *pd,
 	if (ucmd->sq_wqe_count > (1 << MLX5_CAP_GEN(mdev, log_max_qp_sz)))
 		return -EINVAL;

+	if (init_attr->qp_type != IB_QPT_RAW_PACKET) {
+		ts_format = get_qp_ts_format(dev, to_mcq(init_attr->send_cq),
+					     to_mcq(init_attr->recv_cq));
+		if (ts_format < 0)
+			return ts_format;
+	}
+
 	err = _create_user_qp(dev, pd, qp, udata, init_attr, &in, &params->resp,
 			      &inlen, base, ucmd);
 	if (err)
@@ -1993,6 +2078,9 @@ static int create_user_qp(struct mlx5_ib_dev *dev, struct ib_pd *pd,
 		MLX5_SET(qpc, qpc, log_rq_size, ilog2(qp->rq.wqe_cnt));
 	}

+	if (init_attr->qp_type != IB_QPT_RAW_PACKET)
+		MLX5_SET(qpc, qpc, ts_format, ts_format);
+
 	MLX5_SET(qpc, qpc, rq_type, get_rx_type(qp, init_attr));

 	if (qp->sq.wqe_cnt) {
@@ -2047,7 +2135,7 @@ static int create_user_qp(struct mlx5_ib_dev *dev, struct ib_pd *pd,
 		qp->raw_packet_qp.sq.ubuffer.buf_addr = ucmd->sq_buf_addr;
 		raw_packet_qp_copy_info(qp, &qp->raw_packet_qp);
 		err = create_raw_packet_qp(dev, qp, in, inlen, pd, udata,
-					   &params->resp);
+					   &params->resp, init_attr);
 	} else
 		err = mlx5_qpc_create_qp(dev, &base->mqp, in, inlen, out);

--
2.29.2

Re: [PATCH mlx5-next 1/2] net/mlx5: Add new timestamp mode bits

[Jakub Kicinski]

On Tue,  9 Feb 2021 15:11:06 +0200 Leon Romanovsky wrote:
> From: Aharon Landau <aharonl@nvidia.com>
> 
> These fields declare which timestamp mode is supported by the device
> per RQ/SQ/QP.
> 
> In addiition add the ts_format field to the select the mode for
> RQ/SQ/QP.
> 
> Signed-off-by: Aharon Landau <aharonl@nvidia.com>
> Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>

We only got patch 1 which explains very little.

You also need to CC Richard.

Re: [PATCH mlx5-next 1/2] net/mlx5: Add new timestamp mode bits

[Leon Romanovsky]

On Tue, Feb 09, 2021 at 10:28:25AM -0800, Jakub Kicinski wrote:
> On Tue,  9 Feb 2021 15:11:06 +0200 Leon Romanovsky wrote:
> > From: Aharon Landau <aharonl@nvidia.com>
> >
> > These fields declare which timestamp mode is supported by the device
> > per RQ/SQ/QP.
> >
> > In addiition add the ts_format field to the select the mode for
> > RQ/SQ/QP.
> >
> > Signed-off-by: Aharon Landau <aharonl@nvidia.com>
> > Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>
> We only got patch 1 which explains very little.

I will change my scripts to ensure that all people will be always CCed
on whole series.

https://lore.kernel.org/linux-rdma/20210209131107.698833-3-leon@kernel.org

>
> You also need to CC Richard.

We are not talking about PTP, but about specific to RDMA timestamp mechanism
which is added to the CQE (completion queue entry) per-user request when
he/she creates CQ (completion queue). User has an option to choose the format
of it for every QP/RQ/SQ.

https://github.com/linux-rdma/rdma-core/blob/master/libibverbs/man/ibv_create_cq_ex.3#L44

Thanks

Re: [PATCH mlx5-next 1/2] net/mlx5: Add new timestamp mode bits

[Jakub Kicinski]

On Tue, 9 Feb 2021 21:14:24 +0200 Leon Romanovsky wrote:
> On Tue, Feb 09, 2021 at 10:28:25AM -0800, Jakub Kicinski wrote:
> > On Tue,  9 Feb 2021 15:11:06 +0200 Leon Romanovsky wrote:  
> > You also need to CC Richard.  
> 
> We are not talking about PTP, but about specific to RDMA timestamp mechanism
> which is added to the CQE (completion queue entry) per-user request when
> he/she creates CQ (completion queue). User has an option to choose the format
> of it for every QP/RQ/SQ.

I see. Perhaps Richard won't be interested then but best to give him 
a chance.

Not directly related to series at hand but how is the clock synchronized
between system and device for the real time option?

Re: [PATCH mlx5-next 1/2] net/mlx5: Add new timestamp mode bits

[Leon Romanovsky]

On Tue, Feb 09, 2021 at 11:52:54AM -0800, Jakub Kicinski wrote:
> On Tue, 9 Feb 2021 21:14:24 +0200 Leon Romanovsky wrote:
> > On Tue, Feb 09, 2021 at 10:28:25AM -0800, Jakub Kicinski wrote:
> > > On Tue,  9 Feb 2021 15:11:06 +0200 Leon Romanovsky wrote:
> > > You also need to CC Richard.
> >
> > We are not talking about PTP, but about specific to RDMA timestamp mechanism
> > which is added to the CQE (completion queue entry) per-user request when
> > he/she creates CQ (completion queue). User has an option to choose the format
> > of it for every QP/RQ/SQ.
>
> I see. Perhaps Richard won't be interested then but best to give him
> a chance.
>
> Not directly related to series at hand but how is the clock synchronized
> between system and device for the real time option?

When device works in real time mode, driver can skip cycles to ns translation
it does today in order to provide recv/sent SKB NS TS to the stack. Real time
mode does not require any changes above driver level and the synchronization
to system clock will remain as is today. The mlx5e soon to support this mode.

This series is needed to keep RDMA compatibility and fail QP creation for wrong mode.

Thanks

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Jason Gunthorpe]

On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> Add an extra timestamp format for mlx5_ib device.
> 
> Thanks
> 
> Aharon Landau (2):
>   net/mlx5: Add new timestamp mode bits
>   RDMA/mlx5: Fail QP creation if the device can not support the CQE TS
> 
>  drivers/infiniband/hw/mlx5/qp.c | 104 +++++++++++++++++++++++++++++---
>  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
>  2 files changed, 145 insertions(+), 13 deletions(-)

Since this is a rdma series, and we are at the end of the cycle, I
took the IFC file directly to the rdma tree instead of through the
shared branch.

Applied to for-next, thanks

Jason

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Saeed Mahameed]

On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > Add an extra timestamp format for mlx5_ib device.
> > 
> > Thanks
> > 
> > Aharon Landau (2):
> >   net/mlx5: Add new timestamp mode bits
> >   RDMA/mlx5: Fail QP creation if the device can not support the CQE
> > TS
> > 
> >  drivers/infiniband/hw/mlx5/qp.c | 104
> > +++++++++++++++++++++++++++++---
> >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> >  2 files changed, 145 insertions(+), 13 deletions(-)
> 
> Since this is a rdma series, and we are at the end of the cycle, I
> took the IFC file directly to the rdma tree instead of through the
> shared branch.
> 
> Applied to for-next, thanks
> 

mmm, i was planing to resubmit this patch with the netdev real time
support series, since the uplink representor is getting delayed, I
thought I could submit the real time stuff today. can you wait on the
ifc patch, i will re-send it today if you will, but it must go through
the shared branch

Thanks.

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Jason Gunthorpe]

On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@nvidia.com>
> > > 
> > > Add an extra timestamp format for mlx5_ib device.
> > > 
> > > Thanks
> > > 
> > > Aharon Landau (2):
> > >   net/mlx5: Add new timestamp mode bits
> > >   RDMA/mlx5: Fail QP creation if the device can not support the CQE
> > > TS
> > > 
> > >  drivers/infiniband/hw/mlx5/qp.c | 104
> > > +++++++++++++++++++++++++++++---
> > >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> > >  2 files changed, 145 insertions(+), 13 deletions(-)
> > 
> > Since this is a rdma series, and we are at the end of the cycle, I
> > took the IFC file directly to the rdma tree instead of through the
> > shared branch.
> > 
> > Applied to for-next, thanks
> > 
> 
> mmm, i was planing to resubmit this patch with the netdev real time
> support series, since the uplink representor is getting delayed, I
> thought I could submit the real time stuff today. can you wait on the
> ifc patch, i will re-send it today if you will, but it must go through
> the shared branch

Friday of rc7 is a bit late to be sending new patches for the first
time, isn't it??

But sure, if you update the shared branch right now I'll fix up rdma.git

Jason

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Saeed Mahameed]

On Fri, 2021-02-12 at 17:14 -0400, Jason Gunthorpe wrote:
> On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> > On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > 
> > > > Add an extra timestamp format for mlx5_ib device.
> > > > 
> > > > Thanks
> > > > 
> > > > Aharon Landau (2):
> > > >   net/mlx5: Add new timestamp mode bits
> > > >   RDMA/mlx5: Fail QP creation if the device can not support the
> > > > CQE
> > > > TS
> > > > 
> > > >  drivers/infiniband/hw/mlx5/qp.c | 104
> > > > +++++++++++++++++++++++++++++---
> > > >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> > > >  2 files changed, 145 insertions(+), 13 deletions(-)
> > > 
> > > Since this is a rdma series, and we are at the end of the cycle,
> > > I
> > > took the IFC file directly to the rdma tree instead of through
> > > the
> > > shared branch.
> > > 
> > > Applied to for-next, thanks
> > > 
> > 
> > mmm, i was planing to resubmit this patch with the netdev real time
> > support series, since the uplink representor is getting delayed, I
> > thought I could submit the real time stuff today. can you wait on
> > the
> > ifc patch, i will re-send it today if you will, but it must go
> > through
> > the shared branch
> 
> Friday of rc7 is a bit late to be sending new patches for the first
> time, isn't it??

I know, uplink representor last minute mess !

> 
> But sure, if you update the shared branch right now I'll fix up
> rdma.git
> 

I can't put it in the shared brach without review, i will post it to
the netdev/rdma lists for two days at least for review and feedback.

Not critical though, this can wait for next rc1.. if you want to
proceed with what you already did.

Thanks

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Jason Gunthorpe]

On Fri, Feb 12, 2021 at 01:19:09PM -0800, Saeed Mahameed wrote:
> On Fri, 2021-02-12 at 17:14 -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> > > On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > > > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > 
> > > > > Add an extra timestamp format for mlx5_ib device.
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Aharon Landau (2):
> > > > >   net/mlx5: Add new timestamp mode bits
> > > > >   RDMA/mlx5: Fail QP creation if the device can not support the
> > > > > CQE
> > > > > TS
> > > > > 
> > > > >  drivers/infiniband/hw/mlx5/qp.c | 104
> > > > > +++++++++++++++++++++++++++++---
> > > > >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> > > > >  2 files changed, 145 insertions(+), 13 deletions(-)
> > > > 
> > > > Since this is a rdma series, and we are at the end of the cycle,
> > > > I
> > > > took the IFC file directly to the rdma tree instead of through
> > > > the
> > > > shared branch.
> > > > 
> > > > Applied to for-next, thanks
> > > > 
> > > 
> > > mmm, i was planing to resubmit this patch with the netdev real time
> > > support series, since the uplink representor is getting delayed, I
> > > thought I could submit the real time stuff today. can you wait on
> > > the
> > > ifc patch, i will re-send it today if you will, but it must go
> > > through
> > > the shared branch
> > 
> > Friday of rc7 is a bit late to be sending new patches for the first
> > time, isn't it??
> 
> I know, uplink representor last minute mess !
> 
> > 
> > But sure, if you update the shared branch right now I'll fix up
> > rdma.git
> > 
> 
> I can't put it in the shared brach without review, i will post it to
> the netdev/rdma lists for two days at least for review and feedback.

Well, I'm not going to take any different patches beyond right now
unless Linus does a rc8??

Just move this one IFC patch to the shared branch, it is obviously OK

Jason

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Leon Romanovsky]

On Fri, Feb 12, 2021 at 05:21:53PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 12, 2021 at 01:19:09PM -0800, Saeed Mahameed wrote:
> > On Fri, 2021-02-12 at 17:14 -0400, Jason Gunthorpe wrote:
> > > On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> > > > On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > > > > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > >
> > > > > > Add an extra timestamp format for mlx5_ib device.
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > Aharon Landau (2):
> > > > > >   net/mlx5: Add new timestamp mode bits
> > > > > >   RDMA/mlx5: Fail QP creation if the device can not support the
> > > > > > CQE
> > > > > > TS
> > > > > >
> > > > > >  drivers/infiniband/hw/mlx5/qp.c | 104
> > > > > > +++++++++++++++++++++++++++++---
> > > > > >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> > > > > >  2 files changed, 145 insertions(+), 13 deletions(-)
> > > > >
> > > > > Since this is a rdma series, and we are at the end of the cycle,
> > > > > I
> > > > > took the IFC file directly to the rdma tree instead of through
> > > > > the
> > > > > shared branch.
> > > > >
> > > > > Applied to for-next, thanks
> > > > >
> > > >
> > > > mmm, i was planing to resubmit this patch with the netdev real time
> > > > support series, since the uplink representor is getting delayed, I
> > > > thought I could submit the real time stuff today. can you wait on
> > > > the
> > > > ifc patch, i will re-send it today if you will, but it must go
> > > > through
> > > > the shared branch
> > >
> > > Friday of rc7 is a bit late to be sending new patches for the first
> > > time, isn't it??
> >
> > I know, uplink representor last minute mess !
> >
> > >
> > > But sure, if you update the shared branch right now I'll fix up
> > > rdma.git
> > >
> >
> > I can't put it in the shared brach without review, i will post it to
> > the netdev/rdma lists for two days at least for review and feedback.
>
> Well, I'm not going to take any different patches beyond right now
> unless Linus does a rc8??
>
> Just move this one IFC patch to the shared branch, it is obviously OK

OK, I'm curious to see the end result of all this last minute adventure.

Thanks

>
> Jason

Re: [PATCH rdma-next 0/2] Real time/free running timestamp support

[Leon Romanovsky]

On Sun, Feb 14, 2021 at 08:41:03AM +0200, Leon Romanovsky wrote:
> On Fri, Feb 12, 2021 at 05:21:53PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 12, 2021 at 01:19:09PM -0800, Saeed Mahameed wrote:
> > > On Fri, 2021-02-12 at 17:14 -0400, Jason Gunthorpe wrote:
> > > > On Fri, Feb 12, 2021 at 01:09:20PM -0800, Saeed Mahameed wrote:
> > > > > On Fri, 2021-02-12 at 14:10 -0400, Jason Gunthorpe wrote:
> > > > > > On Tue, Feb 09, 2021 at 03:11:05PM +0200, Leon Romanovsky wrote:
> > > > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > > >
> > > > > > > Add an extra timestamp format for mlx5_ib device.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Aharon Landau (2):
> > > > > > >   net/mlx5: Add new timestamp mode bits
> > > > > > >   RDMA/mlx5: Fail QP creation if the device can not support the
> > > > > > > CQE
> > > > > > > TS
> > > > > > >
> > > > > > >  drivers/infiniband/hw/mlx5/qp.c | 104
> > > > > > > +++++++++++++++++++++++++++++---
> > > > > > >  include/linux/mlx5/mlx5_ifc.h   |  54 +++++++++++++++--
> > > > > > >  2 files changed, 145 insertions(+), 13 deletions(-)
> > > > > >
> > > > > > Since this is a rdma series, and we are at the end of the cycle,
> > > > > > I
> > > > > > took the IFC file directly to the rdma tree instead of through
> > > > > > the
> > > > > > shared branch.
> > > > > >
> > > > > > Applied to for-next, thanks
> > > > > >
> > > > >
> > > > > mmm, i was planing to resubmit this patch with the netdev real time
> > > > > support series, since the uplink representor is getting delayed, I
> > > > > thought I could submit the real time stuff today. can you wait on
> > > > > the
> > > > > ifc patch, i will re-send it today if you will, but it must go
> > > > > through
> > > > > the shared branch
> > > >
> > > > Friday of rc7 is a bit late to be sending new patches for the first
> > > > time, isn't it??
> > >
> > > I know, uplink representor last minute mess !
> > >
> > > >
> > > > But sure, if you update the shared branch right now I'll fix up
> > > > rdma.git
> > > >
> > >
> > > I can't put it in the shared brach without review, i will post it to
> > > the netdev/rdma lists for two days at least for review and feedback.
> >
> > Well, I'm not going to take any different patches beyond right now
> > unless Linus does a rc8??
> >
> > Just move this one IFC patch to the shared branch, it is obviously OK
>
> OK, I'm curious to see the end result of all this last minute adventure.

Jason,

I took first patch to the shared branch.
a6a217dddcd5 net/mlx5: Add new timestamp mode bits

Thanks

>
> Thanks
>
> >
> > Jason