All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Gal Pressman <galpress@amazon.com>
Cc: Doug Ledford <dledford@redhat.com>, <linux-rdma@vger.kernel.org>,
	Alexander Matushevsky <matua@amazon.com>,
	Shadi Ammouri <sammouri@amazon.com>,
	Yossi Leybovich <sleybo@amazon.com>
Subject: Re: [PATCH for-next v4 3/4] RDMA/efa: User/kernel compatibility handshake mechanism
Date: Tue, 28 Jul 2020 09:28:23 -0300	[thread overview]
Message-ID: <20200728122823.GA16789@nvidia.com> (raw)
In-Reply-To: <1efd7d21-2e4d-46b8-fbdf-47c4bb5553fe@amazon.com>

On Tue, Jul 28, 2020 at 02:50:18PM +0300, Gal Pressman wrote:
> On 27/07/2020 21:56, Jason Gunthorpe wrote:
> > On Wed, Jul 22, 2020 at 05:03:11PM +0300, Gal Pressman wrote:
> >> Introduce a mechanism that performs an handshake between the userspace
> >> provider and kernel driver which verifies that the user supports all
> >> required features in order to operate correctly.
> >>
> >> The handshake verifies the needed functionality by comparing the
> >> reported device caps and the provider caps. If the device reports a
> >> non-zero capability the appropriate comp mask is required from the
> >> userspace provider in order to allocate the context.
> >>
> >> Reviewed-by: Shadi Ammouri <sammouri@amazon.com>
> >> Reviewed-by: Yossi Leybovich <sleybo@amazon.com>
> >> Signed-off-by: Gal Pressman <galpress@amazon.com>
> >>  drivers/infiniband/hw/efa/efa_verbs.c | 40 +++++++++++++++++++++++++++
> >>  include/uapi/rdma/efa-abi.h           | 10 +++++++
> >>  2 files changed, 50 insertions(+)
> >>
> >> diff --git a/drivers/infiniband/hw/efa/efa_verbs.c b/drivers/infiniband/hw/efa/efa_verbs.c
> >> index 26102ab333b2..fda175836fb6 100644
> >> +++ b/drivers/infiniband/hw/efa/efa_verbs.c
> >> @@ -1501,11 +1501,39 @@ static int efa_dealloc_uar(struct efa_dev *dev, u16 uarn)
> >>  	return efa_com_dealloc_uar(&dev->edev, &params);
> >>  }
> >>  
> >> +#define EFA_CHECK_USER_COMP(_dev, _comp_mask, _attr, _mask, _attr_str) \
> >> +	(_attr_str = (!(_dev)->dev_attr._attr || ((_comp_mask) & (_mask))) ? \
> >> +		     NULL : #_attr)
> >> +
> >> +static int efa_user_comp_handshake(const struct ib_ucontext *ibucontext,
> >> +				   const struct efa_ibv_alloc_ucontext_cmd *cmd)
> >> +{
> >> +	struct efa_dev *dev = to_edev(ibucontext->device);
> >> +	char *attr_str;
> >> +
> >> +	if (EFA_CHECK_USER_COMP(dev, cmd->comp_mask, max_tx_batch,
> >> +				EFA_ALLOC_UCONTEXT_CMD_COMP_TX_BATCH, attr_str))
> >> +		goto err;
> >> +
> >> +	if (EFA_CHECK_USER_COMP(dev, cmd->comp_mask, min_sq_depth,
> >> +				EFA_ALLOC_UCONTEXT_CMD_COMP_MIN_SQ_WR,
> >> +				attr_str))
> >> +		goto err;
> > 
> > But this patch should be first, the kernel should never return a
> > non-zero value unless these input bits are set
> 
> But that's exactly what this patch does, it can only fail in case
> max_tx_batch/min_sq_depth is turned on by the device.

My point is the series is out of order, the introduction of the two
uapi parts should be in the same patch

> Anyway, the order doesn't matter as long as the pciid patch is last.

Oh?

Jason

  reply	other threads:[~2020-07-28 12:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 14:03 [PATCH for-next v4 0/4] Add support for 0xefa1 device Gal Pressman
2020-07-22 14:03 ` [PATCH for-next v4 1/4] RDMA/efa: Expose maximum TX doorbell batch Gal Pressman
2020-07-22 14:03 ` [PATCH for-next v4 2/4] RDMA/efa: Expose minimum SQ size Gal Pressman
2020-07-22 14:03 ` [PATCH for-next v4 3/4] RDMA/efa: User/kernel compatibility handshake mechanism Gal Pressman
2020-07-27 18:56   ` Jason Gunthorpe
2020-07-28 11:50     ` Gal Pressman
2020-07-28 12:28       ` Jason Gunthorpe [this message]
2020-07-28 13:07         ` Gal Pressman
2020-07-22 14:03 ` [PATCH for-next v4 4/4] RDMA/efa: Add EFA 0xefa1 PCI ID Gal Pressman
2020-07-29 12:28 ` [PATCH for-next v4 0/4] Add support for 0xefa1 device 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=20200728122823.GA16789@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dledford@redhat.com \
    --cc=galpress@amazon.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matua@amazon.com \
    --cc=sammouri@amazon.com \
    --cc=sleybo@amazon.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.