[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
mshefty at ichips.intel.com
Wed Oct 11 09:08:15 PDT 2006
Michael S. Tsirkin wrote:
> Why is this even a good idea?
> If you are looking for reasons using mutlicast module in ipoib is good, I would
> say blocking unpriviledged userspace from joining IPoIB GID and snoopig on all
> mcast traffic sounds like a better idea. BTW, Sean, I think this is something
> we need for the ucma multicast part to go in. I would imagine kernel components
> could set some kind of flag on mcast join to make them exclusive.
> API currently does not allow for that.
http://openib.org/pipermail/openib-general/2006-March/019147.html
Why is it a bad idea? The architecture allows this. However, none of the
proposed patches allows a userspace app to join an ipoib multicast group. And
an application that talks directly to the SA via MADs puts us no worse off than
before.
> And why the rush? Is the new module used at all yet?
> Let's see it get some use before switching a basic component over.
This module was added to svn in April. The request was to begin the process for
queuing it to 2.6.20, which is likely 2-3 more months out. I hardly call that a
rush.
> Finally, the patch in question also seems to introduce more cleanups and
> such. It would be less controversial if it was just an API change.
The cleanups are part of the change. Once ib_join_multicast() has been invoked,
ib_free_multicast() must be called exactly once. Proper state tracking for this
is required.
- Sean
More information about the general
mailing list