[ofa-general] Re: [PATCH V2] mlx4: check for FW version which properly supports resize_cq

[Jack Morgenstein]

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