[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 eitan at mellanox.co.il
Wed Oct 11 13:11:46 PDT 2006


Sean Hefty wrote:
> Eitan Zahavi wrote:
>   
>> User level code can be run by root. It can access QP1 and bypass your nice
>> API. Also you ignore current kernel implementations that exist and already 
>> perform QP1 access via the SA client code in the kernel.
>>     
>
> Yep - and that same app can, today, delete the multicast groups used by ipoib. 
> As long as a MAD can actually be sent out of QP1, we have this problem.
>   
How is the MAD sent by QP1 ? QP1 is owned by the mad.c isn't it???
So if it is then there is no problem sniffing it and refcounting.
> The existing APIs were not ignored.  The ib_multicast module makes direct calls 
> to ib_sa.
>   
And there are other kernel level ULPs that use that IB_SA code and 
bypass ib_multicast
>   
>> No you are forcing every kernel client out there to do another unneeded 
>> migration to the new API and still not protect it correctly against multicast
>> disconnects.
>>     
>
> There's exactly 1 kernel client that uses multicast groups, and a patch was 
> provided to migrate that client.
>   
1 that you know about. Others did not make it into the kernel but are 
quite productive to those running them.
Changing top API for ULPs and Clients is simpler to implement but 
provide wrong tradeoff for functionality that can be implemented under 
the hood - not burdening the rest of the world with a constant flux of 
API changes.
> - 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
>   





More information about the general mailing list