> Quoting Roland Dreier <[EMAIL PROTECTED]>: > 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 _______________________________________________ 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
