Hi Santosh, On Thu, 2014-04-10 at 14:24 +0530, santosh kulkarni wrote: > Hi Nab, > > On Tuesday 01 April 2014 01:03 AM, Nicholas A. Bellinger wrote: > > Hi Santosh, > > > > On Wed, 2014-03-26 at 12:11 +0530, santosh kulkarni wrote: > >> Hi Nab, > >> > >> I see that for NOPOUT requests, in scenarios where response for a > >> NOPOUT,the NOPIN gets dropped > >> before it reaches the initiator and you request a retransmission through > >> a Type 1 Status SNACK for that NOPIN. > >> What i see is that the target sends out a SCSI Response LUN (Op code > >> 0x21) instead of a NOPIN PDU. Is this an expected behaviour. > >> > > So the original assumption in iscsit_handle_status_snack() was that the > > initiator would only be requesting a status SNACK for ISCSI_OP_SCSI_CMD > > PDUs. > > > > Note the FIXME atop iscsit_handle_status_snack(): > > > > /* #warning FIXME: Status SNACK needs to be dependent on OPCODE!!! */ > > > > Generating a SCSI response for an NOP OUT is obviously wrong here, but > > I'm still undecided if it's worth supporting generating status for non > > ISCSI_OP_SCSI_CMD commands. > > > > That said, here is a quick work-around to only generate a SCSI response > > for ISCSI_OP_SCSI_CMD PDUs. > Am not receiving any SCSI response. > > > > Care to test..? > Sorry for the late reply.I did try the patch. > I was expecting the target to resend the NOPIN packet after sending the > Type 1 Status SNACK for NOPIN. No, that is not what the patch was intended to do. In current code, all PDUs regardless of type will (incorrectly) generate a ISCSI_OP_SCSI_CMD_RSP for a received Status SNACK . As mentioned above, the patch was intended as a work-around to prevent Status SNACKs for PDUs beside ISCSI_OP_SCSI_CMD from being processed. It's still unclear if it's worth it to add support for generating Status Snacks for non ISCSI_OP_SCSI_CMD type PDUs. > (Considering that the NOPIN was dropped before it reached the initiator) > Here's the dmesg. > > Dmesg : [ 46.366852] Unable to find StatSN: 0xd65d74a8 for a Status > SNACK, assuming this was a protactic SNACK for an untransmitted StatSN, > ignoring. > This is the expected behavior with the work-around patch in place. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
