At 01:11 PM 4/7/2009, Jeff Layton wrote:
>On Tue, 07 Apr 2009 12:27:49 -0400
>Tom Talpey <tmtalpey@xxxxxxxxx> wrote:
>
>> At 12:02 PM 4/7/2009, Chuck Lever wrote:
>> >
>> >On Apr 7, 2009, at 11:25 AM, Jeff Layton wrote:
>> >> + /* Use standard NFS port for NFSv4 */
>> >> + if (program == 100003 && version == 4) {
>> >> + port = 2049;
>> >> + goto set_port;
>> >> + }
>> >
>> >I think this patch set looks pretty reasonable. Here's my one
>> >remaining quibble.
>> >
>> >You can specify "port=" for nfs4 mounts, in which case we want to use
>> >that value here, too, I think. It would be simpler overall if the
>>
>> *Must* use a port= specification. The 2049 definition is only true for
>> NFSv4/TCP, as a counterexample the NFSv4/RDMA IANA binding is
>> port 20049. So slamming the port to 2049 would break NFSv4/RDMA.
>>
>
>rpc.gssd doesn't seem to be rdma-enabled at this point. It only seems
>to handle "tcp" and "udp" in the existing code.
Fair enough. But hardwiring 2049 for all transports is going to very
problematic. What's the motivation for bypassing the rpcbind query
altogether (that "goto set_port" skips over it)? Why not at least
try the query first?
>Does libtirpc handle RDMA properly? If so, this might not be too hard
>to enable, but I'd probably rather see it in a follow on patchset (and
>maybe by someone with more of a clue about RDMA than I currently have).
No, libtirpc doesn't have any RDMA support. But, there's no need for
RDMA support in it - only NFS does RDMA, in practice, and currently
that's just in-kernel.
My concern is simply that there be a way to specify, or discover a port
that isn't 2049 here. If mount.nfs supports it, other nfs-utils should too.
Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
