iscsi: Use ICL_NOCOPY for SCSI command immediate data and R2T.

[jhb]

Summary

The associated csio ccb will not be completed via xpt_done() until
after the associated PDUs are transmitted to the other side and either
the original PDU is acked with a SCSI response, or a response is
received for a subsequent abort CCB (which means the earlier PDU has
also been sent since it would have been sent before the abort PDU).

This does assume that once an I/O request has been aborted, no further
PDUs with data payload are queued for that I/O request.

[mav]

I was thinking about it, but haven't done because network stack may hold the mbuf reference for a while after transmission, while that mbuf point to already freed I/O memory. In case of initiator, unlike target, we can't keep the memory allocated until the callback is called. Can stack decide to do some re-transmission, or something, re-reading the data again? Though may be I am too conservative and it is fine.

[jhb]

In D34405#779480, @mav wrote:

I was thinking about it, but haven't done because network stack may hold the mbuf reference for a while after transmission, while that mbuf point to already freed I/O memory. In case of initiator, unlike target, we can't keep the memory allocated until the callback is called. Can stack decide to do some re-transmission, or something, re-reading the data again? Though may be I am too conservative and it is fine.

I think for retransmit it would mean that the other end hasn't yet received all of the PDU and thus hasn't sent any reply (whether a successful completion or an abort). That is, the partially received PDU would still be down in TCP and not handed up to the iSCSI Target code to parse the PDU, and we only xpt_done the csio which would release the buffer when handling a reply.