[ofa-general] Re: [ewg] to be discussed at the developer conference

Or Gerlitz ogerlitz at voltaire.com
Tue Oct 30 00:52:15 PDT 2007


Sean Hefty wrote:
>> 7) the inform info code. Sean - you have implemented and attempted to 
>> push it through the sa caching push, but since the cache was rejected 
>> so did the inform info code. So the questions here - how do we make 
>> this push happen? are there any open issues, etc
> 
> There either needs to be an in kernel user, or we need to reach 
> agreement on the best way to expose this to userspace.  Neither this, 
> nor the multicast code are directly exported.

IB multicast send-only (NonMemberSendOnly in IB spec notation) joins is 
the user that can enable the merge of the inform-info code.

Specifically, the in-kernel user I suggest is the rdma-cm: enhance the 
librdmacm api to let the consumer specify that they want a "send-only" 
join, for such joins have the rdma-cm register to "GID IN" event on this 
group MGID and once such event happens, do the actual join on the group.

How does this sounds?

> I have seen e-mails on the list that event subscription is used by 
> userspace apps, but it is done via the MAD layer directly.

Other than having each such app inventing the wheel in their inform-info 
low level coding, this is bad, since there is no reference counting and 
one process doing unregister makes the second process never get events 
(or they also implemented a reference counting daemon...), anyway, I 
think we want your implementation in, and the question is how we do that.

Or.




More information about the general mailing list