FUJITA Tomonori wrote: > Targets need to perform multiple SCSI commands at the same time. If we > use synchronous APIs, the work queue framework is not sufficient > because it cannot perform lots of SCSI commands simultaneously. Umm, I was just reccomending a work queue becuase you can create them either as a one thread per proc or a single threaded one. So if you like the work queue interface you can just create a bunch of single-threaded-workqueuues instead of creating a bunch of threads. > > There are two options: we need to create lots of kernel threads > calling kthread_create several times (like IET) or we need to use > asynchronous APIs with the work queue framework. Are you creating a thread per command that can get queued or how do you determine how many threads? I don't think that > having lots of kernel threads is so bad, though it makes the stgt code > complicated and dirty a bit. So I'll try AIO later with work queue per > target. Work queue per device is not necessary, though it fit for > SAM-3 theoretically. ok then. > > > The last topic is that how to prevent a device from being removed (by > an user) while it has active I/O operations. There are many ways to do > that. I was just thought about things like the following. > > stgt_device_destory() sets DEVICE_DEL bit (device->state). It prevents > queuecommand from putting new commands to the device. Then, > stgt_device_destory() calls flush_workqueue() to wait all commands to > finish and then frees the resources. That sounds about right. We also will have to deal with people suddenly removing targets too. I mean someone just yanking the controller from the box :) We are going to have to do some more lifetime management for this. |