Re: When IBoE will be merged to upstream?

Roland Dreier
2010-07-12T21:20:22Z

> 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 <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to: