[openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add ib_multicast module to track join requests from the same port

[Eitan Zahavi]

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
>>> openib-general at openib.org
>>> http://openib.org/mailman/listinfo/openib-general
>>>
>>> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>>>   
>>>       
>> _______________________________________________
>> openib-general mailing list
>> openib-general at openib.org
>> http://openib.org/mailman/listinfo/openib-general
>>
>> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>>
>>     
>
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>