From: Jason Gunthorpe <jgg@nvidia.com>
To: Yonatan Nachum <ynachum@amazon.com>
Cc: leon@kernel.org, linux-rdma@vger.kernel.org, mrgolin@amazon.com,
sleybo@amazon.com, matua@amazon.com, gal.pressman@linux.dev,
danamala@amazon.com, Chen Brasch <cbrasch@amazon.com>
Subject: Re: [PATCH for-next 2/2] RDMA/efa: Pass relaxed ordering flag to device
Date: Tue, 11 Aug 2026 16:46:15 -0300 [thread overview]
Message-ID: <20260811194615.GA661754@nvidia.com> (raw)
In-Reply-To: <20260806075758.3476667-3-ynachum@amazon.com>
On Thu, Aug 06, 2026 at 07:57:58AM +0000, Yonatan Nachum wrote:
> @@ -1647,6 +1650,9 @@ static struct efa_mr *efa_alloc_mr(struct ib_pd *ibpd, int access_flags,
> (EFA_DEV_CAP(dev, RDMA_READ) ? IB_ACCESS_REMOTE_READ : 0) |
> (EFA_DEV_CAP(dev, RDMA_WRITE) ? IB_ACCESS_REMOTE_WRITE : 0);
>
> + if (EFA_DEV_CAP(dev, MR_RELAXED_ORDERING))
> + supp_access_flags |= IB_ACCESS_RELAXED_ORDERING;
> +
> access_flags &= ~IB_ACCESS_OPTIONAL;
Since:
IB_UVERBS_ACCESS_RELAXED_ORDERING = IB_UVERBS_ACCESS_OPTIONAL_FIRST,
This is confusing / dead code
The rest of the series looked Ok, but why are you reporting a new CAP
back to userspace? Did you have a use in mind?
As above existing kernels will accept IB_ACCESS_RELAXED_ORDERING just
fine, and it is really just a performance hint anyhow so it is fine if
old kernels ignore it.
Jason
prev parent reply other threads:[~2026-08-11 19:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 7:57 [PATCH for-next 0/2] RDMA/efa: Add support for MR relaxed ordering Yonatan Nachum
2026-08-06 7:57 ` [PATCH for-next 1/2] RDMA/efa: Use device ABI MR permissions instead of verbs flags Yonatan Nachum
2026-08-06 7:57 ` [PATCH for-next 2/2] RDMA/efa: Pass relaxed ordering flag to device Yonatan Nachum
2026-08-11 19:46 ` Jason Gunthorpe [this message]
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=20260811194615.GA661754@nvidia.com \
--to=jgg@nvidia.com \
--cc=cbrasch@amazon.com \
--cc=danamala@amazon.com \
--cc=gal.pressman@linux.dev \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=matua@amazon.com \
--cc=mrgolin@amazon.com \
--cc=sleybo@amazon.com \
--cc=ynachum@amazon.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox