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
-~----------~----~----~----~------~----~------~--~---

Reply via email to