From: sashiko-bot@kernel.org
To: "Eric Davis" <eric.davis@broadcom.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next 06/13] RDMA/core: query the semantics a queue pair type guarantees
Date: Wed, 14 Oct 2026 22:34:01 +0000 [thread overview]
Message-ID: <sashiko-outbox-171975@kernel.org> (raw)
In-Reply-To: <20261014-uet-ib-core-v1-6-a0e626117113@broadcom.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rdma: query_qp_semantics lacks MR attachment capability flag
--
commit 5f36c96aa3fcf03ebbebf03d834b66a1b7642e0a
Author: Eric Davis <eric.davis@broadcom.com>
RDMA/core: query the semantics a queue pair type guarantees
This commit adds a device method to report the guarantees of a queue pair
type, such as operations ordering, largest packet size, and immediate data
width.
> An unconnected transport orders far less than a connected one, and how
> much varies by device. Add a device method that reports, for a queue pair
> type, which operations it orders against which, the largest packet it
> puts on the wire, how wide an immediate it carries, and whether a memory
> region may be attached to a QP so it's only reachable over that QP.
[Severity: Medium]
The commit message states that query_qp_semantics reports "whether a memory
region may be attached to a QP so it's only reachable over that QP".
Is this description accurate for this patch? I notice that a later commit
reports this capability via query_device instead. Could the commit message
be updated to reflect that the MR attachment capability is not included
in query_qp_semantics?
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 68f7a271cf7a7..003b704244293 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
[ ... ]
> @@ -2496,6 +2496,18 @@ struct ib_counters {
> atomic_t usecnt;
> };
>
> +/* what a queue pair of a given type guarantees (query_qp_semantics) */
> +struct ib_qp_semantics {
> + u32 comp_mask; /* enum ib_uverbs_qp_semantics_mask */
> + u32 msg_order; /* enum ib_uverbs_qp_msg_order */
> + u32 max_rdma_raw_size;
> + u32 max_rdma_war_size;
> + u32 max_rdma_waw_size;
> + u32 max_pdu;
> + u32 usage_flags; /* enum ib_uverbs_qp_usage_flags */
> + u8 imm_data_size; /* bits */
> +};
[Severity: Medium]
Does struct ib_qp_semantics omit the MR attachment capability claimed by the
commit message? There doesn't appear to be a field or flag here for it.
> diff --git a/include/uapi/rdma/ib_user_ioctl_verbs.h b/include/uapi/rdma/ib_user_ioctl_verbs.h
> index 210f3f945bd73..3d05a6c7ca8f6 100644
> --- a/include/uapi/rdma/ib_user_ioctl_verbs.h
> +++ b/include/uapi/rdma/ib_user_ioctl_verbs.h
[ ... ]
> +enum ib_uverbs_qp_usage_flags {
> + /* immediate data consumes a posted receive */
> + IB_UVERBS_QP_USAGE_IMM_DATA_RQ = 1 << 0,
> +};
[Severity: Medium]
The usage flags enum only contains IB_UVERBS_QP_USAGE_IMM_DATA_RQ. Should
there be a flag here indicating whether an MR can be attached, or is this
omission expected since it's later reported via query_device?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014-uet-ib-core-v1-0-a0e626117113@broadcom.com?part=6
next prev parent reply other threads:[~2026-10-14 22:34 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 22:21 [PATCH rdma-next 00/13] RDMA/core: Ultra Ethernet transport verbs Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:21 ` [PATCH rdma-next 01/13] RDMA/core: widen the uverbs object key Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:29 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 02/13] RDMA/core: add the UET GID types Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:35 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 03/13] RDMA/core: report the reliable unconnected device capabilities Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:30 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 04/13] RDMA/core: add the reliable unconnected queue pair type Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:43 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 05/13] RDMA/core: extended address handle attributes Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:50 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 06/13] RDMA/core: query the semantics a queue pair type guarantees Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:34 ` sashiko-bot [this message]
2026-10-14 22:21 ` [PATCH rdma-next 07/13] RDMA/core: job and job key objects Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:36 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 08/13] RDMA/uverbs: factor out the queue pair attribute copy Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:30 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 09/13] RDMA/core: create a queue pair ready to send Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:39 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 10/13] RDMA/core: queue pair attributes for unconnected transports Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:41 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 11/13] RDMA/core: extended memory registration Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:36 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 12/13] RDMA/core: 64-bit memory keys Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:32 ` sashiko-bot
2026-10-14 22:21 ` [PATCH rdma-next 13/13] RDMA/core: attach a memory region to a queue pair Eric Davis via B4 Relay
2026-10-14 22:21 ` Eric Davis
2026-10-14 22:37 ` sashiko-bot
2026-10-14 23:57 ` [PATCH rdma-next 00/13] RDMA/core: Ultra Ethernet transport verbs Doug Ledford
2026-10-15 0:08 ` Jason Gunthorpe
2026-10-15 1:02 ` Doug Ledford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-171975@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eric.davis@broadcom.com \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.