On Mon, 2004-11-15 at 16:36, Sean Hefty wrote: > Hal Rosenstock wrote: > > > After Roland's query this AM, I am looking at this some more: > > > > On Wed, 2004-11-10 at 13:43, Sean Hefty wrote: > > > >>The second case where I can see this happening is if the client canceled > >>the send, and I'm not sure that we'd want to give the client an > >>unmatched response in this case. > > > > > > So do we just keep the cancel around for some time period to make sure > > this doesn't occur ? If so, should cancel also have its own timeout or > > should some arbitrary timeout be used to handle this case ? > > My personal take would be to avoid adding that complexity. E.g. a > client sends a MAD with TID 5, cancels 5, sends 5, cancels 5, sends 5. > A response is now received. What should the MAD layer do? > I don't see issues with silently dropping any MAD that we're not ready > to receive.
What does "ready to receive" mean in this context ? Does it mean there is no matching send if it is a solicited response ? > For unsolicited MADs, I don't see a reasonable alternative. Not sure what you mean by alternative for unsolicited MADs. For unsolicited MADs, there is only the version/class/method based routing. If there is no client, the receive is dropped. > For solicited (response) MADs, I have a hard time seeing why a client > would ever want an unmatched MAD, unless they're trying to duplicate MAD > layer functionality higher in the stack. Yes, I too would view this as a duplication of MAD layer services. > For user-mode, this may make sense, but I'm not convinced that duplicating > the request-response > functionality in user-mode is the best option (versus moving all of RMPP > to user-mode). What functionality are you referring to being duplicated ? Request/response matching with timeouts ? Wouldn't moving RMPP to user mode be a duplication ? There are certain things in the kernel that might want to use RMPP. > For the sourceforge stack, we handled this by defining "raw" MAD > services that did nothing other than send/receive MADs. Clients using a > raw service were responsible for performing RMPP, request/response > matching, and handling timeouts. This worked, but the MAD layer still > needed to route received MADs to the correct client. Yes, but there are two types of routing: TID based and version/class/method based. -- 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
