Hal Rosenstock wrote: > On Wed, 2006-10-11 at 12:24, Eitan Zahavi wrote: > >> Sean Hefty wrote: >> >>> 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. >>> >>> >>> >> This is incorrect. The SA can track requests from multiple different >> QPs. It could actually also enforce using QP1 for the requests. But it >> can not differentiate requests from same port different applications >> comming on QP1... >> So if you did catch all QP1 traffic and refcount at that level you will >> be 100% clean. >> > > What about redirection ? > > The SA can redirect itself to any QP. But it can enforce Join/Leave to always use QP1. I do not see how redirection apply here. Also we could follow the InformInfo scheme were if a QP has registered the SA will track it and not Leave the group unless the last QP registered from a given port has left. So the hole we have today can be closed IFF we are able to catch and ref count all QP1 Join/Leave.
EZ > -- Hal > > >> >>>> 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 >>> >>> _______________________________________________ >>> openib-general mailing list >>> [email protected] >>> http://openib.org/mailman/listinfo/openib-general >>> >>> To unsubscribe, please visit >>> http://openib.org/mailman/listinfo/openib-general >>> >>> >> _______________________________________________ >> openib-general mailing list >> [email protected] >> http://openib.org/mailman/listinfo/openib-general >> >> To unsubscribe, please visit >> http://openib.org/mailman/listinfo/openib-general >> >> > > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
