[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