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

[Sean Hefty]

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.

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.

> 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.

> 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.

- Sean