, Sean; linux-rdma@vger.kernel.org
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
Heinz
Cc: Hefty, Sean; linux-rdma@vger.kernel.org
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
To: Mike Heinz
Cc: Hefty, Sean; linux-rdma@vger.kernel.org
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
Mike,
On Mon, Jun 7, 2010 at 12:00 PM, Mike Heinz michael.he...@qlogic.com wrote:
Hal said:
Should a busy be retried at all at the mad layer ? Is a special longer)
timeout policy for busy needed ?
Also, should this be done for all MADs classified by ib_response_mad (e.g.
trap represses) ?
As for needing a longer timeout - in our old proprietary stack, QLogic did
have a longer timeout for retrying busy replies than for normal timeouts -
but we should try to get this in now so we can get some relief before we
begin the long term discussion of the best way to handle this issue
Sean said,
Because applications may handle BUSY replies differently, we shouldn't simply
start hiding them from the user.
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
Subject: RE: Handling busy responses from the SA
N�r��y���b�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j
��f���h���z� �w���
���j:+v���w�j�m
zZ+�ݢj��!�i
Anyone know why my messages are being appended with interesting garbage?
I get that too. I first noticed it a couple of weeks ago. It eventually went
back to the normal 'To unsubscribe from this list' message.
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
Right. Effectively this is similar to the I/O resolution timeout policy laid
out in the spec.
-Original Message-
From: Hefty, Sean [mailto:sean.he...@intel.com]
Sent: Tuesday, June 08, 2010 12:27 PM
To: Mike Heinz; Hal Rosenstock
Cc: linux-rdma@vger.kernel.org
Subject: RE: Handling busy
: Handling busy responses from the SA
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
Is there case where we would ever want to treat BUSY responses differently
from timeouts?
I doubt it for a single MAD, but I can't say what people may have implemented.
The main difference I can think of is that a busy response requires a retry,
whereas a timeout does not. This affects the
On Tue, Jun 8, 2010 at 12:27 PM, Hefty, Sean sean.he...@intel.com 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
.
-Original Message-
From: Hal Rosenstock [mailto:hal.rosenst...@gmail.com]
Sent: Tuesday, June 08, 2010 3:09 PM
To: Hefty, Sean
Cc: Mike Heinz; linux-rdma@vger.kernel.org
Subject: Re: Handling busy responses from the SA
On Tue, Jun 8, 2010 at 12:27 PM, Hefty, Sean sean.he...@intel.com
Is there case where we would ever want to treat BUSY responses
differently from timeouts?
If there isn't then it's silly for the SA to ever send a BUSY response.
- R.
--
Roland Dreier rola...@cisco.com || For corporate legal information go to:
@vger.kernel.org
Subject: Re: Handling busy responses from the SA
On Tue, Jun 8, 2010 at 12:27 PM, Hefty, Sean sean.he...@intel.com 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
Hal said:
Should a busy be retried at all at the mad layer ? Is a special longer)
timeout policy for busy needed ?
Also, should this be done for all MADs classified by ib_response_mad (e.g. trap
represses) ?
Hal,
The idea of processing BUSY responses in the MAD layer is to BUSY responses
17 matches
Mail list logo
