From: Greg Banks <gnb@sgi.com>
To: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 008 of 11] knfsd: Prepare knfsd for support of rsize/wsize of up to 1MB, over TCP.
Date: Tue, 3 Oct 2006 11:59:20 +1000 [thread overview]
Message-ID: <20061003015920.GJ28796@sgi.com> (raw)
In-Reply-To: <17697.48800.933642.581926@cse.unsw.edu.au>
On Tue, Oct 03, 2006 at 11:36:32AM +1000, Neil Brown wrote:
> On Monday September 25, bfields@fieldses.org wrote:
> >
> > We're reporting svc_max_payload(rqstp) as the server's maximum
> > read/write block size:
>
> Yes. So I'm going to change the number returned by
> svc_max_payload(rqstp) to mean the maximum read/write block size.
> i.e. when a service is created, the number passed isn't the maximum
> packet size, but is the maximum payload size.
I'm confused. Last time I looked at the code that was
exactly what the semantics were?
> The assumption is that all of the request that is not payload will fit
> into one page, and all of the reply that is not payload will also fit
> into one page (though a different page).
This is a pretty good assumption for v3.
> It means that RPC services that have lots of non-payload data combined
> with payload data won't work, but making sunrpc code completely
> general when there are only two users is just too painful.
>
> The only real problem is that NFSv4 can have arbitrarily large
> non-payload data, and arbitrarily many payloads. But I guess any
> client that trying to send two full-sized payloads in the one request
> is asking for trouble (I don't suppose the RPC spells this out at
> all?).
Bruce and I briefly discussed this when I dropped into CITI the other
week. The conclusion was that this is a non-issue in the short term
because all the clients do a single READ or WRITE per call. In the
long term I hope to rewrite some parts of that code to do away with
one of the memcpy()s in the WRITE path, and handling multiple WRITEs
for v4 would be a natural extension of that.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
From: Greg Banks <gnb@sgi.com>
To: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [NFS] [PATCH 008 of 11] knfsd: Prepare knfsd for support of rsize/wsize of up to 1MB, over TCP.
Date: Tue, 3 Oct 2006 11:59:20 +1000 [thread overview]
Message-ID: <20061003015920.GJ28796@sgi.com> (raw)
In-Reply-To: <17697.48800.933642.581926@cse.unsw.edu.au>
On Tue, Oct 03, 2006 at 11:36:32AM +1000, Neil Brown wrote:
> On Monday September 25, bfields@fieldses.org wrote:
> >
> > We're reporting svc_max_payload(rqstp) as the server's maximum
> > read/write block size:
>
> Yes. So I'm going to change the number returned by
> svc_max_payload(rqstp) to mean the maximum read/write block size.
> i.e. when a service is created, the number passed isn't the maximum
> packet size, but is the maximum payload size.
I'm confused. Last time I looked at the code that was
exactly what the semantics were?
> The assumption is that all of the request that is not payload will fit
> into one page, and all of the reply that is not payload will also fit
> into one page (though a different page).
This is a pretty good assumption for v3.
> It means that RPC services that have lots of non-payload data combined
> with payload data won't work, but making sunrpc code completely
> general when there are only two users is just too painful.
>
> The only real problem is that NFSv4 can have arbitrarily large
> non-payload data, and arbitrarily many payloads. But I guess any
> client that trying to send two full-sized payloads in the one request
> is asking for trouble (I don't suppose the RPC spells this out at
> all?).
Bruce and I briefly discussed this when I dropped into CITI the other
week. The conclusion was that this is a non-issue in the short term
because all the clients do a single READ or WRITE per call. In the
long term I hope to rewrite some parts of that code to do away with
one of the memcpy()s in the WRITE path, and handling multiple WRITEs
for v4 would be a natural extension of that.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
next prev parent reply other threads:[~2006-10-03 1:59 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 6:36 [PATCH 000 of 11] knfsd: Introduction NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 001 of 11] knfsd: nfsd: lockdep annotation fix NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 002 of 11] knfsd: Fix a botched comment from the last patchset NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 003 of 11] knfsd: call lockd_down when closing a socket via a write to nfsd/portlist NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 004 of 11] knfsd: Protect update to sn_nrthreads with lock_kernel NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 005 of 11] knfsd: Fixed handling of lockd fail when adding nfsd socket NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:36 ` [PATCH 006 of 11] knfsd: Replace two page lists in struct svc_rqst with one NeilBrown
2006-08-24 6:36 ` NeilBrown
2006-08-24 6:37 ` [PATCH 007 of 11] knfsd: Avoid excess stack usage in svc_tcp_recvfrom NeilBrown
2006-08-24 6:37 ` NeilBrown
2006-08-24 6:37 ` [PATCH 008 of 11] knfsd: Prepare knfsd for support of rsize/wsize of up to 1MB, over TCP NeilBrown
2006-08-24 6:37 ` NeilBrown
2006-09-25 15:43 ` J. Bruce Fields
2006-09-25 15:43 ` [NFS] " J. Bruce Fields
2006-09-28 3:41 ` Neil Brown
2006-09-28 3:41 ` [NFS] " Neil Brown
2006-09-28 3:46 ` Andrew Morton
2006-09-28 3:46 ` [NFS] " Andrew Morton
2006-10-03 1:36 ` Neil Brown
2006-10-03 1:36 ` [NFS] " Neil Brown
2006-10-03 1:59 ` Greg Banks [this message]
2006-10-03 1:59 ` Greg Banks
2006-10-03 2:13 ` J. Bruce Fields
2006-10-03 2:13 ` [NFS] " J. Bruce Fields
2006-10-03 5:41 ` Neil Brown
2006-10-03 5:41 ` [NFS] " Neil Brown
2006-10-03 8:02 ` Greg Banks
2006-10-03 8:02 ` [NFS] " Greg Banks
2006-10-05 7:07 ` Neil Brown
2006-10-05 7:07 ` [NFS] " Neil Brown
2006-08-24 6:37 ` [PATCH 009 of 11] knfsd: Allow max size of NFSd payload to be configured NeilBrown
2006-08-24 6:37 ` NeilBrown
2006-09-25 21:24 ` J. Bruce Fields
2006-09-25 21:24 ` [NFS] " J. Bruce Fields
2006-09-28 4:22 ` Neil Brown
2006-09-28 4:22 ` [NFS] " Neil Brown
2006-09-28 17:09 ` Hugh Dickins
2006-09-28 17:09 ` [NFS] " Hugh Dickins
2006-09-29 1:59 ` Neil Brown
2006-09-29 1:59 ` [NFS] " Neil Brown
2006-08-24 6:37 ` [PATCH 010 of 11] knfsd: make nfsd readahead params cache SMP-friendly NeilBrown
2006-08-24 6:37 ` NeilBrown
2006-08-24 6:37 ` [PATCH 011 of 11] knfsd: knfsd: cache ipmap per TCP socket NeilBrown
2006-08-24 6:37 ` NeilBrown
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=20061003015920.GJ28796@sgi.com \
--to=gnb@sgi.com \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
/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.