On Wednesday 08 July 2009 18:58, Roland Dreier wrote: > This is kind of dopey, isn't it? Seems cleaner just to leave the > resize_cq method unset if the hardware doesn't support it; then the core > takes care of this check for us. > Not so (unfortunately). The problem is that doing it the "correct" way (as you describe above) results in userspace apps getting "EINVAL" as the return value, and not ENOSYS. This means that there is no way to differentiate between a real error in the call, and simply a not-implemented verb. This really clobbers MPI.
That was the original reason I submitted this patch as I did. (I had forgotten about all these gory details, and went back and reviewed this issue for my reply here). I submitted a patch for the uverbs EINVAL/ENOSYS issue on Dec 2, 2008 See the short thread for a discussion of all the messy details I allude to above: http://lists.openfabrics.org/pipermail/general/2008-December/055734.html [PATCH] uverbs: return ENOSYS for unimplemented commands (not EINVAL), and my short comment to you in original patch I submitted for the resize_cq fw test http://lists.openfabrics.org/pipermail/general/2008-December/055770.html [PATCH V2] mlx4: check for FW version which properly supports resize_cq Basically, I did not want to deal with the global issue that the uverbs patch raises. Since MPI badly needed to differentiate between ibv_resize_cq() returning ENOSYS and returning EINVAL, the resize_cq patch represents a "local" fix for this specific verb -- rather than a fix with far-reaching consequences for any unimplemented verb. (BTW, the uverbs EINVAL/ENOSYS problem still exists in your tree. I'm not sure that we want to change this) . -Jack _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
