Mike Christie wrote:
> On 08/14/2009 01:42 AM, Hannes Reinecke wrote:
>> Mike Christie wrote:
>>> Hannes Reinecke wrote:
>>>> Whenever we send a Data-Out response to an affected LUN during
>>>> LU Reset, we should be setting the 'FINAL' bit. This will
>>>> indicate to the target that we consider this transfer finished.
>>>>
>>>> Signed-off-by: Hannes Reinecke<h...@suse.de>
>>>> ---
>>>> drivers/scsi/libiscsi.c | 4 ++++
>>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>>>> index a0d1217..16d35f0 100644
>>>> --- a/drivers/scsi/libiscsi.c
>>>> +++ b/drivers/scsi/libiscsi.c
>>>> @@ -321,6 +321,10 @@ static int iscsi_check_tmf_restrictions(struct
>>>> iscsi_task *task, int opcode)
>>>> task->itt, task->hdr_itt, hdr_lun);
>>>> return -EACCES;
>>>> }
>>>> + /*
>>>> + * Set FINAL flag to terminate data transfer.
>>>> + */
>>>> + task->hdr->flags |= ISCSI_FLAG_CMD_FINAL;
>>> Wasn't this in the first patch before?
>>>
>> Yes. But I split it off as it's a different issue.
>> And this one apparently requires more discussion :-)
>>
>>> The data-out hdr is not prepd yet. The entire thing gets memset'd, so
>>> ORing it does not help.
>>>
>> Yes, and no.
>> We're hitting this section for Data-Out PDUs only, ie for tasks on the
>> 'requeue' list. All other tasks (for which iscsi_prep_scsi_cmd() would
>> be called) are filtered out here:
>>
>> if (opcode != ISCSI_OP_SCSI_DATA_OUT) {
>> iscsi_conn_printk(KERN_INFO, conn,
>>
>> as 'opcode' is the parameter passed during invocation, not the actual
>> opcode of the task.
>> So the 'FINAL' bit will only be set when we're here:
>
> Yes, it is set there at this time, but we have to prep the data-out pdus
> still.
>
>
>> list_for_each_entry_safe(task, tmptask,&conn->requeue, running) {
>> /*
>> * we always do fastlogout - conn stop code will clean up.
>> */
>> if (conn->session->state == ISCSI_STATE_LOGGING_OUT)
>> break;
>>
>> if (iscsi_check_tmf_restrictions(task, ISCSI_OP_SCSI_DATA_OUT))
>> continue;
>>
>> conn->task = task;
>> list_del_init(&conn->task->running);
>> if (conn->task->state == ISCSI_TASK_PENDING)
>> conn->task->state = ISCSI_TASK_RUNNING;
>> if (conn->conn_debug)
>> iscsi_conn_printk(KERN_INFO, conn,
>> "requeue cmdpdu [itt 0x%x cmdsn %u "
>> "lun %u] xmit\n", conn->task->itt,
>> be32_to_cpu(conn->task->cmdsn),
>> conn->task->sc ?
>> conn->task->sc->device->lun : -1);
>> rc = iscsi_xmit_task(conn);
>>
>> and there we don't do any header prep()ing.
>>
>
>
> We actually do. We have to prep the data-out pdu/s that get sent. For
> tasks on the requeue list the iscsi_xmit_task above we do:
>
[ Quite detailed explanation skipped ]
>
> You know too, unless this is actually helping your target or any target,
> you can probably bury this on the TODO list.
>
<a big Aah>
Thanks for the explanation. This was really the missing bit
of information. Until now the R2T transfer code was really a bit
of mystery for me.
Thanks again. So yes, your objections are correct. And we probably
should shelf the 'FINAL' bit on the TODO list; it's going to be
more protracted than originally thought.
So a separate patch was a good idea after all :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
