On Thu, 2005-06-30 at 14:45, Roland Dreier wrote: > Looking at the code, I have to say that I don't like the strategy of > returning the actual length of the MAD but not copying anything if the > MAD is too big. It seems error prone to return a length bigger than > the user passed in to read(), and it doesn't feel right either. > > I understand and agree with the sentiment of not wanting to add > another ioctl() to get the length. Instead, how about returning a > ib_user_mad_hdr with a status of ENOSPC and putting the actual length > somewhere. I'm not sure if it's better to change the ABI and add a > length field to ib_user_mad_hdr, or if we want to return the first 36 > bytes of an RMPP MAD so the user can figure out the correct length. > > Also, since we check if the MAD at the head of the receive queue won't > fit in the user's buffer when we're about to pop it off the queue, > instead of dequeuing and then requeuing it, we can just leave it at > the head of the queue. (I'm not sure if this buys us anything but it > seems there might be a race MADs get out of order) > > Sorry for not bringing this up when you asked about how to handle > too-big MADs a few days ago -- I didn't understand your question > really.
You understand it now and answered it well :-) I'm not wedded to the read approach and you have offered 2 alternatives. Unfortunately, I don't think the length in the first segment is reliable (it works for OpenIB but may not for other RMPP implementations) so I would rather not rely on that. So I guess this means an ABI change :-( Do you concur ? If so, I will work on that approach. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
