[ofa-general] Re: pkey change handling patch
Michael S. Tsirkin
mst at dev.mellanox.co.il
Wed Apr 25 01:23:43 PDT 2007
> Quoting Moni Levy <monil at voltaire.com>:
> Subject: Re: pkey change handling patch
> On 4/19/07, Michael S. Tsirkin <mst at dev.mellanox.co.il> wrote:
> >> Quoting Roland Dreier <rdreier at cisco.com>:
> >> Subject: Re: pkey change handling patch
> >> > So since all this thread was started by Moni because of IPoIB,
> >> > the path is clear in that respect, and would already be a step in the
> >> > right direction:
> >> >
> >> > - a patch to add ib_find_pkey() and ib_find_gid() to core
> >> > - a patch to replace cache usage in IPoIB / SRP with uncached
> >> > hardware accesses on top of this
> >> > - pkey change handling patch on top of these
> >> Makes good sense to me.
> >OK, let's do this for starters. Moni?
> Before getting to the implementation phase, I would like to get your
> opinion on two more things:
> 1. Direct access in ib_find_pkey will probably heart RC connections
> per second rate.
I don't think this matters much for IPoIB CM (likely to be dwarfed by CM
handshake times). Long-term, I think providers can cache the pkey
(without coherency issues, since all events go through the provider)
> 2. What do you think about OrG's opinion (I'm copying it from the other
> So the only case which might be problematic with a patch that does not
> change the RC ULPs (and CM) code is when in the exact millisecond you
> set your RC connection the cache changes. I don't think the IB portion
> of the ULP code has to be changed other then sensing the ESTALE error
> and propagating it up. Higher layers would retry the connection and we
> are done.
One can argue about this, but since we decided we want to get rid of the cache,
the point is moot I think?
More information about the general