[ofa-general] [PATCH RFC] rds: add iwarp support

[Steve Wise]

Sean Hefty wrote:
>> The reason for not using rdma_resolve_addr() is to avoid having to
>> allocate and free a cm_id each time we just want to find the local ib
>> device, given a remote IP addr...
>>     
>
> Can someone explain why this needed?  The local IB device is resolved as part of
> the connection establishment process.  Why is an additional mechanism needed?
>
>   

RDS experts, correct me if this is wrong:

RDS exposes a reliable datagram service to user apps. To do this it 
keeps connections to each host with RDS apps running and muxes user 
datagrams over these connections using its own protocol. Further there 
are 3 types of "transports" supported: TCP/IP, IB, and IW. When a user 
app sends a datagram, the RDS module must figure out which transport 
should be used. It does this based on the destination (and maybe local?) 
ip addr of the RDS application's socket. Prior to the iWARP patch, the 
way this transport switch decision was made was to look up the local 
netdev based on the ipaddr(s) and if the netdev's ARP header type was 
INFINIBAND, then obviously the IB transport should be used. With the 
addition of iWARP, the decision is a little more complicated because the 
iWARP netdev arp type is ETHERNET. So Jon added this new cma service to 
find the netdev, then take the netdev mac address and search the gid 
cache to see if that mac address was actually a gid for an rdma device. 
If the mac addr was found, then we know this netdev supports rdma. 
Creating the new service simply made this lookup light-weight by not 
requiring a cm_id to be created, bound, etc.

Maybe there's a better way?

Steve.