Re: [PATCH 1/1] mount: RDMA processing in the mount command is broken

[Steve Dickson <SteveD@redhat.com>]

Hey Chuck,

On 09/02/2010 04:15 PM, Chuck Lever wrote:
> 
> On Sep 2, 2010, at 4:00 PM, Steve Dickson wrote:
> 
>> The mounting code that process RMDA mounts is broken in a few places
>>
>> First with '-o proto=rdma' was broken because nfs_get_proto()
>> did not how to convert a netid of 'rdma' in to a AF_INET
>> address family.
> 
> The usual solution for that is to add appropriate definitions to /etc/netconfig.  
> Since "rdma" is going to become (or has become) a valid "IETF standard" netid, 
> shouldn't this be handled just like the other netids?  
No.. because it is not a netid... when 'rdma' become a netid we'll treat 
like one. Until the then let treat like we always have been... 

> At some point "rdma" is going to start showing up in rpcbind, 
> so this is going to have to work like a normal netid.
When this happen I will be more that willing to accept 
the patches that will add support for the new netid.

> 
>> Secondly, '-o rdma' was broken because po_get() was being using
>> to detect the existence of 'rdma' in the options. With '-o rdma'
>> there is no value associated with that option so po_get()
>> was always return NULL.
> 
> This should be handled just the same way the "udp" and "tcp" mount 
> options are handled, in nfs_nfs_protocol().  Just add an entry for 
> "rdma" in nfs_transport_opttbl. The problem is we don't have an 
> IPPROTO_ number for RDMA, so you'll have to make one up.
Exactly... And I was not about to make up a  IPPROTO_ number
I just think that's crazy... Plus it turns out we didn't need to.
All that's needed is for the address family to be set to 
AF_INET, from what Tom said. So it makes total sense put the
check in nfs_get_proto()

> What does the kernel do in these cases?
I took a quick look it appears they use IPPROTO_TCP (see xprt_setup_rdma())
but it appears they did not make up a IPPROTO_ number.

> 
>> This patch address both those problems.
> 
> Let's not riddle the mount code with these ad hoc string comparisons when 
> we've already got plenty adequate generic support for adding new transport labels.
Riddle?? I'm condensing two existing (broken) if statements and adding 
a third... I'm a bit taken back by your verbiage... I see changes to be
very unobtrusive and clean... with the befit of them working... ;-)

steved.