Skip to contentSkip to conversation

back channel flags, CREATE_SESSION, BIND_CONN_TO_SESSION

DISCUSSION Matt W. Benjamin 3 participants 5 messages Oct 5, 2011 – Oct 7, 2011 1 message not in the archive

Subsystems (2)
NFS client NFS server
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 767481161.156.1317856859691.JavaMail.root@thunderbeast.private.linuxbox.com

Matt W. Benjamin

author
#1 lore raw

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

Signature · 11 lines
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
#2 lore raw
Quoted 3 lines · Matt W. Benjamin

Hi,

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?

Quoted 1 line

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.

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.

Quoted 1 line

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.

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

Signature · 6 lines
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com
#3 lore raw
Quoted 6 lines · Trond Myklebust
Quoted 1 line · Matt W. Benjamin

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.

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?

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?

Signature · 6 lines
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
www.netapp.com
#4 lore raw
In reply to Trond Myklebust
Quoted 41 lines · Trond Myklebust
Quoted 4 lines · Matt W. Benjamin

Hi,

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?

Quoted 7 lines

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.

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.

Quoted 7 lines

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.

Quoted 5 lines

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?

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 doesnt set it in csr_flags, I simply assume no backchannel. I dont 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

#5 lore raw

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSaWNrIE1hY2tsZW0gW21haWx0 bzpybWFja2xlbUB1b2d1ZWxwaC5jYV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIw MTEgOTo0MiBQTQ0KPiBUbzogTXlrbGVidXN0LCBUcm9uZA0KPiBDYzogbGludXgtbmZzOyBuZnMt Z2FuZXNoYS1kZXZlbDsgbmZzdjQ7IE1hdHQgVy4gQmVuamFtaW4NCj4gU3ViamVjdDogUmU6IFtu ZnN2NF0gYmFjayBjaGFubmVsIGZsYWdzLCBDUkVBVEVfU0VTU0lPTiwNCj4gQklORF9DT05OX1RP X1NFU1NJT04NCj4gDQo+IFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gPiBPbiBXZWQsIDIwMTEt MTAtMDUgYXQgMTk6MjEgLTA0MDAsIE1hdHQgVy4gQmVuamFtaW4gd3JvdGU6DQo+IEp1c3QgZnlp LCB3aGF0IEkgaGF2ZSBpbXBsZW1lbnRlZCAoYW5kIEkgZG9uJ3QgaW50ZW5kIHRvIGNoYW5nZSBp dCkgaXMgd2hhdA0KPiBUcm9uZCBjdXJyZW50bHkgaGFzIGRvbmUuIEZvciB0aGUgRnJlZUJTRCA0 LjEgY2xpZW50LCBpdCB3aWxsIHNldA0KPiBDUkVBVEVfU0VTU0lPTjRfRkxBR19DT05OX0JBQ0tf Q0hBTiBpbiBjc2FfZmxhZ3MsIGJ1dCBpZiB0aGUgc2VydmVyDQo+IGRvZXNuYHQgc2V0IGl0IGlu IGNzcl9mbGFncywgSSBzaW1wbHkgYXNzdW1lIGBubyBiYWNrY2hhbm5lbGAuIEkgZG9uYHQgcGxh biBvbg0KPiBpbXBsZW1lbnRpbmcgYSBkZWRpY2F0ZWQgYmFjayBjaGFubmVsLiAoSSBzdXBwb3Nl IHRoYXQgY291bGQgY2hhbmdlIGlmDQo+IHRoZXJlIHdlcmUgc3Ryb25nIGV2aWRlbmNlIHRoYXQg YSBkZWRpY2F0ZWQgYmFjayBjaGFubmVsIGRpZCBpbXByb3ZlDQo+IHBlcmZvcm1hbmNlIHNpZ25p ZmljYW50bHkuKQ0KPiANCj4gSSB0aG91Z2h0IElgZCBwb3N0IHRoaXMgbWFpbmx5IHRvIHNob3cg dGhhdCB0aGVyZSBhcmUgYWN0dWFsbHkgdGltZXMgd2hlbiBJDQo+IGFncmVlIHdpdGggVHJvbmQ7 LSkgcmljaw0KDQpIZXkuLi4gRG9uJ3QgeW91IGFsd2F5cz8gOy0pDQoNCiAgICAgVHJvbmQNCg==