To be honest, we haven't been able to think of a case where a sender would use retries on a trap or a busy on a repress either, but I don't think it would hurt to omit represses from the busy handling either.
Would that be acceptable to everyone? To alter the patch to allow "BUSY" trap repress MADs to pass through? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Hal Rosenstock Sent: Thursday, June 17, 2010 9:30 AM To: Mike Heinz Cc: Hefty, Sean; [email protected]; Todd Rimmer Subject: Re: Handling busy responses from the SA Mike, On Wed, Jun 16, 2010 at 3:57 PM, Mike Heinz <[email protected]> wrote: > Hal, > > But if the original trap had retries > 0, wouldn't resending the trap be what > the issuer intended? I suppose as there's nothing in the IBA spec that precludes using busy on TrapRepresses although I'd be hard pressed to rationalize using that particularly for SMP traps. -- Hal > I guess I'm confused why treating BUSY as similar to simply never getting a > response at all is a bad thing. In my mind, receiving a BUSY response is like > getting a busy signal when you call someone on the phone - a sign you need to > wait a bit then try again. Similarly, if I call someone and never get an > answer my strategy is going to be to wait, then try again. > -----Original Message----- > From: Hal Rosenstock [mailto:[email protected]] > Sent: Tuesday, June 08, 2010 8:16 PM > To: Mike Heinz > Cc: Hefty, Sean; [email protected] > Subject: Re: Handling busy responses from the SA > > Mike, > > I'm referring to the receipt of the TrapRepress with busy status. > Wouldn't your patch cause the original Trap to be resent when retries >> 0 ? TrapRepress is essentially a response to Trap and classified as > such by ib_response_mad. Your proposed patch treats a busy as a > timeout and can cause retry of the original sent Trap. > > -- Hal > -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
