One advantage of having shared objects is to be able to preserve IB  connections across process restarts. If the traffic is not very high  and the buffers are in shared memory (which I think should be), then it can save connection setup and message recovery time.

<br><br>Shouldn't the protocol to create and destroy and pass the various <br>IB objects around be decided by the specific application rather than<br>the library trying to solve this problem?<br><br>Thanks<br>Ganesh<br>

<br><div><span class="gmail_quote">On 6/26/07, <b class="gmail_sendername">Roland Dreier</b> <<a href="mailto:rdreier@cisco.com">rdreier@cisco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

 > This is not directly related to SRC: this is an effort<br> > to make it possible to share QPs, CQ etc across processes<br> > in the same way as they can be currently shared across threads.<br> > So assuming that we want multiple processes to post to

<br> > the same QP, how can we support this?<br><br>This looks like a lot of work for an unknown gain.  Who is going to<br>really use this?  ie is it worth the trouble?<br><br> > >  - Given that everything shared is in shared memory,

>  > I think we should try and keep shared memory usage to minimum.  > For example, in mthca mr object just needs a key: we could  > keep it in non-shared memory, just pass the key around  > and save on sahred memory usage.

<br><br>This comment made me realize there are a few more problems here.  What<br>happens if I do ibv_reg_mr() in one process, pass the MR to another<br>process, and then do ibv_dereg_mr() in the second process?  What about

<br>if someone registers a region in shared memory -- are there any<br>fork/copy-on-write issues with that?  I think there are probably bugs<br>in the locked_vm accounting in the kernel right now -- it doesn't take<br>

into account the possibility of passing context fds from one process<br>to another.<br><br>In general what do you think the rules for destroying objects should<br>be?  What if process A creates a QP, passes it to process B, and then

<br>process A dies?  Should the QP still be usable?  Should process B be<br>able to destroy it?  What if process A is still alive -- should<br>process B be able to destroy the QP?<br><br> > We need to share file descriptors too. Is there a way to pass these

<br> > around besides unix domain sockets?<br><br>I guess we need this to be able to re-mmap doorbell pages etc, right?<br>I wonder if there's a better way around that... maybe extending the<br>kernel interface so that unrelated processes can share a context, eg

<br>by putting contexts in a filesystem or something like that.<br><br> > But are you sure we want to break API for all users just to add<br> > a new capability for a minority that wants shared memory support?<br><br>

Yes, you're right... better to be backward compatible and have a new<br>API for shared stuff.<br><br> - R.<br>_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openfabrics.org">

general@lists.openfabrics.org</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br><br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">

http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br>