Re: [PATCH 06/10] SUNRPC/svc: add light-weight queuing mechanism.

[Chuck Lever <chuck.lever@oracle.com>]

On Fri, Aug 18, 2023 at 08:06:16AM +1000, NeilBrown wrote:
> On Fri, 18 Aug 2023, Chuck Lever wrote:
> > On Tue, Aug 15, 2023 at 11:54:22AM +1000, NeilBrown wrote:
> > > lwq is a FIFO single-linked queue that only requires a spinlock
> > > for dequeueing, which happens in process context.  Enqueueing is atomic
> > > with no spinlock and can happen in any context.
> > > 
> > > Include a unit test for basic functionality - runs a boot/module-load
> > > time.  Does not use kunit framework.
> > > 
> > > Signed-off-by: NeilBrown <neilb@suse.de>
> > > ---
> > >  include/linux/sunrpc/svc_lwq.h |  79 +++++++++++++++++++
> > 
> > I'm wondering what your longer-term intentions are for this new
> > mechanism. If it is only useful for SunRPC, then perhaps this
> > header belongs under net/sunrpc instead.
> 
> I try to avoid long-term intentions, they rarely work out :-)
> 
> I did want to put it under net/sunrpc.  But that requires moving
> structure definitions for svc_pool, svc_serv, and svc_xprt into
> net/sunrpc - which I would like to do.
> But there are a few places where svc_xprt (at least) is accessed from
> fs/nfsd/ either directly (xpt_flags, xpt_cred, xpt_local ...) or
> through inlines. (svc_xprt_get(), svc_xpt_set_local() ...).
> 
> We we would need to create APIs to replace the direct accesses, and turn
> the inlines into EXPORT_SYMBOL function.
> 
> So I don't think it is practical.

Fair enough. It doesn't look difficult to fix those issues (which
are effectively layering violations) but perhaps that's for another
day.

Meanwhile, do these new files need names that begin with "svc_" ?
I don't see anything server-specific about them. I'd prefer just
"lwq.[ch]".


-- 
Chuck Lever