Hi Todd, On Tue, 2006-04-11 at 13:15, Rimmer, Todd wrote: > I haven't been watching this thread so I might be missing the point. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Hal Rosenstock > > Sent: Tuesday, April 11, 2006 12:48 PM > > > > On Tue, 2006-04-11 at 12:38, Sean Hefty wrote: > > > Hal Rosenstock wrote: > > > > I don't think that can work. If the request and response > > are RMPP'd, I > > > > think a direction switch is needed so this can't be done. > > > > > > A direction switch is only needed if we want to follow the > > DS RMPP protocol. > > > Why can't both sides just follow the sender-initiated > > protocol instead? > > > > In thinking about this a little, I see no reason this > > couldn't work. In > > fact, that's one mode I have toyed with (a non conformant SA GetMulti* > > mode) in developing SA MultiPathRecord. > > It is a bad idea to implement a custom double sided approach. This will > suddenly create various compliance and interop issues. For example > Windows Open Fabrics and Linux OpenSM might not interoperate. Not to > mention other OSs (such as Solaris) which have their own IB stacks.
Understood. All I said was I used this as a development vehicle. It is not intended to be checked into the tree. > More interestingly, it is very likely that most uses of getmulti would > involve a requestor providing a request which would fit into a single > MAD packet and the RMPP protocol would not be fully needed by the > sender (eg. just the simple case of a single packet RMPP transfer > by sender with a multipacket RMPP response). Right. > You will note up to 10 > GIDs can fit in the request within a single packet. The most common > uses will probably involve 2 source GIDs and 2 destination GIDs. Yes. > Hence perhaps the complexity of a compliant double sided solution > could even be avoided for now. You lost me here. What do you have in mind ? -- Hal > Todd Rimmer _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
