The receiving side doesn't perform a data copy. It collects the separate MAD buffers together in a list and hands those to the user.
Yes. I meant user_mad.c needs a buffer to copy into on ib_umad_read and hence the size needs to be known ahead of time. That's where I think a peek might be useful (for RMPP, not for fixed size MADs).
By the time the kernel client gets the MAD, it's been reassembled, and the exact size that's needed is known. So, I don't think that this is an issue for kernel clients.
Maybe you could add a peek for usermode or have read return the correct size if the requested size is too small. Since you have to do a data copy for usermode anyway, I think it makes sense to just return the coalesced buffer. This makes me think that I should implement ib_coalesce_recv_mad() now.
I'm not sure how important streaming RMPP is. I would defer this.
I agree. :)
- Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
