From: "yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>
To: Tom Talpey <tom@talpey.com>,
"Gromadzki, Tomasz" <tomasz.gromadzki@intel.com>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"yanjun.zhu@linux.dev" <yanjun.zhu@linux.dev>,
"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.com>,
"jgg@nvidia.com" <jgg@nvidia.com>,
"y-goto@fujitsu.com" <y-goto@fujitsu.com>,
"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>
Subject: Re: [RFC PATCH 0/2] RDMA/rxe: Add RDMA Atomic Write operation
Date: Tue, 4 Jan 2022 09:28:05 +0000 [thread overview]
Message-ID: <61D4131D.5070700@fujitsu.com> (raw)
In-Reply-To: <61CEA398.7090703@fujitsu.com>
On 2021/12/31 14:30, yangx.jy@fujitsu.com wrote:
> On 2021/12/31 5:42, Tom Talpey wrote:
>> On 12/30/2021 2:21 PM, Gromadzki, Tomasz wrote:
>>> 1)
>>>> rdma_post_atomic_writev(struct rdma_cm_id *id, void *context, struct
>>>> ibv_sge *sgl,
>>>> int nsge, int flags, uint64_t remote_addr, uint32_t rkey)
>>> Do we need this API at all?
>>> Other atomic operations (compare_swap/add) do not use struct ibv_sge
>>> at all but have a dedicated place in
>>> struct ib_send_wr {
>>> ...
>>> struct {
>>> uint64_t remote_addr;
>>> uint64_t compare_add;
>>> uint64_t swap;
>>> uint32_t rkey;
>>> } atomic;
>>> ...
>>> }
>>>
>>> Would it be better to reuse (extend) any existing field?
>>> i.e.
>>> struct {
>>> uint64_t remote_addr;
>>> uint64_t compare_add;
>>> uint64_t swap_write;
>>> uint32_t rkey;
>>> } atomic;
>> Agreed. Passing the data to be written as an SGE is unnatural
>> since it is always exactly 64 bits. Tweaking the existing atomic
>> parameter block as Tomasz suggests is the best approach.
> Hi Tomasz, Tom
>
> Thanks for your quick reply.
>
> If we want to pass the 8-byte value by tweaking struct atomic on user
> space, why don't we
> tranfer the 8-byte value by ATOMIC Extended Transport Header (AtomicETH)
> on kernel space?
> PS: IBTA defines that the 8-byte value is tranfered by RDMA Extended
> Transport Heade(RETH) + payload.
>
> Is it inconsistent to use struct atomic on user space and RETH + payload
> on kernel space?
Hi Tomasz, Tom
I think the following rules are right:
RDMA READ/WRITE should use struct rdma in libverbs and RETH + payload in
kernel.
RDMA Atomic should use struct atomic in libverbs and AtomicETH in kernel.
According to IBTA's definition, RDMA Atomic Write should use struct rdma
in libibverbs.
How about adding a member in struct rdma? for example:
struct {
uint64_t remote_addr;
uint32_t rkey;
uint64_t wr_value:
} rdma;
Best Regards,
Xiao Yang
> Best Regards,
> Xiao Yang
>> Tom.
next prev parent reply other threads:[~2022-01-04 9:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 12:14 [RFC PATCH 0/2] RDMA/rxe: Add RDMA Atomic Write operation Xiao Yang
2021-12-30 12:14 ` [RFC PATCH 1/2] RDMA/rxe: Rename send_atomic_ack() and atomic member of struct resp_res Xiao Yang
2021-12-30 12:14 ` [RFC PATCH 2/2] RDMA/rxe: Add RDMA Atomic Write operation Xiao Yang
2021-12-30 21:39 ` Tom Talpey
2021-12-31 8:29 ` yangx.jy
2021-12-31 15:09 ` Tom Talpey
[not found] ` <61D563B4.2070106@fujitsu.com>
2022-01-07 15:50 ` Tom Talpey
2022-01-07 17:11 ` Jason Gunthorpe
2022-01-12 9:24 ` yangx.jy
2022-01-05 23:53 ` Jason Gunthorpe
2022-01-06 10:52 ` yangx.jy
2022-01-06 13:00 ` Jason Gunthorpe
2022-01-07 2:15 ` yangx.jy
2022-01-07 12:22 ` Jason Gunthorpe
2022-01-07 15:38 ` Tom Talpey
2022-01-07 19:28 ` Jason Gunthorpe
2022-01-07 20:11 ` Tom Talpey
2021-12-31 3:01 ` lizhijian
2021-12-31 6:02 ` yangx.jy
2021-12-30 19:21 ` [RFC PATCH 0/2] " Gromadzki, Tomasz
2021-12-30 21:42 ` Tom Talpey
2021-12-31 6:30 ` yangx.jy
2022-01-04 9:28 ` yangx.jy [this message]
2022-01-04 15:17 ` Tom Talpey
2022-01-05 1:00 ` yangx.jy
2022-01-06 0:01 ` Jason Gunthorpe
2022-01-06 1:54 ` yangx.jy
2022-01-10 15:42 ` Jason Gunthorpe
2022-01-11 2:34 ` yangx.jy
2022-01-11 23:29 ` Jason Gunthorpe
2022-02-11 13:18 ` Gromadzki, Tomasz
2022-02-17 3:50 ` yangx.jy
2022-02-19 10:37 ` Leon Romanovsky
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=61D4131D.5070700@fujitsu.com \
--to=yangx.jy@fujitsu.com \
--cc=jgg@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--cc=tom@talpey.com \
--cc=tomasz.gromadzki@intel.com \
--cc=y-goto@fujitsu.com \
--cc=yanjun.zhu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).