Eitan Zahavi wrote: > I disagree. If you sniff at the MAD level you can simply react to the > lower level messages.
First, when designing this, I did consider using the MAD snooping ability, and changing what could be done with snooping. However, the multicast handling is not simply sniffing MADs going out on the wire and incrementing / decrementing some count. It can change or prevent a MAD from being sent. This is a fundamental change to the behavior of the ib_mad APIs. MADs are sent and tracked by their respective registered ib_mad clients. Trying to push this down into the MAD layer means that the send request from one client may now occur on some other client's registration. If that client decides to unregister in the middle of their send, the operation is canceled, and now needs to be restarted on some other registration. And even though the operation was canceled, we still need to know whether it was seen by the SA. This requires sniffing all MADs, and quickly gets extremely complex. In order to avoid issues these with which registered client is actually performing the operation, the solution is to filter multicast requests through a single registration. The ib_mad layer is complex enough as it is. (Have you tried tracing a MAD through the send path?) We don't need to push even more functionality down into it. - 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
