[openib-general] Some Missing Features from mthca/user MADacc ess

[Hal Rosenstock]

On Tue, 2005-01-11 at 05:59, Eitan Zahavi wrote:
> [EZ]: The IBADM specification does not require the SA to be the same
> application/program as the SM. But it does require that ServiceRecords
> be handled by the SA.

Not sure what the relevance of IBADM is here nor the use of
application/program. IBA (IB architecture), which is what I think is
relevant here, allows SA requests to be redirected from the SMLID which
effectively accomplishes the end result you mention. 

I do not know the requirements of IBADM in terms of the MAD layer but am
interested in learning...

> [EZ] Another thought. I hope there is no assumption in the code that
> only one application can register for receiving "un-solicited" MADs of
> specific class,method,attribute triplet . 

There currently is. This is method based filtering (and includes class
and class version) but not attribute.

> Consider the case of using InformInfo for receiving Reports from the
> SM on critical changes in the subnet. Unless you allow each one of the
> applications to register for receiving these "un-solicited" MADs you
> will end up writing a kernel module and invent a new API for
> registering single clients.

I see your point. (I do not believe) there is currently a way to
accomplish delivering a Report/Trap (subscribed to by multiple clients)
to those multiple consumers (some which may be in the kernel and others
in user space). 

Sean's email yesterday mentioned a possible solution for user space but
I'm not sure this is sufficient as there could be kernel clients for
this as well.

In my mind, this is somewhat similar to some of the PortInfo changes
except that these events don't go to all consumers so the event
mechanism is probably not appropriate.

If no one else has other better alternatives, it looks to me like
attribute based filtering needs to be added for this plus the delivery
of a single received MAD to multiple clients :-(

-- Hal