Re: [Scst-devel] Fwd: Re: linuxcon 2010...

[Vladislav Bolkhovitin <vst@vlnb.net>]

Bart Van Assche, on 09/07/2010 10:45 AM wrote:
> On Tue, Sep 7, 2010 at 8:29 AM, Hannes Reinecke<hare@suse.de>  wrote:
>>
>> Bart Van Assche wrote:
>> [ ... ]
>>> You seem to have missed the start of this thread. The design of SCST
>>> is significantly more advanced than that of LIO, and it has already
>>> been explained in this thread why
>>> (http://www.spinics.net/lists/linux-scsi/msg45856.html).
>>>
>> Hmm. That link seems to be misrouted. I was hoping for a design
>> overview of SCST there; however it's just a complain to
>> James Bottomley etc.
>>
>> Care to send the correct link?
>
> An SCST design overview diagram together with SCST API documentation
> can be found here: http://scst.sourceforge.net/scst_pg.html (sorry for
> the language imperfections on this page, which should not affect
> readability though).

For iSCSI-like transports, which support immediate/unsolicited data, 
additional description of the processing flow is here.

In short, in this flow target drivers called by the SCST core 
(preprocessing_done() callback) after preprocessing of this command 
finished and the command has allocated buffer, so now the driver can 
continue processing of the command and transfer in its buffer 
immediate/unsolicited data, if there are any.

In details it is as the following:

After iSCSI-SCST received new command in scsi_cmnd_start() it calls 
scst_rx_cmd() to create scst_cmd then after it initialized necessary 
fields in it (CDB, task attribute, expected data direction, etc.) it 
calls scst_cmd_init_stage1_done() to notify SCST that scst_cmd 
initialization finished and its processing can be started. Then SCST 
parses SCSI CDB to determines data transfer length and direction (this 
is necessary to prevent various DoS'es from remote initiators like 
sending a command with wrong data direction; try this in the 
pass-through case and you will see what happens) and allocates necessary 
data buffer. From this point the following 2 scenarios are possible:

1. Regular path, when SCST does all the processing directly as simple 
function calls. SCST in the end of processing calls 
iscsi_preprocessing_done() callback, which sets scst_state and returns. 
Following the call stack the execution flow will return to 
scsi_cmnd_start() and continue there.

2. During processing SCST has to change context (switch to another 
thread). It can be necessary, e.g., to handle some management activity. 
Here everything is the same as in (1) above, but after 
scst_cmd_init_stage1_done() returned scsi_cmnd_start() returns 1 and 
further processing of this connection is suspended. Then 
iscsi_preprocessing_done() will resume it. Then process_read_io() will 
call cmnd_rx_continue().

Then iSCSI-SCST will do necessary checks and if all correct:

   - For READ commands and commands without data transfers, calls in 
iscsi_restart_cmnd() scst_restart_cmd() to tell SCST to start command's 
execution.

   - Fro WRITE commands it receives immediate data, sends the necessary 
R2T PDUs (send_r2t()), receives data for them and then calls 
scst_restart_cmd().

Then, after the command is finished, SCST returns to iSCSI-SCST status 
of the command's execution in iscsi_xmit_response() callback, which 
using send_data_rsp() makes the necessary Data-In PDUs and then either 
directly sends them using iscsi_try_local_processing()->iscsi_send() (to 
minimize latency) or passes to the write thread.

Other internal SCST processing is as shown on the "The commands 
processing flow" in http://scst.sourceforge.net/scst_pg.html.

Thanks,
Vlad