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:
> These are the things done today in the kernel wrt IB:
> * Map a local or remote IP address to a GID
> * If a local address is not given, provide a usable address based on the destination address
> * Acquire a path between the source and destination
> * Format the first 36 bytes of private data in the CM REQ
> Any or all of these could be done in user space instead.  Adding AF_IB to the kernel can provide a clean way of enabling this.  It can also allow full support of IB CM functionality through the RDMA CM interfaces
Sean,

First, on top of what you have mentioned above, the kernel also 
generates the SID to connect to / listen on, maintains a "binding" 
(mapping) between an rdma-cm id to a netdevice which today is used for 
generating address change events, and maybe some more tasks which I 
neither of us brought. From what you write here I understand that the 
reasoning is something like:

1. we can do all this in user space
2. for that end AF_INET/PS_TCP flow has to be converted to AF_IB/PS_IB 
behind the cover

well, you didn't address some of my comments (not the ice-cream 
ones...), which come to say that this wouldn't be inter-operable if for 
one side you convert INET/TCP to IB/IB and for the other side you don't 
(e.g userA/userB user/kernel kernel/user etc schemes). Also the 
functionality added under the bonding scheme is lost, etc.

I am asking you to have INET/TCP apps enjoy both ACM's DGID and route 
resolution without being converted to IB/IB, simple as that. If needed 
I'd be happy to assist in making this flow happen.

The rdma-cm was born first and most to serve as a glue between the IP 
and RDMA worlds, and I just ask you, as the maintainer, to keep this 
well-going-glue happening also under ACM.

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