ionic: RDMA completion timestamping support
Subsystems (6)
Abhijit Gangurde
maintainerv4 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
Abhijit Gangurde
maintainerPATCH 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
@@ -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
@@ -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
@@ -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
@@ -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
[email protected]
AI reviewRe: [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@@ -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
-4info->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
Abhijit Gangurde
maintainerPATCH v4 2/5 net: ionic: Add PHC state page for user space access
In reply to Abhijit GangurdeAdd 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
@@ -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
@@ -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
[email protected]
AI reviewRe: [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.
Co-developed-by Allen Hubbe <[email protected]>Signed-off-by Allen Hubbe <[email protected]>Signed-off-by Abhijit Gangurde <[email protected]>
Sashiko has reviewed this patch and found no issues.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Abhijit Gangurde
maintainerPATCH v4 3/5 RDMA/ionic: map PHC state into user space
In reply to Abhijit GangurdeEnable 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
[email protected]
AI reviewRe: [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@@ -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
Abhijit Gangurde
maintainerPATCH v4 4/5 RDMA/ionic: add completion timestamp to CQE format
In reply to Abhijit GangurdeUpdate 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
@@ -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
@@ -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
[email protected]
AI reviewRe: [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.
Co-developed-by Allen Hubbe <[email protected]>Signed-off-by Allen Hubbe <[email protected]>Signed-off-by Abhijit Gangurde <[email protected]>
Sashiko has reviewed this patch and found no issues.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
Abhijit Gangurde
maintainerPATCH v4 5/5 RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info
In reply to Abhijit GangurdeUse 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
@@ -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_infoenum mlx5_ib_mmap_cmd {MLX5_IB_MMAP_REGULAR_PAGE =0 ,
Signature · 1 line
2.43.0
Abhijit Gangurde
maintainerHi 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 ofmlx5_ib_clock_infotoib_uverbs_clock_info
v3:
- Renamedib_uverbs_phc_statetoib_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:
- changedionic_phc_statetoib_uverbs_phc_stateand moved it underib_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 structib_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(-)
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,
AbhijitQuoted 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 ofmlx5_ib_clock_infotoib_uverbs_clock_info
v3:
- Renamedib_uverbs_phc_statetoib_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:
- changedionic_phc_statetoib_uverbs_phc_stateand moved it underib_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 structib_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(-)
Abhijit Gangurde
maintainerThanks 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,
AbhijitQuoted 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 ofmlx5_ib_clock_infotoib_uverbs_clock_info
v3:
- Renamedib_uverbs_phc_statetoib_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:
- changedionic_phc_statetoib_uverbs_phc_stateand moved it underib_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 structib_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(-)
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,
AbhijitQuoted 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 ofmlx5_ib_clock_infotoib_uverbs_clock_info
v3:
- Renamedib_uverbs_phc_statetoib_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:
- changedionic_phc_statetoib_uverbs_phc_stateand moved it underib_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 structib_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(-)
Abhijit Gangurde
maintainerQuoted 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,
AbhijitQuoted 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 ofmlx5_ib_clock_infotoib_uverbs_clock_info
v3:
- Renamedib_uverbs_phc_statetoib_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:
- changedionic_phc_statetoib_uverbs_phc_stateand moved it underib_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 structib_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(-)
Leon Romanovsky
AppliedQuoted 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.
Leon Romanovsky
AppliedQuoted 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]>