[ofa-general] Re: [PATCH 2/3] remove ib pkey gid and lmc cache

[Michael S. Tsirkin]

> Quoting Yosef Etigin <yosefe at voltaire.com>:
> Subject: Re: [PATCH 2/3] remove ib pkey gid and lmc cache
> 
> Michael S. Tsirkin wrote:
> >>Quoting Yosef Etigin <yosefe at voltaire.com>:
> >>Subject: Re: [PATCH 2/3] remove ib pkey gid and lmc cache
> >>
> >>Michael S. Tsirkin wrote:
> >>
> >>>>+ * ib_query_lmc() returns the LID mask control associated
> >>>>+ * with port @port_num
> >>>>+ */
> >>>>+int ib_query_lmc(struct ib_device *device, u8 port_num, u8 *lmc);
> >>>>+
> >>>
> >>>
> >>>I don't think we need this one in ib_verbs.h - it just does query_port once.
> >>>Let's keep the API simple. The only user is in mad.c - move
> >>>it there and make it static.
> >>>
> >>>
> >>
> >>why keep ib_query_lmc anyway if we won't use it?
> > 
> > 
> > Actually, I think I see a problem with changing
> > ib_get_cached_lmc -> ib_query_lmc: it is called on data path in mad.c.
> > Calling ib_query_port there will slow down MAD processing significantly,
> > because it's hard to driver to cache all of portinfo state
> > (e.g. how do you cache phys_state?).
> > 
> > But mad.c is actually seeing all MADs, too, so maybe the right thing
> > is to cache lmc directly there.
> > 
> So how about mad.c will use the cache for now (like mthca),
> and will have a lmc cache of its own after the cache is really removed?

OK I guess. But I wonder whether other changes might affect e.g.  connection
setup for other pieces, too.

We started by discussing a race condition with IPoIB.
So again, my suggestion for now (from archives) would be:

>  > - a patch to add ib_find_pkey() and ib_find_gid() to core
>  > - a patch to replace cache usage in IPoIB with uncached
>  >   hardware accesses on top of this
>  > - ipoib pkey change handling patch on top of these

Here's a link to discussion we had in April:
http://www.mail-archive.com/general@lists.openfabrics.org/msg01613.html

-- 
MST