Re: [PATCH 2/2] rdma/cm: allow user to specify IP to DGID mapping

[Or Gerlitz <ogerlitz-smomgflXvOZWk0Htik3J/w@public.gmane.org>]

Sean Hefty wrote:
>> okay, I just wanted to make sure that the whole thing (ACM + modified librdmacm + modifed rdma-cm) is applicable AND inter-operable for AF_INET / PS_TCP applications
> I do not intend to have any changes that break anything
my question went beyond whether things are going to be broken (they 
aren't as you said), but rather will ACM is going to be 
***applicable***  for AF_INET/PS_TCP application. From your reply and 
the discussion that followed between you and Jason, I got the impression 
that the answer is "not really" b/c if for example the server side 
thinks it would be getting the IP address of the connecting side in the 
REQ private header, once this REQ was sent in the flow of AF_INET which 
was converted to AF_IB, this is not going to happen. Moreover, if the 
SID constructed by AF_INET / PS_TCP call to rdma_resolve_address which 
uses the librdmacm-ACM flow wouldn't match the SID constructed in the 
passive side which didn't use this flow (e.g user --> kernel or kernel 
--> user app), the REQ wouldn't be getting anywhere and be rejected by 
the CM on the passive side :(

>> Going with your proposed flow, I understand that an app call to rdma_resolve_addr will be broken down to rdma_bind_addr, ACM resolution of the destination GID and then rdma_set_ib_dest, so things should work perfect for AF_INET / PS_TCP apps, correct?
> This is my current plan for the kernel: export rdma_set_ib_paths to user space.  Submit a patch.  Get it accepted upstream.  Eat ice cream to celebrate.
again, rdma_set_ib_path for itself is quite innocent... as I wrote you 
couple of days ago, it can be merged anytime, the big thing is the bind 
/ address resolution modified flow which effects the connect/listen, 
etc.  So just for this patch, I would go on a small size ice-cream, 
where once the design for the bigger picture is in place, go for a pint...

> Define AF_IB and struct sockaddr_ib (contains a gid and service id).  Update rdma_bind_addr, rdma_resolve_addr, and rdma_connect to handle AF_IB. rdma_bind_addr fills in the sid according RDMA IP CM service annex. rdma_resolve_addr just needs to save the GIDs. rdma_connect will not modify the private data in the CM REQ for AF_IB.
I really tried to follow the thread between you and Jason with quite 
little success, and I am going to give it more tries... in parallel, 
could you help me understand what is the --drive/reasoning-- from your 
perspective to add AF_IB / PS_IB here?

I believe that the suggestion I brought of: converting rdma_resolve_addr 
with null src addr to route lookup and following that rdma_bind_addr, 
with a similar/same flow for rdma_resolve_addr with src address, next do 
the ACM dgid resolution, call the rdma_set_dgid call. Would allow to 
serve AF_INET / PS_TCP with ACM.

If from other reasons, people want the rdma-cm to support AF_IB and/or 
PS_IB, we can do that as well, but why force doing that behind the cover 
each time ACM is used?!

Or.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html