RE: Data in SCSI Response or SCSI Data

["Y P Cheng" <ycheng@advansys.com>]

Matt, I see your point in software implementation.  May be this is a good
time to introduce the concept of "Good Status" flag bit.  In fact, 99.99% of
iSCSI reads should be completed without error.  For the normal completions,
all we need to is a flag bit in the data packet message header indicating
"Everything is OK. This SCSI read is now completed normally."  If this flag
bit is not set, there will be a status packet with sense data following.  In
the hardware implementation, after transferring data packet into the buffer,
if this flag bit is set, we interrupt the microcode which post the Request
Block (RB) completion interrupt to the device driver.  If the bit is not
set, the hardware does nothing after data transfer.  The status packet
arrived later will be passed to the microcode that, in turn, generates a
proper RB completion interrupt to pass the error information to the device
driver.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Matthew Jacob
Sent: Thursday, August 24, 2000 5:08 PM
To: csapuntz@cisco.com
Cc: 'ips@ece.cmu.edu'
Subject: Re: Data in SCSI Response or SCSI Data

That's a fair point. In other contexts (FC in this case), I've really liked
being able (in target mode) to send back data && status in packet- it means
I
don't have to manage multiple resources on the send side, and in the case of
sending back canned data for 'trivial' commands (like Mode data), I don't
even
have to do a context or thread switch.

What this might like like in an IPS implementation is not clear to me, but I
believe I do see the point about the h/w implementation issues.

It's not clear to me that you can state as a general rule that two packets
back-to-back is minimally different- not from a performance point of view,
but
from a likelihood of lossage and retransmit. If a high proportion of your
trivial (or not so trivial) read commands come back in one frame, that's a
lot
better than managing lost frames, no?

-matt