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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
