All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Adamson <andros@netapp.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org,
	Andy Adamson <andros-HgOvQuBEEgQAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 1/3] SUNRPC add deferral processing callbacks
Date: Fri, 17 Oct 2008 14:42:19 -0400	[thread overview]
Message-ID: <1224268939.3883.29.camel@localhost.localdomain> (raw)
In-Reply-To: <20081017174803.GC11884@fieldses.org>


On Fri, 2008-10-17 at 13:48 -0400, J. Bruce Fields wrote:
> On Wed, Oct 15, 2008 at 05:00:24PM -0400, andros@netapp.com wrote:
> > From: Andy Adamson <andros@netapp.com>
> > 
> > For EOS, NFSD compound RPC deferred processing should restart operation which
> > caused the deferral.
> > 
> > Add a callback and a defer_data pointer in svc_rqst to enable svc_defer to
> > save partial result state in the deferral request.
> > 
> > Add page pointer storage to svc_deferred_req to cache the pages holding the
> > partially processed request.
> > 
> > Add callbacks and a defer_data pointer in svc_deferred_request to enable
> > svc_deferred_recv to restore and release the partial result state.
> > 
> > Signed-off-by: Andy Adamson<andros-HgOvQuBEEgQAvxtiuMwx3w@public.gmane.org>
> 
> Could you fix the missing space there?

Oops..:)
> 
> > ---
> >  include/linux/sunrpc/svc.h |   10 ++++++++++
> >  net/sunrpc/svc_xprt.c      |   20 +++++++++++++++-----
> >  2 files changed, 25 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> > index dc69068..46a4097 100644
> > --- a/include/linux/sunrpc/svc.h
> > +++ b/include/linux/sunrpc/svc.h
> > @@ -215,6 +215,9 @@ struct svc_rqst {
> >  	struct svc_cred		rq_cred;	/* auth info */
> >  	void *			rq_xprt_ctxt;	/* transport specific context ptr */
> >  	struct svc_deferred_req*rq_deferred;	/* deferred request we are replaying */
> > +	/* callback to save deferred request state */
> > +	void (*rq_save_state)(struct svc_rqst *, struct svc_deferred_req *);
> > +	void			*rq_defer_data; /* defer state data to save */
> >  
> >  	size_t			rq_xprt_hlen;	/* xprt header len */
> >  	struct xdr_buf		rq_arg;
> > @@ -323,6 +326,13 @@ struct svc_deferred_req {
> >  	union svc_addr_u	daddr;	/* where reply must come from */
> >  	struct cache_deferred_req handle;
> >  	size_t			xprt_hlen;
> > +	/* callbacks to restore and release deferred request state
> > +	 * set in rq_save_state */
> > +	void (*restore_state)(struct svc_rqst *, struct svc_deferred_req *);
> > +	void (*release_state)(struct svc_deferred_req *);
> > +	void			*defer_data; /* defer state data */
> > +	struct page		*respages[RPCSVC_MAXPAGES];
> > +	short			resused;
> >  	int			argslen;
> >  	__be32			args[0];
> >  };
> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index e46c825..531b325 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -876,6 +876,8 @@ static void svc_revisit(struct cache_deferred_req *dreq, int too_many)
> >  	struct svc_xprt *xprt = dr->xprt;
> >  
> >  	if (too_many) {
> > +		if (dr->release_state)
> > +			dr->release_state(dr);
> >  		svc_xprt_put(xprt);
> >  		kfree(dr);
> >  		return;
> > @@ -902,10 +904,10 @@ static void svc_revisit(struct cache_deferred_req *dreq, int too_many)
> >  static struct cache_deferred_req *svc_defer(struct cache_req *req)
> >  {
> >  	struct svc_rqst *rqstp = container_of(req, struct svc_rqst, rq_chandle);
> > -	struct svc_deferred_req *dr;
> > +	struct svc_deferred_req *dr = NULL;
> >  
> >  	if (rqstp->rq_arg.page_len)
> > -		return NULL; /* if more than a page, give up FIXME */
> > +		goto out; /* if more than a page, give up FIXME */
> >  	if (rqstp->rq_deferred) {
> >  		dr = rqstp->rq_deferred;
> >  		rqstp->rq_deferred = NULL;
> > @@ -914,9 +916,9 @@ static struct cache_deferred_req *svc_defer(struct cache_req *req)
> >  		size_t size;
> >  		/* FIXME maybe discard if size too large */
> >  		size = sizeof(struct svc_deferred_req) + rqstp->rq_arg.len;
> > -		dr = kmalloc(size, GFP_KERNEL);
> > +		dr = kzalloc(size, GFP_KERNEL);
> >  		if (dr == NULL)
> > -			return NULL;
> > +			goto out;
> >  
> >  		dr->handle.owner = rqstp->rq_server;
> >  		dr->prot = rqstp->rq_prot;
> > @@ -935,7 +937,13 @@ static struct cache_deferred_req *svc_defer(struct cache_req *req)
> >  	dr->xprt = rqstp->rq_xprt;
> >  
> >  	dr->handle.revisit = svc_revisit;
> > -	return &dr->handle;
> > +	if (rqstp->rq_save_state)
> > +		rqstp->rq_save_state(rqstp, dr);
> > +out:
> > +	rqstp->rq_defer_data = NULL;
> > +	rqstp->rq_save_state = NULL;
> > +
> > +	return dr ? &dr->handle: NULL;
> 
> I may not be thinking this through clearly, but: I think the correct
> place to initialize rq_defer_data and rq_save_state is not here but at
> the very start of request processing (in svc_recv or at the top of
> svc_process).  We shouldn't depend on svc_defer()--it may never get
> called.

In patch 3/3, nfsd4_proc_compound sets the rq_defer_data and
rq_defer_state prior to operation processing, and then sets them back to
NULL after operation processing, so the initialization to NULL in
svc_defer is not needed.

We could indeed initialize these fields at the top of svc_process in
which case the setting to NULL at the end of operation processing in
nfsd4_proc_compound would not be needed. Your call.

-->Andy

> --b.
> 
> >  }
> >  
> >  /*
> > @@ -959,6 +967,8 @@ static int svc_deferred_recv(struct svc_rqst *rqstp)
> >  	rqstp->rq_xprt_hlen   = dr->xprt_hlen;
> >  	rqstp->rq_daddr       = dr->daddr;
> >  	rqstp->rq_respages    = rqstp->rq_pages;
> > +	if (dr->restore_state)
> > +		dr->restore_state(rqstp, dr);
> >  	return (dr->argslen<<2) - dr->xprt_hlen;
> >  }
> >  
> > -- 
> > 1.5.4.3
> > 

  reply	other threads:[~2008-10-17 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 21:00 [PATCH 0/3] NFSD EOS deferral andros
2008-10-15 21:00 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros
2008-10-15 21:00   ` [PATCH 2/3] NFSD save, restore, and release deferred result pages andros
2008-10-15 21:00     ` [PATCH 3/3] NFSD deferral processing andros
2008-10-17 20:46       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDNY30k000001cc-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 17:58           ` J. Bruce Fields
2008-10-17 17:48   ` [PATCH 1/3] SUNRPC add deferral processing callbacks J. Bruce Fields
2008-10-17 18:42     ` Andy Adamson [this message]
2008-10-17 20:35   ` Talpey, Thomas
     [not found]     ` <RTPCLUEXC1-PRDf3sll000001cb-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:42       ` J. Bruce Fields
2008-10-17 17:44 ` [PATCH 0/3] NFSD EOS deferral J. Bruce Fields
2008-10-17 18:44   ` Andy Adamson
2008-10-17 18:59   ` Marc Eshel
     [not found]     ` <OF9E4C4BA6.37418EC7-ON882574E5.0067FB2B-882574E5.0068487F@ us.ibm.com>
2008-10-17 20:26       ` Talpey, Thomas
     [not found]         ` <RTPCLUEXC1-PRDidcDj000001ca-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-17 20:36           ` J. Bruce Fields
2008-10-17 20:51             ` Talpey, Thomas
     [not found]               ` <RTPCLUEXC1-PRDarcR4000001cd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-20 18:06                 ` J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2008-10-22 18:12 andros
2008-10-22 18:12 ` [PATCH 1/3] SUNRPC add deferral processing callbacks andros

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=1224268939.3883.29.camel@localhost.localdomain \
    --to=andros@netapp.com \
    --cc=andros-HgOvQuBEEgQAvxtiuMwx3w@public.gmane.org \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    /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.