All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Michal Kalderon <mkalderon@marvell.com>
Cc: "dledford@redhat.com" <dledford@redhat.com>,
	Ariel Elior <aelior@marvell.com>,
	Yuval Basson <ybason@marvell.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH v3 rdma-next 2/2] RDMA/qedr: Add EDPM max size to alloc ucontext response
Date: Thu, 16 Jul 2020 15:57:31 -0300	[thread overview]
Message-ID: <20200716185731.GD2021234@nvidia.com> (raw)
In-Reply-To: <MN2PR18MB31824C9F96D7F0D511D9B261A17F0@MN2PR18MB3182.namprd18.prod.outlook.com>

On Thu, Jul 16, 2020 at 06:17:29PM +0000, Michal Kalderon wrote:
> > From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> > owner@vger.kernel.org> On Behalf Of Jason Gunthorpe
> > 
> > On Tue, Jul 07, 2020 at 09:31:00AM +0300, Michal Kalderon wrote:
> > > User space should receive the maximum edpm size from kernel driver,
> > > similar to other edpm/ldpm related limits.
> > > Add an additional parameter to the alloc_ucontext_resp structure for
> > > the edpm maximum size.
> > >
> > > In addition, pass an indication from user-space to kernel (and not
> > > just kernel to user) that the DPM sizes are supported.
> > >
> > > This is for supporting backward-forward compatibility between driver
> > > and lib for everything related to DPM transaction and limit sizes.
> > >
> > > This should have been part of commit mentioned in Fixes tag.
> > > Fixes: 93a3d05f9d68 ("RDMA/qedr: Add kernel capability flags for dpm
> > > enabled mode")
> > > Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
> > > Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
> > > drivers/infiniband/hw/qedr/verbs.c | 9 ++++++---
> > >  include/uapi/rdma/qedr-abi.h       | 6 +++++-
> > >  2 files changed, 11 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/qedr/verbs.c
> > > b/drivers/infiniband/hw/qedr/verbs.c
> > > index fbb0c66c7f2c..cfe4cd637f1c 100644
> > > +++ b/drivers/infiniband/hw/qedr/verbs.c
> > > @@ -320,9 +320,12 @@ int qedr_alloc_ucontext(struct ib_ucontext *uctx,
> > struct ib_udata *udata)
> > >  				  QEDR_DPM_TYPE_ROCE_LEGACY |
> > >  				  QEDR_DPM_TYPE_ROCE_EDPM_MODE;
> > >
> > > -	uresp.dpm_flags |= QEDR_DPM_SIZES_SET;
> > > -	uresp.ldpm_limit_size = QEDR_LDPM_MAX_SIZE;
> > > -	uresp.edpm_trans_size = QEDR_EDPM_TRANS_SIZE;
> > > +	if (ureq.context_flags & QEDR_SUPPORT_DPM_SIZES) {
> > 
> > Why does this need an input flag just to set some outputs?
> > 
> > The usual truncate on not enough size should take care of it, right?
> At this point it just sets some output, but for future related changes around these sizes
> there will also be fw related configurations, we will need to know whether the lib supports
> accepting different sizes or not. This is for forward compatibility between libqedr and
> driver. 

I would be happier to see this flag introduced when it actually had a
purpose, as I really don't like the pattern of conditionally filling
uresp, but OK. Please delete this if when you make use of it the flag properly.

Jason

  reply	other threads:[~2020-07-16 18:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-07  6:30 [PATCH v3 rdma-next 0/2] RDMA/qedr: Add EDPM kernel-user flags for feature compatibility Michal Kalderon
2020-07-07  6:30 ` [PATCH v3 rdma-next 1/2] RDMA/qedr: Add EDPM mode type for user-fw compatibility Michal Kalderon
2020-07-07  6:31 ` [PATCH v3 rdma-next 2/2] RDMA/qedr: Add EDPM max size to alloc ucontext response Michal Kalderon
2020-07-16 17:10   ` Jason Gunthorpe
2020-07-16 18:17     ` Michal Kalderon
2020-07-16 18:57       ` Jason Gunthorpe [this message]
2020-07-16 19:05         ` [EXT] " Michal Kalderon
2020-07-16 19:07 ` [PATCH v3 rdma-next 0/2] RDMA/qedr: Add EDPM kernel-user flags for feature compatibility Jason Gunthorpe

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=20200716185731.GD2021234@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=aelior@marvell.com \
    --cc=dledford@redhat.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mkalderon@marvell.com \
    --cc=ybason@marvell.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 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.