Mike, On Tue, Jun 8, 2010 at 3:59 PM, Mike Heinz <[email protected]> wrote: > Hal, > > I may be confused - but I thought the spec said there was no valid response > to a trap repress. I interpreted > > "o14-3.a4: The SMA shall not send any message in response to a valid > SubnTrapRepress() message" > > to mean that the SMA isn't allowed to respond with a BUSY status for a trap > repress.
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 > > -----Original Message----- > From: Hal Rosenstock [mailto:[email protected]] > Sent: Tuesday, June 08, 2010 3:09 PM > To: Hefty, Sean > Cc: Mike Heinz; [email protected] > Subject: Re: Handling busy responses from the SA > > On Tue, Jun 8, 2010 at 12:27 PM, Hefty, Sean <[email protected]> wrote: >>> Sean - remember that this patch will still return a BUSY status to the >>> caller, if retries are exhausted and the last return code was BUSY, then >>> that's what the caller will get. Thus, code which sets retries to zero will >>> not be affected by this patch at all. >> >> It looks like it only returns the BUSY response if that matches with the >> last retry, otherwise, the BUSY response is dropped. It also looks like it >> applies to all MADs, including vendor specific ones, and not just those from >> the SA. > > Per the proposed patch, it currently includes trap represses (as > determined by ib_response_mad). Shouldn't busy be ignored for that > case ? I don't think that would be used but it seems safer to me. > > -- Hal > >> >> - Sean >> > -- 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
