> Quoting Moni Levy <[EMAIL PROTECTED]>: > Subject: Re: pkey change handling patch > > On 4/26/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > >> Quoting Moni Levy <[EMAIL PROTECTED]>: > >> Subject: Re: pkey change handling patch > >> > >> On 4/25/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > >> > > >> >If you want to tackle more of the cache elimination plan we discussed > >> >that would be great though. > >> > > >> > >> One more issue I looked into that in my opinion needs to be discussed > >> is that we do not have an easy api that should provide us with the > >> whole PKEY table and one for the whole GID table for a specific port. > >> I know that ib_process_mad can be used it's just not user friendly. > >> The only thing we have now is ib_query_pkey that gets us one pkey from > >> a specific index and is implemented to get the 32 pkeys chunks under > >> the hood (and something similar for gids). Do we need something like > >> ib_get_pkey_table & ib_get_gid_table calls ? Just an interesting fact: > >> ib_cache_update on a Mellanox card performs 64 + 64 + 1 = 129 commands > >> instead the really needed 5 :) > > > >If the intended usage is to speed up ib_cache_update, the point is > >moot I think since we agreed we are getting rid of it. > > Do you suggest to implement ib_find_pkey & ib_find_gid by using > ib_process_mad ?
Oh, I see what you mean. Let's do it over query_pkey/query_port for now. Long term providers will just optimize these I think. -- 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
