[ewg] Re: pkey change handling patch

[Michael S. Tsirkin]

> 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/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 ?

Snooping MADs. provider can make sure it's synced wrt port events.

-- 
MST