FUJITA Tomonori wrote: > On Wed, 21 Jan 2009 11:52:39 +0200 > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > >> Currently inherited from sg.c bsg will submit asynchronous request >> at the head-of-the-queue, (using "at_head" set in the call to >> blk_execute_rq_nowait()). This is bad in situation where we want >> to keep the queues full but need the requests to execute in order. > > As I wrote, I think that blk_execute_rq_nowait inserts a request and > plugs a queue. So how can you keep the queue full? On the completion > of blk_execute_rq_nowait, the queue is empty. If it's so then why does the "at_head" matters why does it exist? Let me say it this way, if it does not matter then could we just reverse it? you just said it does not matter, lets reverse it to be 0 and not 1. I don't understand what you are saying. bsg::write can accept an array of commands lets say I have this sequence in the array: command1:command2:command3 And for the sake of the argument lets say the hosts queue is full, has can_queue commands waiting response. Let say from other clients. if I use at_head==0, the target will surly see this sequence: command1:command2:command3 But if I use at_head==1, the way I read the code, the target will see" command3:command2:command1 and some times command1:command3:command2 or command2:command1:command3 It all depends on the random completions of the other commands in flight. This is the way I read the code, If I read it wrong, please explain what will be the actual behavior and what is the effect of at_head? Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
