Re: [PATCH 00/11] New Caching mechanism for ib_core

Goldwyn Rodrigues
2011-11-10T04:20:29Z

On Wed, Nov 09, 2011 at 03:12:04PM +0000, Hefty, Sean wrote:
> > > > 1. Greater degree of control by individual drivers. Drivers have a
> > > > choice to use it or not.
> > >
> > > I believe that some callers need to know that specific query calls will not
> > sleep. That capability should either be required or exposed through the API.
> >
> > The new cache access functions do not sleep. This is the primary
> > objective of the exercise. See motviation 2 :)
> > Exceptions are the init functions which may sleep because of kzalloc().
> > Did you want me to mention this specifically in the comments?
>
> Yes, but the use of the cache is hidden from the user.

user who?

> Currently calls like ib_query_gid() are allowed to sleep. If drivers are given the choice whether or not to use the cache, then there's no way for a user to know whether a query call will sleep or not.
>

The cache calls do not sleep. Period.
AFAIK, the problem is with assuming calls do not sleep, when they
actually do and not vice versa.

What problems do you forsee if we declare that cache calls do not sleep?

Since the drivers would be users of cache calls, the behavior would be
as assumed for the query calls for the driver. Refer mthca
implementation (PATCH 11/11): If the entry is found in cache, it
will return immediately, and will not sleep. If the entry is not
found, it will query the device and may sleep. In essence we still
hold that the query functions may sleep, but if the data is available
in cache it will return faster.