[Openib-windows] IPoIB GUID to MAC conversion

[Dror Goldenberg]

> From: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Wednesday, May 25, 2005 9:00 PM
> 
> 
> Folks,
> 
> The IPoIB driver is an NDIS miniport driver that reports 
> itself as an 802.3 Ethernet device.  NDIS doesn't support MAC 
> addresses larger than 6 bytes.
> 
> Currently, the driver has knowledge of how to convert 
> InfiniCon/SilverStorm port GUIDs into valid, globally unique 
> Ethernet MAC addresses.  Is this the case for any of the 
> other IB vendors?  If so, what is the algorithm?

Linux 2.4 had the exact same problem. You can take a look 
at the gen1 code to see what of solutions people had. One 
example: gen1/trunk/src/linux-kernel/infiniband/ulp/ipoib/ipoib_arp.c
is some hashing on the {GID,QPN} into 48 bits. I don't believe it has any
assumption on how GUID is constructed / allocated by the
vendor.

> 
> I'd like to hear suggestions for how to handle all vendors 
> with this driver, as well as how to properly handle GIDs 
> where the lower 64-bits aren't the port GUID.

Can be one of:
1) generic hash on GID - all nodes will show the same MAC
      entries on ARP. You're stuck if you have hash collision
2) create locally faked MAC in each node - not all nodes will
      show the same MAC (arp -a). You can solve it by writing
      a new utility, e.g. ipoib_arp, which will dump the full 20B
      MAC addresses by using some private interface with the NDIS 
      miniport
3) assume some GUID assignment algorithm - can be problematic
      looking into the future. Might not fit all cards, all vendors, etc.
      I'm not sure that all the vendors can commit on how they
      assign GUIDs today, because they may want the ability
      to change the GUID assignment method without rewriting 
      the miniport.
4) Use the 48 bits to contain the path information. A non IB routable
     approach will use the bits as follows: 16 LID, 4 SL, 24 QPN,
     2 static rate (might be not enough to hold all static rate options)
     2 reserved (local/global, unicast/mcast) - total 48 bits.
     
I don't have any strong opinion about which one to choose. 

> 
> One thing that needs to happen is for local instances of the 
> driver to have the same MAC address across disable/enable 
> device state transitions.

Can you better explain ? MAC address is {GID,QPN}. If you disable/enable
the HCA you might end up getting a new QPN which implies that your MAC
address has changed. This is how IPoIB supposed to work.
If you want to preserve the MAC, you'd need to maintain the same QP which 
is something beyond the standard IB verbs. By tweaking the driver , you can
reserve some QP numbers for IPoIB. But is it really required ?


> 
> Thanks,
> 
> - Fab
> 
> _______________________________________________
> openib-windows mailing list
> openib-windows at openib.org 
> http://openib.org/mailman/listinfo/openib-windows
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050525/2beedcf9/attachment.html>