"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote on 06/20/2007 11:20:29 PM:
> > Since SRQ is not a required function in the IB spec we never addressed that > > issue in the RFC along with UC. > > > > ... > > Since SRQ is almost transparent wire-protocol-wise, RFC probably does not have > to say anything about it. But I wonder why do you say this about UC which is > explicitly documented in the spec. > Looks like that was added in the last set of revisions. > > If you really want to start splitting up which layer has part of > the decision > > on how to connect, then you need to propose a totally different RFC. > > > > ... > > I hear an architect speaking :) Guilty as charged :=} > You seem to use the term layer in the OSI model sense, while Roland is just > speaking about code organisation. We haven't stopped developing ipoib, so > duplicating the controlling logic is a problem for us: both performance and > maintainance wise. Abstracting the SRQ/nonSRQ issue out, by > implementing a set > of functions that can work on top of either SRQ or a pool of QPs is > the proposed > solution. Still trying to understand why this is easier to maintain and performs better than the current patch. If this has to go in the drivers, then this has to be a part of the distros. Seems messy. > > -- > MST Bernie King-Smith IBM Corporation Server Group Cluster System Performance [EMAIL PROTECTED] (845)433-8483 Tie. 293-8483 or wombat2 on NOTES "We are not responsible for the world we are born into, only for the world we leave when we die. So we have to accept what has gone before us and work to change the only thing we can, -- The Future." William Shatner
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
