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? I don't
see where this is prohibited, and we know that it works.
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. (Wow, I'm almost beginning to
sound like a Linux programmer now.) 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.
- Sean
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
