linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).