|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI/iWARP drafts and flow controlAs I indicated to Caitlin in an earlier e-mail, since each iSCSI control-type PDU from the target to the initiator is associated with a StatSN, the ExpStatSN from the initiator can be used to advance the "credit" at the target. The question is for iSCSI control-type PDUs from the initiator to the target, what is the mechanism for the target to advance the "credit" at the initiator? For PDUs where the Immediate flag is not set, the CmdSN and MaxCmdSN mechanism in iSCSI are already available and the new "credit" scheme is not necessary. The unsolicited SCSI Data-out PDUs are covered by FirstBurstLength and again the new "credit" scheme is not needed. The "credit" scheme is needed for PDUs where the Immediate flag is set or the SNACK Request (note that SNACKs are not needed in iSER). For these PDUs, the target may not be able to advance the "credit" at the initiator individually. One possibility is to wait for the initiator to issue an iSCSI control-type PDU with a new CmdSN but without the Immediate flag, and if the target responds with an iSCSI control-type PDU with ExpCmdSN set to CmdSN + 1, then "credit" at the initiator is restored to its full negotiated (or by definition) value. As Caitlin pointed out, since no one has yet identified a specific need for per-session negotiation of these credits, a simple rule enumerated in the draft may be sufficient. Mike Ko IBM Almaden Research mako@almaden.ibm.com To: wrstuden@wasabisystems.com cc: Mike Ko <mako@almaden.ibm.com>, ips@ece.cmu.edu, rddp@ietf.org Subject: Re: iSCSI/iWARP drafts and flow control On Friday, August 15, 2003, at 04:12 PM, wrstuden@wasabisystems.com wrote: > Sorry for my delay in responding. > > One of the things I've been wondering through this whole thread is > can't > we expand iSCSI negotiation to handle these parameters (like how many > async messages are ok, how many immediate commands, etc.)? That way, to > the extent that iSCSI/iWARP needs new parameters, we can decide on them > out easily. > > Maybe it's been in everyone's thoughts, but the thread had been talking > about needing new limits and talking like it's hard to do. Can't we > just > negotiate them? > > Take care, > > Bill Bill, There are two separate issues. The first is establishing what the credit limits are. That could be negotiated on a per session basis, or it could be established by the draft as a simple rule. You are correct that negotiating is not terribly complex. Therefore, if there is *any* benefit to varying those limits on a per-session basis, then negotiations should be allowed. So far, however, I do not believe that anyone has identified a specific need for per-session negotiation of these credits. The second issue is the mechanism by which credits are replenished. The iSER draft authors were opposed to creation of additional messages to exchange credits. My contention is that under virtually all circumstances, credit replenishment can be inferred from existing message exchanges. Under worst case circumstances a "NOP" might have to be sent that would not have otherwise been required. No additional message types are required. I believe the last few prior exchanges may have established that tracking credits is not as onerous as the draft authors had originally thought. But it is on that issue, not the overhead of negotiation during setup, that was their concern. Caitlin Bestler - cait@asomi.com - http://asomi.com/
Home Last updated: Fri Aug 15 23:19:24 2003 12822 messages in chronological order |