From: Jason Gunthorpe <jgg@ziepe.ca>
To: Parav Pandit <parav@mellanox.com>
Cc: Leon Romanovsky <leon@kernel.org>,
Doug Ledford <dledford@redhat.com>,
Leon Romanovsky <leonro@mellanox.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Daniel Jurgens <danielj@mellanox.com>
Subject: Re: [PATCH rdma-next v1 1/2] IB/core: Let IB core distribute cache update events
Date: Tue, 29 Oct 2019 12:54:54 -0300 [thread overview]
Message-ID: <20191029155454.GF6128@ziepe.ca> (raw)
In-Reply-To: <AM0PR05MB48668ED6420D4DC6385ADE13D1610@AM0PR05MB4866.eurprd05.prod.outlook.com>
On Tue, Oct 29, 2019 at 03:47:42PM +0000, Parav Pandit wrote:
>
>
> > From: Jason Gunthorpe <jgg@mellanox.com>
> > Sent: Tuesday, October 29, 2019 10:34 AM
> > To: Parav Pandit <parav@mellanox.com>
> > Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
> > <dledford@redhat.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
> > mailing list <linux-rdma@vger.kernel.org>; Daniel Jurgens
> > <danielj@mellanox.com>
> > Subject: Re: [PATCH rdma-next v1 1/2] IB/core: Let IB core distribute cache
> > update events
> >
> > On Tue, Oct 29, 2019 at 03:32:46PM +0000, Parav Pandit wrote:
> >
> > > > > +/**
> > > > > + * ib_dispatch_event - Dispatch an asynchronous event
> > > > > + * @event:Event to dispatch
> > > > > + *
> > > > > + * Low-level drivers must call ib_dispatch_event() to dispatch the
> > > > > + * event to all registered event handlers when an asynchronous event
> > > > > + * occurs.
> > > > > + */
> > > > > +void ib_dispatch_event(struct ib_event *event) {
> > > > > + ib_enqueue_cache_update_event(event);
> > > > > +}
> > > > > EXPORT_SYMBOL(ib_dispatch_event);
> > > >
> > > > Why not just move this into cache.c?
> > > >
> > > Same thought same to me when I had to add one liner call.
> > > However the issue was device.c has the code for the event
> > registration/unregistration and calling the handlers unrelated to cache.
> > > So moving ib_dispatch_event() to cache.c looked incorrect to me.
> >
> > Well, maybe we can move the wq code from the cache.c into here?
>
> I prefer to keep all cache specific code in cache.c because there is
> where we flush the ib_wq, queue work there.
I think that is because the cache is not subscribing to a notifier, it
really should, then things order properly and the flush is not needed.
> > It looks just as incorrect to have the one line call
>
> No, its not incorrect. Because device.c provides functionality to
> register/unregister handler and dispatch event. While cache layer
> deals with cache updates etc, and uses wq service provided device.c
> If we rename ib_dispatch_event() to ib_dispatch_cache_event() it
> make sense to move to cache.c However we have non cache specific
> events there too, so current code split between cache.c and device.c
> looks appropriate.
It always looks bad to have a single line function call like that,
especially just for spurious reasons like file placement or
functioning naming. It shows something is being done wrong
Jason
next prev parent reply other threads:[~2019-10-29 15:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 11:53 [PATCH rdma-next v1 0/2] Let IB core distribute cache update events Leon Romanovsky
2019-10-29 11:53 ` [PATCH rdma-next v1 1/2] IB/core: " Leon Romanovsky
2019-10-29 13:31 ` Parav Pandit
2019-10-29 15:24 ` Jason Gunthorpe
2019-10-29 15:32 ` Parav Pandit
2019-10-29 15:33 ` Jason Gunthorpe
2019-10-29 15:47 ` Parav Pandit
2019-10-29 15:54 ` Jason Gunthorpe [this message]
2019-10-29 18:11 ` Parav Pandit
2019-10-29 18:26 ` Jason Gunthorpe
2019-10-29 19:28 ` Parav Pandit
2019-10-29 11:53 ` [PATCH rdma-next v1 2/2] IB/core: Cut down single member ib_cache structure 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=20191029155454.GF6128@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=danielj@mellanox.com \
--cc=dledford@redhat.com \
--cc=leon@kernel.org \
--cc=leonro@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=parav@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox