Sean Hefty wrote: > Eitan Zahavi wrote: > >> So if it is then there is no problem sniffing it and refcounting. >> > > The MADs cannot simply be sniffed and counted. MADs which affect the same > multicast group should not always be sent. Join operations must be > serialized > against leave operations, especially when the join/leave parameters differ. > But you did all that extra work in ib_multicast. You just need to attach it to EVERY SubnAdmin Set or Delete of MCMemberRecord. So the argument it is complicated does not mean you need to make it with a hole in it. The hold being the fact anybody can bypass it and the ref-counting will be broken. What is the point in providing the client the illusion of safety if eventually it does not work? > A join operation to an existing group may not result in a MAD being sent, so > no > response from the SA is available. The act of joining or leaving a multicast > group is distinct from sending a MAD. The appearance of a MAD on the wire is > not always necessary. > > Consider that pushing this functionality down into the MAD layer also results > in > pushing the related ib_sa functionality into the ib_mad module as well. > I disagree. If you sniff at the MAD level you can simply react to the lower level messages. > >> And there are other kernel level ULPs that use that IB_SA code and >> bypass ib_multicast >> > > There are no in tree users, which is my primary concern at the moment. The > ib_sa API still exists for out of tree users, but they will as broken as they > are today. > Consider gcc was asking to support only the code that is in some distribution. You build a broken architecture (one that fails to provide the functionality under all conditions) and hide behind not knowing the code that will break it. > >> Changing top API for ULPs and Clients is simpler to implement but >> provide wrong tradeoff for functionality that can be implemented under >> the hood - not burdening the rest of the world with a constant flux of >> API changes. >> > > I'm more concerned about getting the right API than trying to fit something > into > an existing API just because its there. My proposal is to have the following > layers: > > ib_mad - sends and receives MADs on QP0/1 > ib_sa - sends and receives MADs to the SA > ib_multicast - manages multicast joins > > The alternative proposal I keep hearing is to combine these 3 layers under > the > existing ib_mad API. However, the behavior of that API will change. > My proposal is of building a pluggable module that is below the ib_mad that tracks SubnAdmin.Set/Delete.MCMemberRecord and reacts accordingly:
ib_mad <-> ib_multicast ib_sa > - Sean > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
