[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port

[Eitan Zahavi]

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
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>