On Wed, Apr 20, 2011 at 1:57 AM, Hefty, Sean <[email protected]> wrote:
>> --- umad.cpp      (revision 7570)
>>
>> +++ umad.cpp   (revision 7571)
>>
>> @@ -613,11 +613,11 @@
>>
>>
>>
>>                 umad_convert_addr(&mad->addr, &((WM_MAD *) mad)->Address);
>>
>>                 hr = ports[portid].prov->Send((WM_MAD *) mad, NULL);
>>
>> -              umad_convert_av(&((WM_MAD *) mad)->Address, &mad->addr);
>>
>>                 if (FAILED(hr)) {
>>
>>                                 _set_errno(EIO);
>>
>>                                 return GetLastError();
>>
>>                 }
>>
>> +             umad_convert_av(&((WM_MAD *) mad)->Address, &mad->addr);
>
> I should have a fix for this within the next couple of days that won't impact 
> performance greatly.  The winmad library will need to support both address 
> formats: the WV_MAD_AV that it defined, plus a umad compatibility format.  It 
> can distinguish between the two by checking the 'Version' bits in the 
> address.  This should ensure backwards compatability.
>
> However, this likely won't matter in practice, since there's no need to do 
> anything unless grh_present flag is set, and I don't see anything in the 
> stack which does this,

Some of the infiniband-diags can set the grh_present flag. I tested
perfquery with GRHs quite some time ago and I think there are other
diags which can do that too.

-- Hal

> or think of any reason why it should ever be needed.  But just in case some 
> app out there is trying to use it, I'll update libibumad and winmad.dll 
> accordingly.
>
> - Sean
> _______________________________________________
> ofw mailing list
> [email protected]
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
_______________________________________________
ofw mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw

Reply via email to