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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
