[ofa-general] question regarding umad_recv

[Sasha Khapyorsky]

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