[ewg] Re: pkey change handling patch

[Moni Levy]

On 4/26/07, Michael S. Tsirkin <mst at dev.mellanox.co.il> wrote:
> > Quoting Moni Levy <monil at voltaire.com>:
> > Subject: Re: pkey change handling patch
> >
> > On 4/26/07, Michael S. Tsirkin <mst at dev.mellanox.co.il> wrote:
> > >> Quoting Moni Levy <monil at voltaire.com>:
> > >> Subject: Re: pkey change handling patch
> > >>
> > >> On 4/25/07, Roland Dreier <rdreier at cisco.com> 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.

How ? Caching at device driver level ?

>
>
> --
> MST
>