All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Matt W. Benjamin" <matt@linuxbox.com>
To: nfsv4 <nfsv4@ietf.org>
Cc: nfs-ganesha-devel <nfs-ganesha-devel@lists.sourceforge.net>,
	linux-nfs <linux-nfs@vger.kernel.org>
Subject: back channel flags, CREATE_SESSION, BIND_CONN_TO_SESSION
Date: Wed, 5 Oct 2011 19:21:48 -0400 (EDT)	[thread overview]
Message-ID: <800236997.158.1317856908314.JavaMail.root@thunderbeast.private.linuxbox.com> (raw)
In-Reply-To: <767481161.156.1317856859691.JavaMail.root@thunderbeast.private.linuxbox.com>

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

       reply	other threads:[~2011-10-05 23:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <767481161.156.1317856859691.JavaMail.root@thunderbeast.private.linuxbox.com>
2011-10-05 23:21 ` Matt W. Benjamin [this message]
2011-10-06  3:28   ` [nfsv4] back channel flags, CREATE_SESSION, BIND_CONN_TO_SESSION Trond Myklebust
2011-10-06  3:44     ` Trond Myklebust
2011-10-07  1:42     ` Rick Macklem
2011-10-07  1:49       ` Myklebust, Trond

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=800236997.158.1317856908314.JavaMail.root@thunderbeast.private.linuxbox.com \
    --to=matt@linuxbox.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfs-ganesha-devel@lists.sourceforge.net \
    --cc=nfsv4@ietf.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.