> At this point, the mask_status could be IB_INVALID_GUID_MASK (in the current > unpatched code). If one of the vendor-specific conversion functions returned > IB_SUCCESS the code still returns IB_INVALID_GUID_MASK, which is wrong. In > fact, even if the GUID has no known conversion function, the code will fall > through to the locally administered MAC address generation, and then return > IB_INVALID_GUID_MASK anyway...
Oy, so the plot thickens... The IB_INVALID_GUID_MASK error code isn't actually an error - the code that checks for this value uses it to log a entry in the event log, but expects the MAC to be generated anyways... So it's an error that isn't an error... Ugh, talk about convoluted. It would have been *really* helpful to have some comment that would inform the reader of this totally counter intuitive behavior. Ok, so I'm going to fix up my 4th patch (again) to implement the following behavior: 1. Ignore the registry GUID mask if there is a known conversion for a GUID. This is especially needed in the receive path, as the GUID mask code will potentially incorrectly generate a MAC address for a known GUID - Mellanox, SilverStorm, and Voltaire GUIDs all would get improperly generated. 2. Attempt MAC generation if a GUID mask is provided, only for the local port GUIDs during adapter initialization. The remote port GUIDs (from a received packet) should *not* use the GUID mask, as the local node has no idea what the remote GUID formats are. 3. If a GUID mask is provided, fail adapter initialization if it is invalid. -Fab _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
