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.(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.
PFA the pcap.
diff --git a/drivers/target/iscsi/iscsi_target_erl1.c b/drivers/target/iscsi/iscsi_target_erl index cda4d80..a65af25 100644 --- a/drivers/target/iscsi/iscsi_target_erl1.c +++ b/drivers/target/iscsi/iscsi_target_erl1.c @@ -524,6 +524,9 @@ int iscsit_handle_status_snack(spin_lock_bh(&conn->cmd_lock);list_for_each_entry(cmd, &conn->conn_cmd_list, i_conn_node) { + if (cmd->iscsi_opcode != ISCSI_OP_SCSI_CMD) + continue; + if (cmd->stat_sn == begrun) { found_cmd = 1; break;Also when i retry the NOPOUT with the same CmdSn the target is properly ignoring it as duplicate since it has properly responded to the previous NOPOUT.This is correct behavior. --nab
Regards Santosh
Attachment:
nopinSNACK
Description: Binary data
