On Wed, Jun 3, 2015 at 10:53 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Wed, Jun 03, 2015 at 10:05:34PM +0300, Or Gerlitz wrote: > >> Indeed the DHCP story isn't working there and to get DHCP work >> something has to be done. But this issue can't serve for blocking the >> existing UAPI and introduce regression to working systems. > > It is not DHCP that concerns me, it is the fact we can't combine net > namespaces, RDMA-CM and duplicate GUID IPoIB children together without > adding hacks to the kernel. Searching netdevs by IP is a hack. > > I'm mostly fine with it as an optional capability, similar to macvlan, > I just don't see how to cleanly integrate it with RDMA CM and > namespaces. And I don't see what RDMA CM is supposed to do when > it hits this case. > > So, any ideas that don't involve the searching for IP hack?? > > [And yes, as discussed with Haggie, it is not the worst hack in the > world, and maybe we can live with it, but lets understand the trade > offs carefully]
As Haggai wrote, if we let the using IP address thing to fly up, we have support for RDMA in containers using the RDMA-CM at IPoIB environments. This will let people test, use, experiment, fix, interact (and even production-it when static IP address assignment scheme is used). Later, usage of alias GUIDs for IPoIB RTNL childs would allow to remove the IP thing. Later, the next stage/s in Matan's work on the RoCE GID table would allow to support MACVLAN and hence RoCE too. This is how the Linux kernel being evolved since the 2.5 failure to come up with giant releases -- doing things in relativity small steps. > Also, now that this has been brought up, I think you need to make a > patch to fix the IPv6 SLAAC breakage this caused. It looks trivial to > modify addrconf_ifid_infiniband to return error if the IPoIB child is > sharing a guid. It was not good at all to push the child patches > forward to 3.6/3.7 if you knew that IPv6 SLAAC was broken by them. Till the alias GUID thing is introduced, maybe we can patch addrconf_ifid_infiniband to use the QPN value from the device HW address to come up with unique IPv6 link local address, agree? where you think we can place the 24 bits QPN? Or. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
