linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Bernard Metzler <BMT@zurich.ibm.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	linux-rdma@vger.kernel.org, bharat@chelsio.com,
	nirranjan@chelsio.com, krishna2@chelsio.com, bvanassche@acm.org
Subject: Re: Re: Re: Re: [[PATCH v2 for-next]] RDMA/siw: Fix SQ/RQ drain logic
Date: Tue, 29 Oct 2019 06:54:47 +0200	[thread overview]
Message-ID: <20191029045447.GA5545@unreal> (raw)
In-Reply-To: <OF7628E460.D6869428-ON002584A1.003AE367-002584A1.00455D5D@notes.na.collabserv.com>

On Mon, Oct 28, 2019 at 12:37:38PM +0000, Bernard Metzler wrote:
> -----"Leon Romanovsky" <leon@kernel.org> wrote: -----
>
> >To: "Bernard Metzler" <BMT@zurich.ibm.com>
> >From: "Leon Romanovsky" <leon@kernel.org>
> >Date: 10/27/2019 06:21AM
> >Cc: "Jason Gunthorpe" <jgg@ziepe.ca>, linux-rdma@vger.kernel.org,
> >bharat@chelsio.com, nirranjan@chelsio.com, krishna2@chelsio.com,
> >bvanassche@acm.org
> >Subject: [EXTERNAL] Re: Re: Re: [[PATCH v2 for-next]] RDMA/siw: Fix
> >SQ/RQ drain logic
> >
> >On Fri, Oct 25, 2019 at 12:11:16PM +0000, Bernard Metzler wrote:
> >> -----"Jason Gunthorpe" <jgg@ziepe.ca> wrote: -----
> >>
> >> >To: "Bernard Metzler" <BMT@zurich.ibm.com>
> >> >From: "Jason Gunthorpe" <jgg@ziepe.ca>
> >> >Date: 10/04/2019 07:48PM
> >> >Cc: "Leon Romanovsky" <leon@kernel.org>,
> >linux-rdma@vger.kernel.org,
> >> >bharat@chelsio.com, nirranjan@chelsio.com, krishna2@chelsio.com,
> >> >bvanassche@acm.org
> >> >Subject: [EXTERNAL] Re: Re: [[PATCH v2 for-next]] RDMA/siw: Fix
> >SQ/RQ
> >> >drain logic
> >> >
> >> >On Fri, Oct 04, 2019 at 02:09:57PM +0000, Bernard Metzler wrote:
> >> >> <...>
> >> >>
> >> >> >>   *
> >> >> >> @@ -705,6 +746,12 @@ int siw_post_send(struct ib_qp *base_qp,
> >> >const
> >> >> >struct ib_send_wr *wr,
> >> >> >>  	unsigned long flags;
> >> >> >>  	int rv = 0;
> >> >> >>
> >> >> >> +	if (wr && !qp->kernel_verbs) {
> >> >> >
> >> >> >It is not related to this specific patch, but all siw
> >> >"kernel_verbs"
> >> >> >should go, we have standard way to distinguish between kernel
> >and
> >> >> >user
> >> >> >verbs.
> >> >> >
> >> >> >Thanks
> >> >> >
> >> >> Understood. I think we touched on that already.
> >> >> rdma core objects have a uobject pointer which
> >> >> is valid only if it belongs to a user land
> >> >> application. We might better use that.
> >> >
> >> >No, the uobject pointer is not to be touched by drivers
> >> >
> >> Now what would be the appropriate way of remembering/
> >> detecting user level nature of endpoint resources?
> >> I see drivers _are_ doing 'if (!ibqp->uobject)' ...
> >
> >IMHO, you should rely in "udata" to distinguish user/kernel objects.
> >
>
> right, we already do that at resource creation time, when
> 'udata' is available.  But there is no such parameter
> around during resource access (post_send/post_recv/poll_cq/...),
> when user land or kernel land application specific
> code might be required.
> That's why siw currently saves that info to a resource
> (QP/CQ/SRQ) specific parameter 'kernel_verbs'. I agree
> this parameter is redundant, if the rdma core object
> provides that information as well. The only way I see
> it provided is the validity of the uobject pointer of
> all those resources.
> Either (1) we use that uobject pointer as an indication
> of application location, or (2) we remember it from
> resource creation time when udata was available, or
> (3) we have the rdma core exporting that information
> explicitly.
> siw, and other drivers, are currently implementing (2).
> Some drivers implement (1). I'd be happy to change siw
> to implement (1) - to get rid of 'kernel_verbs'.

Many if not all "kernel_verbs" variables are copy/paste.
The usual way to handle difference in internal flows is to
rely on having pointer initialized, e.g.
if (siw_device->some_specific_kernel_pointer)
 do_kernelwork(siw_device->some_specific_kernel_pointer->extra)

Thanks

>
> Thanks and best regards,
> Bernard.
>
>
>
>
> >>
> >> Other drivers keep it with the private state, like iw40,
> >> but I learned we shall get rid of it.
> >>
> >> We may export an inline query from RDMA core, or simply
> >> #define is_usermode(ib_obj *) (ib_obj->uobject != NULL)
> >> ?
> >>
> >> Thanks and best regards,
> >> Bernard
> >>
> >
> >
>

  parent reply	other threads:[~2019-10-29  4:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02 14:38 [[PATCH v2 for-next]] RDMA/siw: Fix SQ/RQ drain logic Bernard Metzler
2019-10-02 15:47 ` Leon Romanovsky
2019-10-04 14:09   ` Bernard Metzler
2019-10-04 17:48     ` Jason Gunthorpe
2019-10-25 12:11       ` Bernard Metzler
2019-10-27  5:21         ` Leon Romanovsky
2019-10-28 12:37           ` Bernard Metzler
2019-10-28 13:43             ` Jason Gunthorpe
2019-10-29  4:54             ` Leon Romanovsky [this message]
2019-10-31 13:38               ` Bernard Metzler
2019-10-05  8:26     ` Leon Romanovsky
2019-10-18 13:50       ` Bernard Metzler
2019-10-22  5:49         ` 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=20191029045447.GA5545@unreal \
    --to=leon@kernel.org \
    --cc=BMT@zurich.ibm.com \
    --cc=bharat@chelsio.com \
    --cc=bvanassche@acm.org \
    --cc=jgg@ziepe.ca \
    --cc=krishna2@chelsio.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=nirranjan@chelsio.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;
as well as URLs for NNTP newsgroup(s).