RE: When IBoE will be merged to upstream?

Liran Liss
2010-07-15T11:00:49Z

> > 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.