[ofw] RE: [PATCH 1/4] Clean up MAC generation, add support for HP GUIDs

Alex Naslednikov xalex at mellanox.co.il
Mon Oct 6 09:56:16 PDT 2008


Hello all,
Following our discussion during WinOF meeting, I'd like to explain
better what we meant by "one final patch".
Of course, the division into small chunks should be preserved.
We just want to avoid bringing unnecessary noise into svn trunk, because
Fib's patch included "fix to the fix to the patch"

Fab, we would like to ask you resend us the final version of your
patches again, 
Thank You,
XaleX 

-----Original Message-----
From: Alex Naslednikov 
Sent: Thursday, October 02, 2008 10:14 AM
To: 'Fab Tillier'; ofw at lists.openfabrics.org
Subject: RE: [ofw] RE: [PATCH 1/4] Clean up MAC generation,add support
for HP GUIDs

Hello Fab,
Thank you for your time for reviewing GUID patches.
Please, send again one final patch - there's no need to insert all these
patches into svn tree.

XaleX 

-----Original Message-----
From: ofw-bounces at lists.openfabrics.org
[mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
Sent: Tuesday, September 30, 2008 10:01 PM
To: Fab Tillier; ofw at lists.openfabrics.org
Subject: [ofw] RE: [PATCH 1/4] Clean up MAC generation,add support for
HP GUIDs

> 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
ofw at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw



More information about the ofw mailing list