From: Vladislav B. <vs...@vl...> - 2005-11-18 11:22:33
|
Ming Zhang wrote: > On Thu, 2005-11-17 at 21:21 +0300, Vladislav Bolkhovitin wrote: > >>Ming Zhang wrote: >> >>>what i mean is when a scsi command received, it is sent to middle layer, >>>do this unplug, executed by scsi device, respond back to initiator. then >> >>Well, why do you think "then"? An initiator doesn't have to wait the >>command's completition in order to send the next one. > > > for disk, this is not true. but for tape device, it will be true i > think. ?? >>>next scsi command come in. so scsi cmd is serially executed from >>>initiator point of view. >>> >>>if we have initiator, scst box, scsi storage array, then this scst box >>>is like a bridge box while serialize all scsi traffic. >>> >>>maybe i understand something wrong. >> >>Looks like you should check what "plugging" means. > > > guess so. could u explain a bit? thanks. > > my understanding is that unplug will release the queue and began to > execute, while code will not wait i think. so this is different from > scsi_wait_req(). Seems, that's correct, although scsi_wait_req()/scsi_req_req() is, basically, orthogonal to the "plugging". The code will not wait in any case, even without doing unplugging > ming > > >>>Ming >>> >>>On Thu, 2005-11-17 at 19:57 +0300, Vladislav Bolkhovitin wrote: >>> >>> >>>>Hm, I don't see in any of those 2 places a "synchronousation" point. >>>>Both putting scsi cmd in the queue and generic_unplug_device() are >>>>asynchronous. So, what is the question? >>>> >>>>Vlad >>>> >>>>Ming Zhang wrote: >>>> >>>> >>>>>Hi folks >>>>> >>>>>I wonder how scst maintain the speed if it act as a bridge like device. >>>>>In scst_send_to_midlev(), it calls scst_do_send_to_midlev() to put scsi >>>>>cmd in the queue, then it will call generic_unplug_device() to execute >>>>>the queue. So will all scsi command sent from initiator side will be >>>>>executed one by one in a synchronous way? if so, will the speed be >>>>>greatly reduced? >>>>> >>>>> >>>>> >>>>>Ming |