[ewg] Re: pkey change handling patch

[Roland Dreier]

 > Could be a good idea, but note this will require creating another
 > WQ for cache updates, otherwise e.g. IPoIB
 > will deadlock waiting for it.

Actually, on further thought, it's kind of a stupid idea.  The whole
point of the cache module is to be usable in places where blocking
isn't allowed.  If it's being called from a context where we know we
can block, then there's no point in going through the cache at all.

 > By the way, are there any users for the non-blocking API?
 > Maybe we can simply relax the requirement, and make all API's
 > blocking?

Well, at least mthca is using it when posting WQEs to MLX QPs.  But it
could keep its own internal cache (which would be much simpler, and
easier to keep in sync since it sees all MADs that change the cache as
they go by).

If there are no other users for a non-blocking API then we could tear
out the whole caching mess and be much happier.

At least IPoIB and SRP seem like they could live without the cache,
with the addition of ib_find_pkey() and ib_find_gid() convenience
functions, and they're the only users in infiniband/ulp.
infiniband/core would take a little more auditing.

 - R.