All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>
Cc: Tom Talpey <tom@talpey.com>,
	"Gromadzki, Tomasz" <tomasz.gromadzki@intel.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"yanjun.zhu@linux.dev" <yanjun.zhu@linux.dev>,
	"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.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: Mon, 10 Jan 2022 11:42:05 -0400	[thread overview]
Message-ID: <20220110154205.GD2328285@nvidia.com> (raw)
In-Reply-To: <61D64BD5.9020401@fujitsu.com>

On Thu, Jan 06, 2022 at 01:54:30AM +0000, yangx.jy@fujitsu.com wrote:
> On 2022/1/6 8:01, Jason Gunthorpe wrote:
> > On Wed, Jan 05, 2022 at 01:00:42AM +0000, yangx.jy@fujitsu.com wrote:
> >
> >> 1) In kernel, current SoftRoCE copies the content of struct rdma to RETH
> >> and copies the content of struct atomic to AtomicETH.
> >> 2) IBTA defines that RDMA Atomic Write uses RETH + payload.
> >> According to these two reasons, I perfer to tweak the existing struct rdma.
> > No this is basically meaningless
> >
> > The wr struct is designed as a 'tagged union' where the op specified
> > which union is in effect.
> >
> > It turns out that the op generally specifies the network headers as
> > well, but that is just a side effect.
> >
> >>>> How about adding a member in struct rdma? for example:
> >>>> struct {
> >>>>        uint64_t    remote_addr;
> >>>>        uint32_t    rkey;
> >>>>        uint64_t    wr_value:
> >>>> } rdma;
> >>> Yes, that's what Tomasz and I were suggesting - a new template for the
> >>> ATOMIC_WRITE request payload. The three fields are to be supplied by
> >>> the verb consumer when posting the work request.
> >> OK, I will update the patch in this way.
> > We are not extending the ib_send_wr anymore anyhow.
> >
> > You should implement new ops inside struct ibv_qp_ex as function
> > calls.
> 
> Hi Jason,
> 
> For SoftRoCE, do you mean that I only need to extend struct rxe_send_wr 
> and add  ibv_wr_rdma_atomic_write() ?
> struct rxe_send_wr {
>      ...
>          struct {
>              __aligned_u64 remote_addr;
> +           __aligned_u64 atomic_wr;
>              __u32   rkey;
>              __u32   reserved;
>          } rdma;

You can't make a change like this to anything in
include/uapi/rdma/rdma_user_rxe.h, it has to remain compatiable.

 
> static inline void ibv_wr_rdma_atomic_write(struct ibv_qp_ex *qp, 
> uint32_t rkey,
>                                       uint64_t remote_addr)
> {
>          qp->wr_rdma_atomic_write(qp, rkey, remote_addr);
> }

Yes, something like that
 
> Besides, could you tell me why we cannot extend struct ibv_send_wr for 
> ibv_post_send()?

The ABI is not allowed to change so what is doable with it is very
limited.

Jason

  reply	other threads:[~2022-01-10 15:42 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
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 [this message]
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=20220110154205.GD2328285@nvidia.com \
    --to=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=yangx.jy@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 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.