Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > >Multiple distinct mcmember_rec queries could get us the same mcast group. > >Say MTU > 256 and MTU > 512 look different but actually will get > >same group in practice. > > > >Say 2 clients ask for these 2 queries. > >What will be in the ib_sa_mcmember_rec in this case? > > The module currently does not handle queries in as complex a way as the SA. > The current matching is limited to equality comparisons against the local > mcmember record. (See cmp_rec() in multicast.c.) If there's a need to expand > the comparisons, that can be done.
Yes, I think supporting more queries is required in real world. For heterogenious clusters, it seems we already need something like IB_SA_LTE at least for the rate selector. It is somewhat unfortunate that we are duplicating the SA logic at the endnode in kernel memory here - current sa module has the advantage in that it just packs all data into a mad and sends it out. Something to think about. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
