Skip to contentSkip to conversation

ionic: RDMA completion timestamping support

PATCH Applied Abhijit Gangurde 3 participants 17 messages Jun 10 – Oct 30

Subsystems (6)
lore
Share & tools
lore

Abhijit Gangurde

author maintainer
#0 lore raw

v4 cover ionic: RDMA completion timestamping support

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

 .../infiniband/hw/ionic/ionic_controlpath.c   | 34 ++++++++++
 drivers/infiniband/hw/ionic/ionic_datapath.c  | 43 ++++++-------
 drivers/infiniband/hw/ionic/ionic_fw.h        | 12 +++-
 drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 +
 drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 +
 drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
 .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 ++--
 .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
 .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 +-
 .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
 .../net/ethernet/pensando/ionic/ionic_phc.c   | 63 ++++++++++++++++---
 include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++
 include/uapi/rdma/ionic-abi.h                 |  1 +
 include/uapi/rdma/mlx5-abi.h                  | 15 ++---
 14 files changed, 179 insertions(+), 48 deletions(-)
Signature · 1 line
2.43.0
author maintainer
#1 lore raw

PATCH v4 1/5 net: ionic: register PHC for rdma timestamping

Currently, the driver only registers the PTP Hardware Clock (PHC) if Ethernet hardware timestamping is supported. Update the registration logic to register the PHC if the device supports either Ethernet hardware timestamping or RDMA completion timestamping.

---
 .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 +++++++----
 .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
 .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 ++++-
 .../net/ethernet/pensando/ionic/ionic_phc.c   | 20 ++++++++++++-------
 4 files changed, 26 insertions(+), 12 deletions(-)
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c +8 -4
index 78a802eb159f..154ea1bef85d 100644
@@ -1018,10 +1018,14 @@ static int ionic_get_ts_info(struct net_device *netdev,
 
 	info->phc_index = ptp_clock_index(lif->phc->ptp);
 
-	info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
-				SOF_TIMESTAMPING_TX_HARDWARE |
-				SOF_TIMESTAMPING_RX_HARDWARE |
-				SOF_TIMESTAMPING_RAW_HARDWARE;
+	info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE;
+
+	if (!(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
+		return 0;
+
+	info->so_timestamping |= SOF_TIMESTAMPING_TX_HARDWARE |
+				 SOF_TIMESTAMPING_RX_HARDWARE |
+				 SOF_TIMESTAMPING_RAW_HARDWARE;
 
 	/* tx modes */
 
drivers/net/ethernet/pensando/ionic/ionic_if.h +1 -0
index 23d6e2b4791e..49d451c686b7 100644
@@ -1179,6 +1179,7 @@ enum ionic_eth_hw_features {
 	IONIC_ETH_HW_TX_CSUM_GENEVE	= BIT(18),
 	IONIC_ETH_HW_TSO_GENEVE		= BIT(19),
 	IONIC_ETH_HW_TIMESTAMP		= BIT(20),
+	IONIC_ETH_HW_RDMA_TIMESTAMP	= BIT(21),
 };
 
 /**
drivers/net/ethernet/pensando/ionic/ionic_lif.c +4 -1
index 637e635bbf03..9d86f795f5f6 100644
@@ -1498,7 +1498,8 @@ static int ionic_set_nic_features(struct ionic_lif *lif,
 	ctx.cmd.lif_setattr.features = ionic_netdev_features_to_nic(features);
 
 	if (lif->phc)
-		ctx.cmd.lif_setattr.features |= cpu_to_le64(IONIC_ETH_HW_TIMESTAMP);
+		ctx.cmd.lif_setattr.features |= lif->ionic->ident.lif.eth.config.features &
+			cpu_to_le64(IONIC_ETH_HW_TIMESTAMP | IONIC_ETH_HW_RDMA_TIMESTAMP);
 
 	err = ionic_adminq_post_wait(lif, &ctx);
 	if (err)
@@ -1549,6 +1550,8 @@ static int ionic_set_nic_features(struct ionic_lif *lif,
 		dev_dbg(dev, "feature ETH_HW_TSO_UDP_CSUM\n");
 	if (lif->hw_features & IONIC_ETH_HW_TIMESTAMP)
 		dev_dbg(dev, "feature ETH_HW_TIMESTAMP\n");
+	if (lif->hw_features & IONIC_ETH_HW_RDMA_TIMESTAMP)
+		dev_dbg(dev, "feature ETH_HW_RDMA_TIMESTAMP\n");
 
 	return 0;
 }
drivers/net/ethernet/pensando/ionic/ionic_phc.c +13 -7
index 05b44fc482f8..116408099974 100644
@@ -77,7 +77,8 @@ static int ionic_lif_hwstamp_set_ts_config(struct ionic_lif *lif,
 	bool rx_all;
 	__le64 mask;
 
-	if (!lif->phc || !lif->phc->ptp)
+	if (!lif->phc || !lif->phc->ptp ||
+	    !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
 		return -EOPNOTSUPP;
 
 	mutex_lock(&lif->phc->config_lock);
@@ -210,7 +211,8 @@ int ionic_hwstamp_set(struct net_device *netdev,
 	struct ionic_lif *lif = netdev_priv(netdev);
 	int err;
 
-	if (!lif->phc || !lif->phc->ptp)
+	if (!lif->phc || !lif->phc->ptp ||
+	    !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
 		return -EOPNOTSUPP;
 
 	mutex_lock(&lif->queue_lock);
@@ -228,7 +230,8 @@ void ionic_lif_hwstamp_replay(struct ionic_lif *lif)
 {
 	int err;
 
-	if (!lif->phc || !lif->phc->ptp)
+	if (!lif->phc || !lif->phc->ptp ||
+	    !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
 		return;
 
 	mutex_lock(&lif->queue_lock);
@@ -242,7 +245,8 @@ void ionic_lif_hwstamp_recreate_queues(struct ionic_lif *lif)
 {
 	int err;
 
-	if (!lif->phc || !lif->phc->ptp)
+	if (!lif->phc || !lif->phc->ptp ||
+	    !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
 		return;
 
 	mutex_lock(&lif->phc->config_lock);
@@ -267,7 +271,8 @@ int ionic_hwstamp_get(struct net_device *netdev,
 {
 	struct ionic_lif *lif = netdev_priv(netdev);
 
-	if (!lif->phc || !lif->phc->ptp)
+	if (!lif->phc || !lif->phc->ptp ||
+	    !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
 		return -EOPNOTSUPP;
 
 	mutex_lock(&lif->phc->config_lock);
@@ -506,7 +511,8 @@ static const struct ptp_clock_info ionic_ptp_info = {
 
 void ionic_lif_register_phc(struct ionic_lif *lif)
 {
-	if (!lif->phc || !(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
+	if (!lif->phc ||
+	    !(lif->hw_features & (IONIC_ETH_HW_TIMESTAMP | IONIC_ETH_HW_RDMA_TIMESTAMP)))
 		return;
 
 	lif->phc->ptp = ptp_clock_register(&lif->phc->ptp_info, lif->ionic->dev);
@@ -545,7 +551,7 @@ void ionic_lif_alloc_phc(struct ionic_lif *lif)
 		return;
 
 	features = le64_to_cpu(ionic->ident.lif.eth.config.features);
-	if (!(features & IONIC_ETH_HW_TIMESTAMP))
+	if (!(features & (IONIC_ETH_HW_TIMESTAMP | IONIC_ETH_HW_RDMA_TIMESTAMP)))
 		return;
 
 	phc = devm_kzalloc(ionic->dev, sizeof(*phc), GFP_KERNEL);
Signature · 1 line
2.43.0
#2 lore raw

Re: [for-next v4 1/5] net: ionic: register PHC for rdma timestamping

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] ionic_get_ts_info incorrectly drops software timestamping capabilities for devices supporting…

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ionic_get_ts_info incorrectly drops software timestamping capabilities for devices supporting only RDMA timestamping. --

commit e70a276bad5dcce2118c120bed8e5cd4bc2c22fd
Author: Abhijit Gangurde <[email protected]>

net: ionic: register PHC for rdma timestamping

Currently, the driver only registers the PTP Hardware Clock (PHC) if Ethernet hardware timestamping is supported. Update the registration logic to register the PHC if the device supports either Ethernet hardware timestamping or RDMA completion timestamping.

Quoted 6 lines
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c +0 -0
index 78a802eb159f0..154ea1bef85d9 100644
@@ -1018,10 +1018,14 @@ static int ionic_get_ts_info(struct net_device *netdev,
 

drivers/net/ethernet/pensando/ionic/ionic_ethtool.c static int ionic_get_ts_info(struct net_device *netdev, · line 1024

Quoted 10 lines
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c +4 -4
 	info->phc_index = ptp_clock_index(lif->phc->ptp);
 
-	info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
-				SOF_TIMESTAMPING_TX_HARDWARE |
-				SOF_TIMESTAMPING_RX_HARDWARE |
-				SOF_TIMESTAMPING_RAW_HARDWARE;
+	info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE;
+
+	if (!(lif->hw_features & IONIC_ETH_HW_TIMESTAMP))
+		return 0;

[Severity: Medium]
Does this early return omit software timestamping capabilities for devices that only support RDMA timestamping?

Before this patch, devices supporting only RDMA timestamping (where IONIC_ETH_HW_RDMA_TIMESTAMP is present but IONIC_ETH_HW_TIMESTAMP is not) did not allocate lif->phc. Because lif->phc was NULL, ionic_get_ts_info() would fall back to ethtool_op_get_ts_info(), which correctly advertises SOF_TIMESTAMPING_TX_SOFTWARE, SOF_TIMESTAMPING_RX_SOFTWARE, and SOF_TIMESTAMPING_SOFTWARE.

With this patch, lif->phc is allocated for RDMA-only devices, causing the ethtool_op_get_ts_info() fallback to be skipped. The custom logic here only sets SOF_TIMESTAMPING_TX_SOFTWARE and then returns 0, dropping the SOF_TIMESTAMPING_RX_SOFTWARE and SOF_TIMESTAMPING_SOFTWARE capabilities for these interfaces.

Quoted 4 lines
drivers/net/ethernet/pensando/ionic/ionic_ethtool.c +4 -0
+
+	info->so_timestamping |= SOF_TIMESTAMPING_TX_HARDWARE |
+				 SOF_TIMESTAMPING_RX_HARDWARE |
+				 SOF_TIMESTAMPING_RAW_HARDWARE;
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
author maintainer
#3 lore raw

PATCH v4 2/5 net: ionic: Add PHC state page for user space access

In reply to Abhijit Gangurde

Add a page associated with the PHC that can be mapped to user space, allowing applications to access hardware timestamp information.

In order to synchronize between kernel and user space, a sequence number is incremented at the beginning and end of each update. An odd number means the data is being updated while an even number means the update is complete. To guarantee that the data structure was accessed atomically, user space will:

repeat:
seq1 = <read sequence>
goto <repeat> if odd
<read PHC state>
seq2 = <read sequence>
if seq1 != seq2 goto repeat

This mechanism acts as a guard against reading invalid state during concurrent updates.

---
 .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
 .../net/ethernet/pensando/ionic/ionic_phc.c   | 43 +++++++++++++++++++
 include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++++++
 3 files changed, 78 insertions(+), 1 deletion(-)
drivers/net/ethernet/pensando/ionic/ionic_lif.h +2 -1
index 8e10f66dc50e..42581ddd18ae 100644
@@ -249,7 +249,7 @@ struct ionic_lif {
 };
 
 struct ionic_phc {
-	spinlock_t lock; /* lock for cc and tc */
+	spinlock_t lock; /* lock for state_page, cc and tc */
 	struct cyclecounter cc;
 	struct timecounter tc;
 
@@ -262,6 +262,7 @@ struct ionic_phc {
 	long aux_work_delay;
 
 	struct ptp_clock_info ptp_info;
+	struct ib_uverbs_clock_info *state_page;
 	struct ptp_clock *ptp;
 	struct ionic_lif *lif;
 };
drivers/net/ethernet/pensando/ionic/ionic_phc.c +43 -0

103 lines not on this page · raw message

include/uapi/rdma/ib_user_verbs.h +33 -0
index d2aeadb6d2f9..565301594634 100644
@@ -1379,4 +1379,37 @@ enum ib_uverbs_raw_packet_caps {
 	IB_UVERBS_RAW_PACKET_CAP_DELAY_DROP = 1 << 3,
 };
 
+/*
+ * struct ib_uverbs_clock_info - timecounter state shared with userspace
+ *
+ * Drivers that use a software timecounter over a free-running hardware
+ * cycle counter can map this page read-only into userspace, allowing
+ * conversion of hardware timestamps to system time without a syscall.
+ *
+ * Synchronization uses a sequence counter (@sign): the kernel sets bit 0
+ * before updating, then advances by 2 after. Userspace must retry the read
+ * if @sign is odd or changed during the read.
+ *
+ * @sign:            Sequence counter (bit 0 = update in progress)
+ * @resv:            Reserved
+ * @nsec:            Nanoseconds at last update
+ * @cycles:          Cycle counter value at last update
+ * @frac:            Fractional nanoseconds at last update
+ * @mult:            Cycle-to-nanosecond multiplier
+ * @shift:           Cycle-to-nanosecond shift
+ * @mask:            Cycle counter bitmask
+ * @overflow_period: Max interval (nsec) between reads before counter wraps
+ */
+struct ib_uverbs_clock_info {
+	__u32 sign;
+	__u32 resv;
+	__aligned_u64 nsec;
+	__aligned_u64 cycles;
+	__aligned_u64 frac;
+	__u32 mult;
+	__u32 shift;
+	__aligned_u64 mask;
+	__aligned_u64 overflow_period;
+};
+
 #endif /* IB_USER_VERBS_H */
Signature · 1 line
2.43.0
#4 lore raw

Re: [for-next v4 2/5] net: ionic: Add PHC state page for user space access

Sashiko has reviewed this patch and found no issues.
Quoted 16 lines

Add a page associated with the PHC that can be mapped to user space, allowing applications to access hardware timestamp information.

In order to synchronize between kernel and user space, a sequence number is incremented at the beginning and end of each update. An odd number means the data is being updated while an even number means the update is complete. To guarantee that the data structure was accessed atomically, user space will:

repeat:
seq1 = <read sequence>
goto <repeat> if odd
<read PHC state>
seq2 = <read sequence>
if seq1 != seq2 goto repeat

Quoted 6 lines

This mechanism acts as a guard against reading invalid state during concurrent updates.

Sashiko has reviewed this patch and found no issues.

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
author maintainer
#5 lore raw

PATCH v4 3/5 RDMA/ionic: map PHC state into user space

In reply to Abhijit Gangurde

Enable user space applications to access the PHC state page when firmware RDMA completion timestamp is supported.

This mapping allows user space to convert RDMA completion timestamps to system wall time without kernel transitions, minimizing latency overhead. Applications can directly read the PHC state through mmap, enabling efficient timestamp correlation for precision timing applications.

---
 .../infiniband/hw/ionic/ionic_controlpath.c   | 34 +++++++++++++++++++
 drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 ++
 drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 ++
 drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
 include/uapi/rdma/ionic-abi.h                 |  1 +
 5 files changed, 40 insertions(+)
drivers/infiniband/hw/ionic/ionic_controlpath.c +34 -0
index db18c315cc21..29d670fd2ddd 100644
@@ -391,6 +391,16 @@ int ionic_alloc_ucontext(struct ib_ucontext *ibctx, struct ib_udata *udata)
 		goto err_mmap_dbell;
 	}
 
+	if (dev->lif_cfg.phc_state) {
+		ctx->mmap_phc = ionic_mmap_entry_insert(ctx, PAGE_SIZE, 0,
+							IONIC_MMAP_PHC,
+							&resp.phc_offset);
+		if (!ctx->mmap_phc) {
+			rc = -ENOMEM;
+			goto err_mmap_phc;
+		}
+	}
+
 	resp.page_shift = PAGE_SHIFT;
 
 	resp.dbell_offset = db_phys & ~PAGE_MASK;
@@ -421,6 +431,8 @@ int ionic_alloc_ucontext(struct ib_ucontext *ibctx, struct ib_udata *udata)
 	return 0;
 
 err_resp:
+	rdma_user_mmap_entry_remove(ctx->mmap_phc);
+err_mmap_phc:
 	rdma_user_mmap_entry_remove(ctx->mmap_dbell);
 err_mmap_dbell:
 	ionic_put_dbid(dev, ctx->dbid);
@@ -433,10 +445,26 @@ void ionic_dealloc_ucontext(struct ib_ucontext *ibctx)
 	struct ionic_ibdev *dev = to_ionic_ibdev(ibctx->device);
 	struct ionic_ctx *ctx = to_ionic_ctx(ibctx);
 
+	rdma_user_mmap_entry_remove(ctx->mmap_phc);
 	rdma_user_mmap_entry_remove(ctx->mmap_dbell);
 	ionic_put_dbid(dev, ctx->dbid);
 }
 
+static int ionic_mmap_phc_state(struct ionic_ibdev *dev,
+				struct vm_area_struct *vma)
+{
+	if (!(vma->vm_flags & VM_SHARED))
+		return -EINVAL;
+
+	if (vma->vm_flags & (VM_WRITE | VM_EXEC))
+		return -EPERM;
+
+	vm_flags_clear(vma, VM_MAYWRITE);
+
+	return vm_insert_page(vma, vma->vm_start,
+			      virt_to_page(dev->lif_cfg.phc_state));
+}
+
 int ionic_mmap(struct ib_ucontext *ibctx, struct vm_area_struct *vma)
 {
 	struct ionic_ibdev *dev = to_ionic_ibdev(ibctx->device);
@@ -455,6 +483,12 @@ int ionic_mmap(struct ib_ucontext *ibctx, struct vm_area_struct *vma)
 	ionic_entry = container_of(rdma_entry, struct ionic_mmap_entry,
 				   rdma_entry);
 
+	if (ionic_entry->mmap_flags & IONIC_MMAP_PHC) {
+		rc = ionic_mmap_phc_state(dev, vma);
+		rdma_user_mmap_entry_put(rdma_entry);
+		return rc;
+	}
+
 	ibdev_dbg(&dev->ibdev, "writecombine? %d\n",
 		  ionic_entry->mmap_flags & IONIC_MMAP_WC);
 	if (ionic_entry->mmap_flags & IONIC_MMAP_WC)
drivers/infiniband/hw/ionic/ionic_ibdev.h +2 -0
index 63828240d659..08655c4d8297 100644
@@ -72,6 +72,7 @@ enum ionic_admin_flags {
 
 enum ionic_mmap_flag {
 	IONIC_MMAP_WC = BIT(0),
+	IONIC_MMAP_PHC = BIT(1),
 };
 
 struct ionic_mmap_entry {
@@ -173,6 +174,7 @@ struct ionic_ctx {
 	struct ib_ucontext	ibctx;
 	u32			dbid;
 	struct rdma_user_mmap_entry	*mmap_dbell;
+	struct rdma_user_mmap_entry	*mmap_phc;
 };
 
 struct ionic_tbl_buf {
drivers/infiniband/hw/ionic/ionic_lif_cfg.c +2 -0
index f3cd281c3a2f..f827dce59973 100644
@@ -40,6 +40,8 @@ void ionic_fill_lif_cfg(struct ionic_lif *lif, struct ionic_lif_cfg *cfg)
 	cfg->dbid_count = le32_to_cpu(lif->ionic->ident.dev.ndbpgs_per_lif);
 	cfg->dbpage = lif->kern_dbpage;
 	cfg->intr_ctrl = lif->ionic->idev.intr_ctrl;
+	if (lif->phc)
+		cfg->phc_state = lif->phc->state_page;
 
 	cfg->db_phys = lif->ionic->bars[IONIC_PCI_BAR_DBELL].bus_addr;
 
drivers/infiniband/hw/ionic/ionic_lif_cfg.h +1 -0
index 20853429f623..2b29e646c193 100644
@@ -23,6 +23,7 @@ struct ionic_lif_cfg {
 	u64 __iomem *dbpage;
 	struct ionic_intr __iomem *intr_ctrl;
 	phys_addr_t db_phys;
+	void *phc_state;
 
 	u64 page_size_supported;
 	u32 npts_per_lif;
include/uapi/rdma/ionic-abi.h +1 -0
index 7b589d3e9728..2c70ac149c4f 100644
@@ -48,6 +48,7 @@ struct ionic_ctx_resp {
 	__u8 expdb_qtypes;
 
 	__u8 rsvd2[3];
+	__aligned_u64 phc_offset;
 };
 
 struct ionic_qdesc {
Signature · 1 line
2.43.0
#6 lore raw

Re: [for-next v4 3/5] RDMA/ionic: map PHC state into user space

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Critical] Unconstrained ib_copy_to_udata causes out-of-bounds write in userspace memory and ABI…

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Unconstrained ib_copy_to_udata causes out-of-bounds write in userspace memory and ABI breakage. --

commit 92d10c24093a8b27cdd06722f8f50e627c7ca437
Author: Abhijit Gangurde <[email protected]>

RDMA/ionic: map PHC state into user space

This commit enables user space applications to access the PHC state page when firmware RDMA completion timestamping is supported. It maps the PHC state into user space to allow timestamp conversion without kernel transitions.

include/uapi/rdma/ionic-abi.h struct ionic_ctx_resp { · line 52

Quoted 10 lines
include/uapi/rdma/ionic-abi.h +1 -0
index 7b589d3e9728e..2c70ac149c4ff 100644
@@ -48,6 +48,7 @@ struct ionic_ctx_resp {
 	__u8 expdb_qtypes;
 
 	__u8 rsvd2[3];
+	__aligned_u64 phc_offset;
 };

[Severity: Critical]
Does adding phc_offset to ionic_ctx_resp break userspace ABI backward compatibility and cause an out-of-bounds write in userspace memory?

Looking at ionic_alloc_ucontext() in ionic_controlpath.c, the driver copies the response to userspace using the new, larger struct size:

    rc = ib_copy_to_udata(udata, &resp, sizeof(resp));

Since this commit increases the size of struct ionic_ctx_resp from 32 bytes to 40 bytes, and the copy uses sizeof(resp) without restricting the length to udata->outlen, won't older userspace binaries passing an outlen of 32 receive 40 bytes?

This appears to directly pass the larger length to copy_to_user() via ib_copy_to_udata(), potentially overflowing the userspace application's stack or heap buffer. Should the copy length be bounded by udata->outlen to safely support older userspace clients?

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
author maintainer
#7 lore raw

PATCH v4 4/5 RDMA/ionic: add completion timestamp to CQE format

In reply to Abhijit Gangurde

Update the CQE structure to include hardware timestamp. When firmware supports RDMA completion timestamps, the hardware populates the timestamp field.

---
 drivers/infiniband/hw/ionic/ionic_datapath.c | 43 ++++++++++----------
 drivers/infiniband/hw/ionic/ionic_fw.h       | 12 ++++--
 2 files changed, 31 insertions(+), 24 deletions(-)
drivers/infiniband/hw/ionic/ionic_datapath.c +22 -21
index aa2944887f23..3e2300f7ea10 100644
@@ -32,6 +32,7 @@ static int ionic_flush_recv(struct ionic_qp *qp, struct ib_wc *wc)
 {
 	struct ionic_rq_meta *meta;
 	struct ionic_v1_wqe *wqe;
+	u64 wqe_idx;
 
 	if (!qp->rq_flush)
 		return 0;
@@ -40,21 +41,22 @@ static int ionic_flush_recv(struct ionic_qp *qp, struct ib_wc *wc)
 		return 0;
 
 	wqe = ionic_queue_at_cons(&qp->rq);
+	wqe_idx = le64_to_cpu(wqe->base.wqe_idx);
 
-	/* wqe_id must be a valid queue index */
-	if (unlikely(wqe->base.wqe_id >> qp->rq.depth_log2)) {
+	/* wqe_idx must be a valid queue index */
+	if (unlikely(wqe_idx >> qp->rq.depth_log2)) {
 		ibdev_warn(qp->ibqp.device,
 			   "flush qp %u recv index %llu invalid\n",
-			   qp->qpid, (unsigned long long)wqe->base.wqe_id);
+			   qp->qpid, (unsigned long long)wqe_idx);
 		return -EIO;
 	}
 
-	/* wqe_id must indicate a request that is outstanding */
-	meta = &qp->rq_meta[wqe->base.wqe_id];
+	/* wqe_idx must indicate a request that is outstanding */
+	meta = &qp->rq_meta[wqe_idx];
 	if (unlikely(meta->next != IONIC_META_POSTED)) {
 		ibdev_warn(qp->ibqp.device,
 			   "flush qp %u recv index %llu not posted\n",
-			   qp->qpid, (unsigned long long)wqe->base.wqe_id);
+			   qp->qpid, (unsigned long long)wqe_idx);
 		return -EIO;
 	}
 
@@ -133,8 +135,8 @@ static int ionic_poll_recv(struct ionic_ibdev *dev, struct ionic_cq *cq,
 {
 	struct ionic_qp *qp = NULL;
 	struct ionic_rq_meta *meta;
+	u16 vlan_tag, wqe_idx;
 	u32 src_qpn, st_len;
-	u16 vlan_tag;
 	u8 op;
 
 	if (cqe_qp->rq_flush)
@@ -144,7 +146,7 @@ static int ionic_poll_recv(struct ionic_ibdev *dev, struct ionic_cq *cq,
 
 	st_len = be32_to_cpu(cqe->status_length);
 
-	/* ignore wqe_id in case of flush error */
+	/* ignore wqe_idx in case of flush error */
 	if (ionic_v1_cqe_error(cqe) && st_len == IONIC_STS_WQE_FLUSHED_ERR) {
 		cqe_qp->rq_flush = true;
 		cq->flush = true;
@@ -160,20 +162,19 @@ static int ionic_poll_recv(struct ionic_ibdev *dev, struct ionic_cq *cq,
 		return -EIO;
 	}
 
-	/* wqe_id must be a valid queue index */
-	if (unlikely(cqe->recv.wqe_id >> qp->rq.depth_log2)) {
+	wqe_idx = le64_to_cpu(cqe->recv.wqe_idx_timestamp) & IONIC_V1_CQE_WQE_IDX_MASK;
+	/* wqe_idx must be a valid queue index */
+	if (unlikely(wqe_idx >> qp->rq.depth_log2)) {
 		ibdev_warn(&dev->ibdev,
-			   "qp %u recv index %llu invalid\n",
-			   qp->qpid, (unsigned long long)cqe->recv.wqe_id);
+			   "qp %u recv index %u invalid\n", qp->qpid, wqe_idx);
 		return -EIO;
 	}
 
-	/* wqe_id must indicate a request that is outstanding */
-	meta = &qp->rq_meta[cqe->recv.wqe_id];
+	/* wqe_idx must indicate a request that is outstanding */
+	meta = &qp->rq_meta[wqe_idx];
 	if (unlikely(meta->next != IONIC_META_POSTED)) {
 		ibdev_warn(&dev->ibdev,
-			   "qp %u recv index %llu not posted\n",
-			   qp->qpid, (unsigned long long)cqe->recv.wqe_id);
+			   "qp %u recv index %u not posted\n", qp->qpid, wqe_idx);
 		return -EIO;
 	}
 
@@ -408,7 +409,7 @@ static int ionic_comp_msn(struct ionic_qp *qp, struct ionic_v1_cqe *cqe)
 static int ionic_comp_npg(struct ionic_qp *qp, struct ionic_v1_cqe *cqe)
 {
 	struct ionic_sq_meta *meta;
-	u16 cqe_idx;
+	u16 wqe_idx;
 	u32 st_len;
 
 	if (qp->sq_flush)
@@ -430,8 +431,8 @@ static int ionic_comp_npg(struct ionic_qp *qp, struct ionic_v1_cqe *cqe)
 		return 0;
 	}
 
-	cqe_idx = cqe->send.npg_wqe_id & qp->sq.mask;
-	meta = &qp->sq_meta[cqe_idx];
+	wqe_idx = le64_to_cpu(cqe->send.npg_wqe_idx_timestamp) & qp->sq.mask;
+	meta = &qp->sq_meta[wqe_idx];
 	meta->local_comp = true;
 
 	if (ionic_v1_cqe_error(cqe)) {
@@ -811,7 +812,7 @@ static void ionic_prep_base(struct ionic_qp *qp,
 	meta->signal = false;
 	meta->local_comp = false;
 
-	wqe->base.wqe_id = qp->sq.prod;
+	wqe->base.wqe_idx = cpu_to_le64(qp->sq.prod);
 
 	if (wr->send_flags & IB_SEND_FENCE)
 		wqe->base.flags |= cpu_to_be16(IONIC_V1_FLAG_FENCE);
@@ -1205,7 +1206,7 @@ static int ionic_prep_recv(struct ionic_qp *qp,
 
 	meta->wrid = wr->wr_id;
 
-	wqe->base.wqe_id = meta - qp->rq_meta;
+	wqe->base.wqe_idx = cpu_to_le64(meta - qp->rq_meta);
 	wqe->base.num_sge_key = wr->num_sge;
 
 	/* total length for recv goes in base imm_data_key */
drivers/infiniband/hw/ionic/ionic_fw.h +9 -3
index adfbb89d856c..ee23062a1762 100644
@@ -332,7 +332,7 @@ struct ionic_v1_cqe {
 			__le16		old_rq_cq_cindex;
 		} admin;
 		struct {
-			__u64		wqe_id;
+			__le64		wqe_idx_timestamp;
 			__be32		src_qpn_op;
 			__u8		src_mac[6];
 			__be16		vlan_tag;
@@ -342,13 +342,19 @@ struct ionic_v1_cqe {
 			__u8		rsvd[4];
 			__be32		msg_msn;
 			__u8		rsvd2[8];
-			__u64		npg_wqe_id;
+			__le64		npg_wqe_idx_timestamp;
 		} send;
 	};
 	__be32				status_length;
 	__be32				qid_type_flags;
 };
 
+/* bits for cqe wqe_idx and timestamp */
+enum ionic_v1_cqe_wqe_idx_timestamp_bits {
+	IONIC_V1_CQE_WQE_IDX_MASK	= 0xffff,
+	IONIC_V1_CQE_TIMESTAMP_SHIFT	= 16,
+};
+
 /* bits for cqe recv */
 enum ionic_v1_cqe_src_qpn_bits {
 	IONIC_V1_CQE_RECV_QPN_MASK	= 0xffffff,
@@ -423,7 +429,7 @@ static inline u32 ionic_v1_cqe_qtf_qid(u32 qtf)
 
 /* v1 base wqe header */
 struct ionic_v1_base_hdr {
-	__u64				wqe_id;
+	__le64				wqe_idx;
 	__u8				op;
 	__u8				num_sge_key;
 	__be16				flags;
Signature · 1 line
2.43.0
#8 lore raw

Re: [for-next v4 4/5] RDMA/ionic: add completion timestamp to CQE format

Sashiko has reviewed this patch and found no issues.
Quoted 7 lines

Update the CQE structure to include hardware timestamp. When firmware supports RDMA completion timestamps, the hardware populates the timestamp field.

Sashiko has reviewed this patch and found no issues.

Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
author maintainer
#9 lore raw

PATCH v4 5/5 RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

In reply to Abhijit Gangurde

Use struct ib_uverbs_clock_info from ib_user_verbs.h for clock info.

---
 include/uapi/rdma/mlx5-abi.h | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)
include/uapi/rdma/mlx5-abi.h +4 -11
index 8a6ad6c6841c..a39226cd62dc 100644
@@ -472,17 +472,10 @@ struct mlx5_ib_modify_wq {
 	__u32	reserved;
 };
 
-struct mlx5_ib_clock_info {
-	__u32 sign;
-	__u32 resv;
-	__aligned_u64 nsec;
-	__aligned_u64 cycles;
-	__aligned_u64 frac;
-	__u32 mult;
-	__u32 shift;
-	__aligned_u64 mask;
-	__aligned_u64 overflow_period;
-};
+/*
+ * deprecated, see struct ib_uverbs_clock_info from ib_user_verbs.h
+ */
+#define mlx5_ib_clock_info ib_uverbs_clock_info
 
 enum mlx5_ib_mmap_cmd {
 	MLX5_IB_MMAP_REGULAR_PAGE               = 0,
Signature · 1 line
2.43.0
author maintainer
#10 lore raw
In reply to Abhijit Gangurde

Hi Jason, Jakub,

Gentle ping — if there are no further concerns, could this series be merged through the rdma tree?

Thanks,
Abhijit

Quoted 51 lines · Abhijit Gangurde

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

  .../infiniband/hw/ionic/ionic_controlpath.c   | 34 ++++++++++
  drivers/infiniband/hw/ionic/ionic_datapath.c  | 43 ++++++-------
  drivers/infiniband/hw/ionic/ionic_fw.h        | 12 +++-
  drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 +
  drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 +
  drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
  .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 ++--
  .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
  .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 +-
  .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
  .../net/ethernet/pensando/ionic/ionic_phc.c   | 63 ++++++++++++++++---
  include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++
  include/uapi/rdma/ionic-abi.h                 |  1 +
  include/uapi/rdma/mlx5-abi.h                  | 15 ++---
  14 files changed, 179 insertions(+), 48 deletions(-)
#11 lore raw
Quoted 4 lines · Abhijit Gangurde

Hi Jason, Jakub,

Gentle ping — if there are no further concerns, could this series be merged through the rdma tree?

Jason requested converting any driver that extends udata to use uverbs_robust_udata.

https://lore.kernel.org/linux-rdma/[email protected]/

Thanks

Quoted 56 lines

Thanks,
Abhijit

Quoted 51 lines · Abhijit Gangurde

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

  .../infiniband/hw/ionic/ionic_controlpath.c   | 34 ++++++++++
  drivers/infiniband/hw/ionic/ionic_datapath.c  | 43 ++++++-------
  drivers/infiniband/hw/ionic/ionic_fw.h        | 12 +++-
  drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 +
  drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 +
  drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
  .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 ++--
  .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
  .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 +-
  .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
  .../net/ethernet/pensando/ionic/ionic_phc.c   | 63 ++++++++++++++++---
  include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++
  include/uapi/rdma/ionic-abi.h                 |  1 +
  include/uapi/rdma/mlx5-abi.h                  | 15 ++---
  14 files changed, 179 insertions(+), 48 deletions(-)
author maintainer
#12 lore raw

Thanks Leon. This is already addressed in https://patchwork.kernel.org/project/linux-rdma/patch/[email protected]/ which was sent after this series. Happy to rebase if needed.

Quoted 67 lines · Leon Romanovsky
Quoted 4 lines · Abhijit Gangurde

Hi Jason, Jakub,

Gentle ping — if there are no further concerns, could this series be merged through the rdma tree?

Jason requested converting any driver that extends udata to use uverbs_robust_udata.

https://lore.kernel.org/linux-rdma/[email protected]/

Thanks

Quoted 55 lines

Thanks,
Abhijit

Quoted 51 lines · Abhijit Gangurde

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

   .../infiniband/hw/ionic/ionic_controlpath.c   | 34 ++++++++++
   drivers/infiniband/hw/ionic/ionic_datapath.c  | 43 ++++++-------
   drivers/infiniband/hw/ionic/ionic_fw.h        | 12 +++-
   drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 +
   drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 +
   drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
   .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 ++--
   .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
   .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 +-
   .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
   .../net/ethernet/pensando/ionic/ionic_phc.c   | 63 ++++++++++++++++---
   include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++
   include/uapi/rdma/ionic-abi.h                 |  1 +
   include/uapi/rdma/mlx5-abi.h                  | 15 ++---
   14 files changed, 179 insertions(+), 48 deletions(-)
#13 lore raw
Quoted 2 lines · Abhijit Gangurde

Thanks Leon. This is already addressed in https://patchwork.kernel.org/project/linux-rdma/patch/[email protected]/
which was sent after this series. Happy to rebase if needed.

You need to rebase this, as we moved ib_respond_empty_udata() from the end of the function to the beginning.

Also, please send this as a separate patch or series.

Thanks.

Quoted 70 lines · Leon Romanovsky
Quoted 67 lines · Abhijit Gangurde
Quoted 4 lines

Hi Jason, Jakub,

Gentle ping — if there are no further concerns, could this series be merged through the rdma tree?

Jason requested converting any driver that extends udata to use uverbs_robust_udata.

https://lore.kernel.org/linux-rdma/[email protected]/

Thanks

Quoted 55 lines

Thanks,
Abhijit

Quoted 51 lines · Abhijit Gangurde

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

   .../infiniband/hw/ionic/ionic_controlpath.c   | 34 ++++++++++
   drivers/infiniband/hw/ionic/ionic_datapath.c  | 43 ++++++-------
   drivers/infiniband/hw/ionic/ionic_fw.h        | 12 +++-
   drivers/infiniband/hw/ionic/ionic_ibdev.h     |  2 +
   drivers/infiniband/hw/ionic/ionic_lif_cfg.c   |  2 +
   drivers/infiniband/hw/ionic/ionic_lif_cfg.h   |  1 +
   .../ethernet/pensando/ionic/ionic_ethtool.c   | 12 ++--
   .../net/ethernet/pensando/ionic/ionic_if.h    |  1 +
   .../net/ethernet/pensando/ionic/ionic_lif.c   |  5 +-
   .../net/ethernet/pensando/ionic/ionic_lif.h   |  3 +-
   .../net/ethernet/pensando/ionic/ionic_phc.c   | 63 ++++++++++++++++---
   include/uapi/rdma/ib_user_verbs.h             | 33 ++++++++++
   include/uapi/rdma/ionic-abi.h                 |  1 +
   include/uapi/rdma/mlx5-abi.h                  | 15 ++---
   14 files changed, 179 insertions(+), 48 deletions(-)
author maintainer
#14 lore raw
Quoted 9 lines · Leon Romanovsky
Quoted 2 lines · Abhijit Gangurde

Thanks Leon. This is already addressed in https://patchwork.kernel.org/project/linux-rdma/patch/[email protected]/
which was sent after this series. Happy to rebase if needed.

You need to rebase this, as we moved ib_respond_empty_udata() from the end of the function to the beginning.

Also, please send this as a separate patch or series.

Thanks.

Hi Leon,

The robust udata patch has been picked up, and this series still applies cleanly on the latest for-next. Are there any remaining concerns?

Thanks,
Abhijit

Quoted 70 lines
Quoted 70 lines · Leon Romanovsky
Quoted 67 lines · Abhijit Gangurde
Quoted 4 lines

Hi Jason, Jakub,

Gentle ping — if there are no further concerns, could this series be merged through the rdma tree?

Jason requested converting any driver that extends udata to use uverbs_robust_udata.

https://lore.kernel.org/linux-rdma/[email protected]/

Thanks

Quoted 55 lines

Thanks,
Abhijit

Quoted 51 lines · Abhijit Gangurde

Hi,

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

With this, user space can read completion timestamps and convert them to wall time with low overhead.

Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724

v4:
- Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
v3:
- Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
- Moved mlx5 to use the common clock info structure
- Addressed review feedback from Sashiko
- https://lore.kernel.org/linux-rdma/[email protected]/
v2:
- changed ionic_phc_state to ib_uverbs_phc_state and moved it under ib_user_verbs.h
- https://lore.kernel.org/linux-rdma/[email protected]/
v1:
- https://lore.kernel.org/all/[email protected]/

Abhijit Gangurde (5):
net: ionic: register PHC for rdma timestamping
net: ionic: Add PHC state page for user space access RDMA/ionic: map PHC state into user space
RDMA/ionic: add completion timestamp to CQE format RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info

.../infiniband/hw/ionic/ionic_controlpath.c | 34 ++++++++++
drivers/infiniband/hw/ionic/ionic_datapath.c | 43 ++++++-------
drivers/infiniband/hw/ionic/ionic_fw.h | 12 +++-
drivers/infiniband/hw/ionic/ionic_ibdev.h | 2 +
drivers/infiniband/hw/ionic/ionic_lif_cfg.c | 2 +
drivers/infiniband/hw/ionic/ionic_lif_cfg.h | 1 +
.../ethernet/pensando/ionic/ionic_ethtool.c | 12 ++--
.../net/ethernet/pensando/ionic/ionic_if.h | 1 +
.../net/ethernet/pensando/ionic/ionic_lif.c | 5 +-
.../net/ethernet/pensando/ionic/ionic_lif.h | 3 +-
.../net/ethernet/pensando/ionic/ionic_phc.c | 63 ++++++++++++++++---
include/uapi/rdma/ib_user_verbs.h | 33 ++++++++++
include/uapi/rdma/ionic-abi.h | 1 +
include/uapi/rdma/mlx5-abi.h | 15 ++---
14 files changed, 179 insertions(+), 48 deletions(-)

#15 lore raw
Quoted 10 lines · Abhijit Gangurde
Quoted 8 lines · Leon Romanovsky
Quoted 2 lines · Abhijit Gangurde

Thanks Leon. This is already addressed in https://patchwork.kernel.org/project/linux-rdma/patch/[email protected]/
which was sent after this series. Happy to rebase if needed.

You need to rebase this, as we moved ib_respond_empty_udata() from the end of the function to the beginning.

Also, please send this as a separate patch or series.

Quoted 7 lines
Quoted 1 line

Thanks.

Hi Leon,

The robust udata patch has been picked up, and this series still applies cleanly on
the latest for-next. Are there any remaining concerns?

Sorry, I didn't notice that it applies cleanly.

Applied to wip/leon-for-next.

Thanks.

#16 lore raw
In reply to Abhijit Gangurde
Quoted 8 lines · Abhijit Gangurde

This series adds RDMA completion timestamp support for ionic.

It enables PHC registration for RDMA timestamp capability, exposes a PHC state page for safe user-space reads, maps that PHC state through RDMA ucontext mmap, and extends the RDMA CQE format to carry completion timestamps.

[...]

Applied, thanks!

[1/5] net: ionic: register PHC for rdma timestamping

      https://git.kernel.org/rdma/rdma/c/8aae47a046439b
[2/5] net: ionic: Add PHC state page for user space access
      https://git.kernel.org/rdma/rdma/c/02e643e22a4403
[3/5] RDMA/ionic: map PHC state into user space
      https://git.kernel.org/rdma/rdma/c/7462d18889bf5d
[4/5] RDMA/ionic: add completion timestamp to CQE format
      https://git.kernel.org/rdma/rdma/c/8ba049504671fe
[5/5] RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info
      https://git.kernel.org/rdma/rdma/c/63d6c2d10c15ba

Best regards,

Signature · 1 line
Leon Romanovsky <[email protected]>