[ofa-general] question regarding umad_recv

[Sumit Gaur - Sun Microsystem]

Hi,

     Just want to confirm which OFED build you have integrated this bug 
(*support multiple umad_open_port*)fix. I am working on OFED-1.2.5.5. Also want 
to know if it is not available in my current Build, Could I apply any available 
patch to get fix.

Thanks and Regards
sumit


Sasha Khapyorsky wrote:
> On 12:56 Mon 15 Oct     , Sean Hefty wrote:
> 
>>>Seems you don't think it is very critical, cannot say I disagree so much.
>>>Hmm, let's change portid -> fd and depreciate umad_get_fd() after OFED?
>>
>>My vote is to retain some sort of abstraction.  Once we get rid of it, it will
>>be very hard to add it back in.
> 
> 
> That is true, but I cannot find scenario when using fd as umad device
> handle could be insufficient. Even if we will need to create some
> internally tracked per device data again (unlikely) fd can serve as us
> index just well. The whole issue is all about naming and seems minor for
> me - without actual API change we can rename it once and rename again
> later if it will be needed or keep things as it is - both options are
> fine. Anc since there is concern let's do nothing and stay with "as is".
> 
> 
>>My concern is that multi-thread receive handling isn't easily supported when
>>RMPP is involved, and having umad_recv take an abstract 'id' gives us some
>>flexibility that could come in useful someday.
>>
>>E.g. something like:
>>umad_recv() -> returns too small, gives necessary size + id specific to a mad
>>uamd_recv(mad id, new size ...) -> returns reassembled rmpp mad
> 
> 
> With this second umad_recv() we also will need to specify which umad
> device to use, I think API change will be required, right?
> (the option to encode both fd and mad id as first umad_recv() parameter
> looks messy for me.)
> 
> Sasha