Subject: [nfsv4] back channel flags, CREATE_SESSION, BIND_CONN_TO_SESSION

From: "Matt W. Benjamin" <[email-masked]>
Date: Wed, 5 Oct 2011 19:21:48 -0400 (EDT)

Hi,

There seem to be legitimate reasons for an (NFSv4.1) client and/or server to prefer a dedicated callback channel.

If a server wants this result, it seems from the language of 18.36.3 that it should indicate it by not setting CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csr_flags in the CREATE_SESSION response, presuming the flag is set in the corresponding csa_flags argument (it's not allowed to set it otherwise).  The client may respond with BIND_CONN_TO_SESSION on a new channel, setting bctsa_dir to CDFC4_BACK.

Currently, the Linux and I believe also the CITI Windows client always propose channels in both directions.  The Linux mainline Linux client doesn't know how to BIND_CONN_TO_SESSION, so trivially it won't negotiate any back channel if a server didn't agree to both directions today, either.  I've experimentally implemented a "fallback" model in a Linux client and (partly in a) Ganesha server.  I'd appreciate any feedback on the idea.

Thanks,

Matt

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 05 Oct 2011 23:28:13 -0400

> There seem to be legitimate reasons for an (NFSv4.1) client and/or server to prefer a dedicated callback channel.

That would be an assertion that is missing a lot of context and
explanation. Why should my client bother to support such a server?

> If a server wants this result, it seems from the language of 18.36.3 that it should indicate it by not setting CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csr_flags in the CREATE_SESSION response, presu…

Nope. The exact wording is:

         If CREATE_SESSION4_FLAG_CONN_BACK_CHAN is set in csa_flags, the
         client is requesting that the connection over which the
         CREATE_SESSION operation arrived be associated with the
         session's backchannel in addition to its fore channel.  If the
         server agrees, it sets CREATE_SESSION4_FLAG_CONN_BACK_CHAN in
         the result field csr_flags.  If
         CREATE_SESSION4_FLAG_CONN_BACK_CHAN is not set in csa_flags,
         then CREATE_SESSION4_FLAG_CONN_BACK_CHAN MUST NOT be set in
         csr_flags.

I see nothing there to indicate that the server is able to request a
dedicated backchannel. All it says is that the server may refuse a
backchannel on this particular connection.

> Currently, the Linux and I believe also the CITI Windows client always propose channels in both directions.  The Linux mainline Linux client doesn't know how to BIND_CONN_TO_SESSION, so trivially i…

Yep. As I said, why should we bother adding support for servers that
don't? I can function perfectly well without pNFS support or delegation
support in such a case. Performance will suck, but why do I care?

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 05 Oct 2011 23:44:56 -0400

> support in such a case. Performance will suck, but why do I care?

To put it in more basic terms: what you are proposing will add
development costs to the client and and an extra code burden to maintain
long term. So what is in it for me?

NetApp

---

From: Rick Macklem <[email-masked]>
Date: Thu, 6 Oct 2011 21:42:23 -0400 (EDT)

Trond Myklebust wrote:
> > There seem to be legitimate reasons for an (NFSv4.1) client and/or
> > server to prefer a dedicated callback channel.
> 
> > If a server wants this result, it seems from the language of 18.36.3
> > that it should indicate it by not setting
> > CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csr_flags in the
> > CREATE_SESSION response, presuming the flag is set in the
> > corresponding csa_flags argument (it's not allowed to set it
> > otherwise). The client may respond with BIND_CONN_TO_SESSION on a
> > new channel, setting bctsa_dir to CDFC4_BACK.
> 
> > Currently, the Linux and I believe also the CITI Windows client
> > always propose channels in both directions. The Linux mainline Linux
> > client doesn't know how to BIND_CONN_TO_SESSION, so trivially it
> > won't negotiate any back channel if a server didn't agree to both
> > directions today, either. I've experimentally implemented a
> > "fallback" model in a Linux client and (partly in a) Ganesha server.
> > I'd appreciate any feedback on the idea.
> 
Just fyi, what I have implemented (and I don't intend to change it) is
what Trond currently has done. For the FreeBSD 4.1 client, it will set
CREATE_SESSION4_FLAG_CONN_BACK_CHAN in csa_flags, but if the server
doesn`t set it in csr_flags, I simply assume `no backchannel`. I
don`t plan on implementing a dedicated back channel. (I suppose that
could change if there were strong evidence that a dedicated back channel
did improve performance significantly.)

I thought I`d post this mainly to show that there are actually times when I
agree with Trond;-) rick

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 6 Oct 2011 18:49:21 -0700

> -----Original Message-----
> From: Rick Macklem [mailto:[email-masked]]
> Sent: Thursday, October 06, 2011 9:42 PM
> To: Myklebust, Trond
> Cc: linux-nfs; nfs-ganesha-devel; nfsv4; Matt W. Benjamin
> Subject: Re: [nfsv4] back channel flags, CREATE_SESSION,
> BIND_CONN_TO_SESSION
> 
> Trond Myklebust wrote:
> Just fyi, what I have implemented (and I don't intend to change it) is what
> Trond currently has done. For the FreeBSD 4.1 client, it will set
> doesn`t set it in csr_flags, I simply assume `no backchannel`. I don`t plan on
> implementing a dedicated back channel. (I suppose that could change if
> there were strong evidence that a dedicated back channel did improve
> performance significantly.)
> 

Hey... Don't you always? ;-)

     Trond