> Quoting Moni Levy <[EMAIL PROTECTED]>:
> Subject: Re: pkey change handling patch
>
> On 4/19/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> >> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> >> 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
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
