>The challenge with the current query/request method is that as we've >discussed the advertised max may not work. What makes the adjust/retry >unworkable is that you don't know which of the advertised maxes caused >the request to fail. So when you retry, which qp_attr do you adjust? The >send sge? The recv sge? The qp depth? > >So what I'm proposing, and I think is similar if not identical to what >other folks have talked about is having an interface that treats the >qp_attr values as requested-sizes that can be adjusted by the provider. >So for example, if I ask for a send_sge of 30, but you can only do 28, >you give me 28 and adjust the qp_attr structure so that I know what I >got. This would allow me to perform a predictable sequence of 1. query, >2. request, 3. adjust in my code.
If the send sge/recv sge/qp depth/etc. aren't independent though, this pushes the problem and policy decision down to the provider. I can't think of an easy solution to this. - Sean _______________________________________________ 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
