> > 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. >
We believe the problems are workable. But let us stop arguing for a while and make progress with link local addressees since we all seem to agree with that. We can get back to non-local GIDs later > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
