linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>,
	Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Anna Schumaker <anna@kernel.org>,
	 Anshuman Khandual <anshuman.khandual@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	David Hildenbrand <david@redhat.com>,
	Greg Marsden <greg.marsden@oracle.com>,
	Ivan Ivanov <ivan.ivanov@suse.com>,
	Kalesh Singh <kaleshsingh@google.com>,
	Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Matthias Brugger <mbrugger@suse.com>,
	Miroslav Benes <mbenes@suse.cz>,
	Trond Myklebust <trondmy@kernel.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-nfs@vger.kernel.org
Subject: Re: [RFC PATCH v1 21/57] sunrpc: Remove PAGE_SIZE compile-time constant assumption
Date: Wed, 16 Oct 2024 10:54:40 -0400	[thread overview]
Message-ID: <33a6cc271475b0fc520b8fc20ed0b4f7742a2560.camel@kernel.org> (raw)
In-Reply-To: <Zw/SE9+AMYmzBprS@tissot.1015granger.net>

On Wed, 2024-10-16 at 10:47 -0400, Chuck Lever wrote:
> On Wed, Oct 16, 2024 at 03:42:12PM +0100, Ryan Roberts wrote:
> > + Chuck Lever, Jeff Layton
> > 
> > This was a rather tricky series to get the recipients correct for and my script
> > did not realize that "supporter" was a pseudonym for "maintainer" so you were
> > missed off the original post. Appologies!
> > 
> > More context in cover letter:
> > https://lore.kernel.org/all/20241014105514.3206191-1-ryan.roberts@arm.com/
> > 
> > 
> > On 14/10/2024 11:58, Ryan Roberts wrote:
> > > To prepare for supporting boot-time page size selection, refactor code
> > > to remove assumptions about PAGE_SIZE being compile-time constant. Code
> > > intended to be equivalent when compile-time page size is active.
> > > 
> > > Updated array sizes in various structs to contain enough entries for the
> > > smallest supported page size.
> > > 
> > > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> > > ---
> > > 
> > > ***NOTE***
> > > Any confused maintainers may want to read the cover note here for context:
> > > https://lore.kernel.org/all/20241014105514.3206191-1-ryan.roberts@arm.com/
> > > 
> > >  include/linux/sunrpc/svc.h      | 8 +++++---
> > >  include/linux/sunrpc/svc_rdma.h | 4 ++--
> > >  include/linux/sunrpc/svcsock.h  | 2 +-
> > >  3 files changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> > > index a7d0406b9ef59..dda44018b8f36 100644
> > > --- a/include/linux/sunrpc/svc.h
> > > +++ b/include/linux/sunrpc/svc.h
> > > @@ -160,6 +160,8 @@ extern u32 svc_max_payload(const struct svc_rqst *rqstp);
> > >   */
> > >  #define RPCSVC_MAXPAGES		((RPCSVC_MAXPAYLOAD+PAGE_SIZE-1)/PAGE_SIZE \
> > >  				+ 2 + 1)
> > > +#define RPCSVC_MAXPAGES_MAX	((RPCSVC_MAXPAYLOAD+PAGE_SIZE_MIN-1)/PAGE_SIZE_MIN \
> > > +				+ 2 + 1)
> 
> There is already a "MAX" in the name, so adding this new macro seems
> superfluous to me. Can we get away with simply updating the
> "RPCSVC_MAXPAGES" macro, instead of adding this new one?
> 

+1 that was my thinking too. This is mostly just used to size arrays,
so we might as well just change the existing macro.

With 64k pages we probably wouldn't need arrays as long as these will
be. Fixing those array sizes to be settable at runtime though is not a
trivial project though.

> 
> > >  /*
> > >   * The context of a single thread, including the request currently being
> > > @@ -190,14 +192,14 @@ struct svc_rqst {
> > >  	struct xdr_stream	rq_res_stream;
> > >  	struct page		*rq_scratch_page;
> > >  	struct xdr_buf		rq_res;
> > > -	struct page		*rq_pages[RPCSVC_MAXPAGES + 1];
> > > +	struct page		*rq_pages[RPCSVC_MAXPAGES_MAX + 1];
> > >  	struct page *		*rq_respages;	/* points into rq_pages */
> > >  	struct page *		*rq_next_page; /* next reply page to use */
> > >  	struct page *		*rq_page_end;  /* one past the last page */
> > >  
> > >  	struct folio_batch	rq_fbatch;
> > > -	struct kvec		rq_vec[RPCSVC_MAXPAGES]; /* generally useful.. */
> > > -	struct bio_vec		rq_bvec[RPCSVC_MAXPAGES];
> > > +	struct kvec		rq_vec[RPCSVC_MAXPAGES_MAX]; /* generally useful.. */
> > > +	struct bio_vec		rq_bvec[RPCSVC_MAXPAGES_MAX];
> > >  
> > >  	__be32			rq_xid;		/* transmission id */
> > >  	u32			rq_prog;	/* program number */
> > > diff --git a/include/linux/sunrpc/svc_rdma.h b/include/linux/sunrpc/svc_rdma.h
> > > index d33bab33099ab..7c6441e8d6f7a 100644
> > > --- a/include/linux/sunrpc/svc_rdma.h
> > > +++ b/include/linux/sunrpc/svc_rdma.h
> > > @@ -200,7 +200,7 @@ struct svc_rdma_recv_ctxt {
> > >  	struct svc_rdma_pcl	rc_reply_pcl;
> > >  
> > >  	unsigned int		rc_page_count;
> > > -	struct page		*rc_pages[RPCSVC_MAXPAGES];
> > > +	struct page		*rc_pages[RPCSVC_MAXPAGES_MAX];
> > >  };
> > >  
> > >  /*
> > > @@ -242,7 +242,7 @@ struct svc_rdma_send_ctxt {
> > >  	void			*sc_xprt_buf;
> > >  	int			sc_page_count;
> > >  	int			sc_cur_sge_no;
> > > -	struct page		*sc_pages[RPCSVC_MAXPAGES];
> > > +	struct page		*sc_pages[RPCSVC_MAXPAGES_MAX];
> > >  	struct ib_sge		sc_sges[];
> > >  };
> > >  
> > > diff --git a/include/linux/sunrpc/svcsock.h b/include/linux/sunrpc/svcsock.h
> > > index 7c78ec6356b92..6c6bcc82685a3 100644
> > > --- a/include/linux/sunrpc/svcsock.h
> > > +++ b/include/linux/sunrpc/svcsock.h
> > > @@ -40,7 +40,7 @@ struct svc_sock {
> > >  
> > >  	struct completion	sk_handshake_done;
> > >  
> > > -	struct page *		sk_pages[RPCSVC_MAXPAGES];	/* received data */
> > > +	struct page *		sk_pages[RPCSVC_MAXPAGES_MAX];	/* received data */
> > >  };
> > >  
> > >  static inline u32 svc_sock_reclen(struct svc_sock *svsk)
> > 
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2024-10-16 14:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20241014105514.3206191-1-ryan.roberts@arm.com>
     [not found] ` <20241014105912.3207374-1-ryan.roberts@arm.com>
2024-10-14 10:58   ` [RFC PATCH v1 09/57] fs/nfs: Remove PAGE_SIZE compile-time constant assumption Ryan Roberts
2024-10-14 10:58   ` [RFC PATCH v1 21/57] sunrpc: " Ryan Roberts
2024-10-16 14:42     ` Ryan Roberts
2024-10-16 14:47       ` Chuck Lever
2024-10-16 14:54         ` Jeff Layton [this message]
2024-10-16 15:09           ` Ryan Roberts
2024-10-14 10:58   ` [RFC PATCH v1 23/57] net: " Ryan Roberts
2024-10-16 14:43     ` Ryan Roberts

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=33a6cc271475b0fc520b8fc20ed0b4f7742a2560.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anna@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chuck.lever@oracle.com \
    --cc=david@redhat.com \
    --cc=greg.marsden@oracle.com \
    --cc=ivan.ivanov@suse.com \
    --cc=kaleshsingh@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mbrugger@suse.com \
    --cc=ryan.roberts@arm.com \
    --cc=trondmy@kernel.org \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).