[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