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