[ewg] [PATCH] pkey fix for ipoib - resubmission

[Todd Rimmer]

Jason wrote:

> What happens if the SM reprograms the pkey table later?
> 
> I'm not sure this is the right approach.. See the recent dicussion
> about using pkey indexes at all.
> 
> Each ipoib interface is assigned a pkey, by number, not index. If the
> SM has not supplied that pkey to the port then the ipoib should not
> come up. If the SM adds it later then it should come up, if it the SM
> removes it later then it should go down.
> 
> The default ipoib interface uses the default pkey. If your network
> need ipoib to use a different pkey then you have to change the pkey
> number assignment when the ipoib interface is created, not magically
> attempt to autoconfigure.
> 
> I believe you cannot safely change the broadcast GID once the ipoib
> interface has started.

The goal for IPoIB should be a mechanism which can mimic the ease of setting up VLANs in Ethernet.  In Ethernet a default VLAN can be programmed into a switch in which case no configuration of the server is needed.  Ethernet switch vendors often provide centralized tools for setting up VLANS in all the switches.  It is only when you want a given server to participate in multiple VLANs that you need to setup specific configuration on the server to do so.

For IB, the centralized tool is the SM and a "VLAN" is an IB Partition.  The present capability of using the 1st PKey table entry is a nice simple and powerful way to mimic the ease of use of Ethernet VLANs.  Only when a user wants IPoIB to run on two different partitions (which is rare) is a server specific configuration needed.

When IPoIB sees a PKey table change, it will reregister with the broadcast GID.  PKey table changes typically also involve a restart of the SM and hence a reregistration request is necessary anyway.

Todd Rimmer
Chief Architect 
QLogic Network Systems Group
Voice: 610-233-4852     Fax: 610-233-4777
Todd.Rimmer at QLogic.com  www.QLogic.com