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. > I don't see where this is prohibited, and we know that it works. It's not prohibited. I'm not sure there are many explicit compliances related to RMPP. > > I don't think the issue is gain but how to reverse the RMPP roles. When > > you say 2 individual sender initiated transfers, would they have the > > same transaction ID ? > > Yes. > > All we're trying to accomplish is reliable segmentation and reassembly. IMO, > the RMPP start-up scenarios are utter nonsense. The two one sided transfers still need to do those things so this is a general RMPP comment rather than a DS one. > (Wow, I'm almost beginning to sound like a Linux programmer now.) I think you qualify :-) > But given that its defined in the spec, and > SA GetMulti is defined to use it, let's limit its use to that method. > > >>If we want to support DS RMPP for more than just MultiPathRecord, it seems > >>that > >>we need some sort of class/method mapping, > > > > > > maybe attribute ID as well. > > > > > >> which would require changing the kernel MAD API. > > > > > > Yes unless this were somehow made self-identifying (part of the RMPP > > protocol rather than an internal state variable). > > If we're going to change the RMPP protocol, my vote is to remove DS RMPP > entirely, unless someone can show why the additional complexity is needed. There is backward compatibility at a minimum. I'm exploring more on this. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
