[ofa-general] Re: pkey change handling patch

[Michael S. Tsirkin]

> 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)
if necessary.

> 2. What do you think about OrG's opinion (I'm copying it from the other 
> thread):

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

-- 
MST