All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kamal Heib <kamalheib1@gmail.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	Doug Ledford <dledford@redhat.com>,
	Maor Gottlieb <maorg@mellanox.com>,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next 04/14] RDMA/core: Allow to override device op
Date: Tue, 26 May 2020 11:07:51 +0300	[thread overview]
Message-ID: <20200526080751.GA182953@kheib-workstation> (raw)
In-Reply-To: <20200526055342.GP10591@unreal>

On Tue, May 26, 2020 at 08:53:42AM +0300, Leon Romanovsky wrote:
> On Tue, May 26, 2020 at 02:21:25AM +0300, Kamal Heib wrote:
> > On Mon, May 25, 2020 at 11:26:41AM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 13, 2020 at 12:50:24PM +0300, Leon Romanovsky wrote:
> > > > From: Maor Gottlieb <maorg@mellanox.com>
> > > >
> > > > Current device ops implementation allows only two stages "set"/"not set"
> > > > and requires caller to check if function pointer exists before
> > > > calling it.
> > > >
> > > > In order to simplify this repetitive task, let's give an option to
> > > > overwrite those pointers. This will allow us to set dummy functions
> > > > for the specific function pointers.
> > > >
> > > > Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > > ---
> > > >  drivers/infiniband/core/device.c | 9 ++++-----
> > > >  1 file changed, 4 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
> > > > index d9f565a779df..9486e60b42cc 100644
> > > > --- a/drivers/infiniband/core/device.c
> > > > +++ b/drivers/infiniband/core/device.c
> > > > @@ -2542,11 +2542,10 @@ EXPORT_SYMBOL(ib_get_net_dev_by_params);
> > > >  void ib_set_device_ops(struct ib_device *dev, const struct ib_device_ops *ops)
> > > >  {
> > > >  	struct ib_device_ops *dev_ops = &dev->ops;
> > > > -#define SET_DEVICE_OP(ptr, name)                                               \
> > > > -	do {                                                                   \
> > > > -		if (ops->name)                                                 \
> > > > -			if (!((ptr)->name))				       \
> > > > -				(ptr)->name = ops->name;                       \
> > > > +#define SET_DEVICE_OP(ptr, name)					\
> > > > +	do {								\
> > > > +		if (ops->name)						\
> > > > +			(ptr)->name = ops->name;			\
> > > >  	} while (0)
> > >
> > > Did you carefully check every driver to be sure it is OK with this?
> > >
> > > Maybe Kamal remembers why it was like this?
> > >
> > > Jason
> >
> > The idea was to set a specific op only once by the provider when there
> > is a valid function for the op, this was done to make sure that if
> > the op isn't supported by the provider then it will be set to NULL.
> 
> This is not changed.
>

Well, This is changed in patch #6 as dummy functions are now allowed...,
Instead of setting NULL when the op isn't supported by the provider.

I'm wondering why allow only fill_res_entry() and fill_stat_entry() to
be a dummy function as there is multiple ops that can be dummy too,
and why this has to be in this patch set instead in a seperiate patch
set for all the ops that can be dummy? 

Thanks,
Kamal

> >
> > I think it will be more cleaner from the provider point of view to
> > see which ops are supported or not supported in the provider code. by
> > overriding the ops in the core this will make things more confusing.
> 
> Actually the patch does quite opposite, set defaults by IB/core and
> overwrite it by the provider later and not vice versa. The IB/core
> won't overwrite defined by the provider ops. From provider point of view
> no change.
> 
> Thanks
> 
> >
> > Thanks,
> > Kamal

  reply	other threads:[~2020-05-26  8:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13  9:50 [PATCH rdma-next 00/14] RAW format dumps through RDMAtool Leon Romanovsky
2020-05-13  9:50 ` [PATCH mlx5-next 01/14] net/mlx5: Export resource dump interface Leon Romanovsky
2020-05-25 14:24   ` Jason Gunthorpe
2020-05-25 15:25     ` Maor Gottlieb
2020-05-13  9:50 ` [PATCH mlx5-next 02/14] net/mlx5: Add support in query QP, CQ and MKEY segments Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 03/14] RDMA/core: Fix double put of resource Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 04/14] RDMA/core: Allow to override device op Leon Romanovsky
2020-05-25 14:26   ` Jason Gunthorpe
2020-05-25 16:28     ` Leon Romanovsky
2020-05-25 23:21     ` Kamal Heib
2020-05-26  5:53       ` Leon Romanovsky
2020-05-26  8:07         ` Kamal Heib [this message]
2020-05-26  9:44           ` Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 05/14] RDMA/core: Don't call fill_res_entry for PD Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 06/14] RDMA/core: Add restrack dummy ops Leon Romanovsky
2020-05-25 14:36   ` Jason Gunthorpe
2020-05-25 16:23     ` Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 07/14] RDMA: Add dedicated MR resource tracker function Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 08/14] RDMA: Add a dedicated CQ " Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 09/14] RDMA: Add a dedicated QP " Leon Romanovsky
2020-05-25 14:34   ` Jason Gunthorpe
2020-05-25 16:26     ` Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 10/14] RDMA: Add dedicated cm id " Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 11/14] RDMA: Add support to dump resource tracker in RAW format Leon Romanovsky
2020-05-25 14:41   ` Jason Gunthorpe
2020-05-25 16:21     ` Leon Romanovsky
2020-05-27  6:14       ` Maor Gottlieb
2020-05-13  9:50 ` [PATCH rdma-next 12/14] RDMA/mlx5: Add support to get QP resource in raw format Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 13/14] RDMA/mlx5: Add support to get CQ resource in RAW format Leon Romanovsky
2020-05-13  9:50 ` [PATCH rdma-next 14/14] RDMA/mlx5: Add support to get MR " Leon Romanovsky
2020-05-25 14:50   ` Jason Gunthorpe
2020-05-13 10:15 ` [PATCH rdma-next 00/14] RAW format dumps through RDMAtool 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=20200526080751.GA182953@kheib-workstation \
    --to=kamalheib1@gmail.com \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=maorg@mellanox.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.