> But, we can't mandate an overload of the GID in a way that it > prevents its use as a true L3 address (eventually routable).
Actually I'm beginning to think that the only possible way we can use the GID in IBoE is as a link-local IPv6 addresses containing an Ethernet address. Trying to hide neighbour discovery or ARP below the verbs doesn't seem workable -- being forced to change the locking rules we've had for the past 5+ years about create_ah is just the beginning. We get further problems if a remote address should ever change and I'm probably missing other issues. So the best solution I can see is to declare that an IBoE GID must be an IPv6 address coming from an EUI-64 Ethernet address for the corresponding port; for MGIDs I guess we use the standard IPv6 mapping to Ethernet address 33:33:xx:xx:xx:xx. I'm not sure how we want to handle IPv4 -- presumably unicast ARP can be done within the RDMA CM, which will then create a DGID with the appropriate Ethernet address. However it's not clear to me whether we need a way to create IPv4 (01:00:5e:xx:xx:xx) multicast addresses. Also, since there is no way to map a link-local IPv6 address to a particular interface, then I guess we need a way to pass in the VLAN tag to be used -- presumably we can steal some other field for the 12 bits. (The fact that the IBoE annex does not mention VLANs or 802.1q a single time is just another thing that shows how rushed and incomplete it is) With all this said, I think it means we do not need to do the mapping from GID to Ethernet address in the kernel for IBoE user verbs, since it is so simple -- we can simply add a fairly trivial helper to libibverbs. - R. -- Roland Dreier <[email protected]> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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
