[ofa-general] Re: pkey change handling patch

[Michael S. Tsirkin]

> Quoting Roland Dreier <rdreier at cisco.com>:
> Subject: Re: pkey change handling patch
> 
>  > So, this all turned out looking much more hairy than I thought it would be.
>  > Maybe option 1 is better? How about adding new types of events, and
>  > generating them once cache has been updated?
> 
> Well, I had another idea that I've been meaning to post.  How about
> adding a can_block flag to the methods query the cache.

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.

> If can_block
> is set, just wait for the cache to be up-to-date, and if it is not
> set, then return ESTALE (or maybe EAGAIN to match non-blocking file
> methods even more closely).

API-wise, I like having "try" (e.g. down_trylock) non-blocking functions
better than yet another flag. E.g. ib_tryget_cached_gid?

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?

> That forces us to think about every use of the cache queries, but I'm
> not sure that's a bad think.

Well, for the blocking case this is OK I think.

However, I now think that for the non-blocking case (if we implement it),
relying on timed retry from ULP is lame - we actually know when cache's up to
date, why force ULPs to jump through hoops to guess? Let's send them an event.

-- 
MST