[Openib-windows] IPoIB GUID to MAC conversion

[Yossi Leybovich]

I would go for option (4) , We tried it here in Mellanox. NDIS does not care
if you change your MAC between Disable/Enable.
The Local MAC should use LID 0 ,this enable you to have MAC even if the SM
not config you yet , and not changing your MAC if the SM reassign your LID.
So the local system use LID 0 for the MAC while the remote system use the
true LID for MAC.
This also good for Multicast MACs.
 
Yossi 

-----Original Message-----
From: Dror Goldenberg [mailto:gdror at mellanox.co.il] 
Sent: Wednesday, May 25, 2005 10:32 PM
To: Fab Tillier; openib-windows at openib.org
Subject: RE: [Openib-windows] IPoIB GUID to MAC conversion





> From: Fab Tillier [mailto:ftillier at silverstorm.com
<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
<http://openib.org/mailman/listinfo/openib-windows>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050526/80b94513/attachment.html>