Re: [RFC,PATCH 00/20] svc: Server Side Transport Switch

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]



Tom Tucker wrote:
> [...snip...]
>>> For example,
>>>
>>> # echo rdma 2050 > /proc/fs/nfsd/portlist
>>>
>>> Will cause the knfsd daemon to attempt to add a listening endpoint on
>>> port 2050 using the 'rdma' transport.
>> Does this also register the new endpoint with the server's portmapper,
>> or is there an additional step required for this?  At least for RDMA I
>> assume the portmapper registration is not needed, but other transports
>> may want it.
> 
> No it doesn't, but IMO it needs to. The reason it doesn't is that the
> current portmapper registration service doesn't look at the netid, it looks
> at the protocol number and maps that to a netid internally. I think this is
> broken, but that's what it does. Since RMDA doesn't have an IP protocol, I
> couldn't map it with the current services.
> 
> I think the right thing to do is to modify the rpcb_register service to take
> a netid and set it in the rpc_msg, and modify the portmapper to honor the
> netid specified. 

Version 2 of the rpcbind protocol doesn't take a netid.  To register a 
netid with the local portmapper, you need two things to happen:

1.  The local portmapper needs to be something that can take v3 or v4 
registration requests

2.  rpcb_register needs to be converted to use v3 or v4 of the rpcbind 
protocol to do the registering.

3.  Mr. Talpey needs to submit his patch to make RPC transport 
implementations support RPC_DISPLAY_NETID so the rpcbind client has a 
proper netid string to send to the local rpcbind daemon.

Thing 1 seems to be happening as distributions start using the new 
rpcbind daemon to replace the old portmapper.

Thing 2 can happen easily after thing 1 is commonplace.

Thing 3 is under development.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs