[Stgt-devel] More threads for device server

[Mike Christie]

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.