On Sat, 05 Mar 2005, [EMAIL PROTECTED] wrote: > In thinking this through a little further - if the workq is just > for the transport, the transport ought to simply create and use > the workq. There would be no need to modify the host structure. > > If we're trying to avoid the potential for several workq's on a > per-host basis (one by the transport, another by the LLDD, another > for ?) - the idea of one in the host is worth while. >
Yes, that was the general idea -- reduce the number of worker-threads contending for the same shost resource. In also thinking a bit more about this subject, I wonder if there are truly many other (useful) purposes for a generic 'deferred' work_q at the shost level, other than for scanning. There were some background tasks I shelved until the remote-ports stuff settled down which I thought could use the deferred processing thread: * Initiate LIP -- several customers have asked for this ability as several topological configurations isolate disruptive FC events. * Initiate LLDD rescan (i.e. ports (fibre channel), devices (iSCSI), etc.) I had originally envisioned these functions residing in the transport. > > However, it > should always be allocated and available. No "create" flag should > be needed. > Not to sure about that -- a large percentage of drivers would not (currently) benefit from having a deferred work_q created for each shost instance it registered. -- AV - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
