[RFC] adding per scsi-host workqueues for defered processing

[RFC] adding per scsi-host workqueues for defered processing

[Andrew Vasquez]

Following discussions which resulted from the:

[RFC] target code updates to support scanned targets
http://marc.theaimsgroup.com/?l=linux-scsi&m=110850749515984&w=2

thread, the overall consensus seems to be that transport-classes
should support a 'true-hotplug' mechanism of device discovery and
removal (this involves both registration and lun-scanning).  In order
to facilitate this ability and to not constrain the LLDD from the
typical restrictions of the storage scanning process:

* must be done from process context -- depending on transport type,
  discovery can occur from a non-process context
* potentially _long_ scan times -- even if discovery is done from a
  'sleeping' capable context, halting a LLDD for discovery purposes
  is typically undesirable.

I'd like to propose the addition of a per-Scsi_Host work-queue to
manage these scanning as well as any other (relevant)
lower-level-driver differed requests.

The attached patch adds:

1) a new scsi-host template member 'create_work_queue' which when set
   will create a single-threaded (the per-CPU option seemed too
   heavyweight) work-queue.
2) an exported helper function scsi_queue_work() to queue the work to
   the scsi-host work-queue.

the interface was kept flexible -- queuing of a work_struct object
rather than adding small wrapper functions to perform distinct
operations (i.e. scsi_scan_target_deferred(...), etc) so that any
'deferred' action could be requested by a transport-class or LLDD.

Example usage:

  scsi_transport_fc.h:

	struct fc_rport {
		...
	
		struct work_struct scan_work;
	} __attribute__((aligned(sizeof(unsigned long))));

  scsi_transport_fc.c:

	...	
	static void fc_scan_rport_work(void *data)
	{
		struct fc_rport *rport = (struct fc_rport *)data;

		scsi_scan_target(&rport->dev, rport->channel,
			rport->scsi_target_id, SCAN_WILD_CARD, 0);
	}	

	struct fc_rport *
	fc_create_rport(struct Scsi_Host *shost, int channel,
		struct fc_rport_identifiers  *ids)
	{
		...
		INIT_WORK(&rport->scan_work,
			fc_scan_rport_work, rport);
		...

	
	void
	fc_remote_port_unblock(struct fc_rport *rport)
	{
		struct Scsi_Host *shost = rport_to_shost(rport);
		...
		if (rport->port_state == FC_PORTSTATE_OFFLINE)
			/* Initiate a full rescan, as all
			 * scsi_target objects have been previously
			 * torn-down. */
			scsi_queue_work(shost, &rport->scan_work);
		else
			scsi_target_unblock(&rport->dev);

Anyway, comments?

--
Andrew Vasquez

===== drivers/scsi/hosts.c 1.107 vs edited =====
--- 1.107/drivers/scsi/hosts.c	2005-01-18 11:15:06 -08:00
+++ edited/drivers/scsi/hosts.c	2005-02-21 15:10:38 -08:00
@@ -160,6 +160,9 @@ static void scsi_host_dev_release(struct
 		shost->eh_notify = NULL;
 	}
 
+	if (shost->create_work_queue)
+		destroy_workqueue(shost->work_q);
+
 	scsi_proc_hostdir_rm(shost->hostt);
 	scsi_destroy_command_freelist(shost);
 	kfree(shost->shost_data);
@@ -247,6 +250,7 @@ struct Scsi_Host *scsi_host_alloc(struct
 	shost->cmd_per_lun = sht->cmd_per_lun;
 	shost->unchecked_isa_dma = sht->unchecked_isa_dma;
 	shost->use_clustering = sht->use_clustering;
+	shost->create_work_queue = sht->create_work_queue;
 
 	if (sht->max_host_blocked)
 		shost->max_host_blocked = sht->max_host_blocked;
@@ -285,16 +289,27 @@ struct Scsi_Host *scsi_host_alloc(struct
 	snprintf(shost->shost_classdev.class_id, BUS_ID_SIZE, "host%d",
 		  shost->host_no);
 
+	if (shost->create_work_queue) {
+		snprintf(shost->work_q_name, KOBJ_NAME_LEN, "scsi_wq_%d",
+			shost->host_no);
+		shost->work_q = create_singlethread_workqueue(
+			shost->work_q_name);
+		if (!shost->work_q)
+			goto fail_destroy_freelist;
+	}
+
 	shost->eh_notify = &complete;
 	rval = kernel_thread(scsi_error_handler, shost, 0);
 	if (rval < 0)
-		goto fail_destroy_freelist;
+		goto fail_destroy_workqueue;
 	wait_for_completion(&complete);
 	shost->eh_notify = NULL;
 
 	scsi_proc_hostdir_add(shost->hostt);
 	return shost;
 
+ fail_destroy_workqueue:
+	destroy_workqueue(shost->work_q);
  fail_destroy_freelist:
 	scsi_destroy_command_freelist(shost);
  fail_kfree:
@@ -392,3 +407,26 @@ int scsi_is_host_device(const struct dev
 	return dev->release == scsi_host_dev_release;
 }
 EXPORT_SYMBOL(scsi_is_host_device);
+
+/**
+ * scsi_queue_work - Queue work to the Scsi_Host workqueue.
+ * @shost:	Pointer to Scsi_Host.
+ * @work:	Work to queue for execution.
+ *
+ * Return value: 
+ * 	0 on success / != 0 for error
+ **/
+int scsi_queue_work(struct Scsi_Host *shost, struct work_struct *work)
+{
+	if (unlikely(!shost->create_work_queue)) {
+		printk(KERN_ERR
+			"ERROR: Scsi host '%s' attempted to queue scsi-work, "
+			"when no workqueue created.\n", shost->hostt->name);
+		dump_stack();
+
+		return -EINVAL;
+	}
+
+	return queue_work(shost->work_q, work);
+}
+EXPORT_SYMBOL_GPL(scsi_queue_work);
===== include/scsi/scsi_host.h 1.26 vs edited =====
--- 1.26/include/scsi/scsi_host.h	2005-01-19 08:01:21 -08:00
+++ edited/include/scsi/scsi_host.h	2005-02-21 12:13:32 -08:00
@@ -4,6 +4,7 @@
 #include <linux/device.h>
 #include <linux/list.h>
 #include <linux/types.h>
+#include <linux/workqueue.h>
 
 struct block_device;
 struct module;
@@ -363,6 +364,11 @@ struct scsi_host_template {
 	unsigned skip_settle_delay:1;
 
 	/*
+	 * True if a work-queue should be created for shost processing.
+	 */
+	unsigned create_work_queue:1;
+
+	/*
 	 * Countdown for host blocking with no commands outstanding
 	 */
 	unsigned int max_host_blocked;
@@ -501,6 +507,11 @@ struct Scsi_Host {
 	 */
 	unsigned reverse_ordering:1;
 
+	unsigned create_work_queue:1;
+
+	char work_q_name[KOBJ_NAME_LEN];
+	struct workqueue_struct *work_q;
+
 	/*
 	 * Host has rejected a command because it was busy.
 	 */
@@ -598,6 +609,7 @@ extern void scsi_free_host_dev(struct sc
 extern struct scsi_device *scsi_get_host_dev(struct Scsi_Host *);
 int scsi_is_host_device(const struct device *);
 
+extern int scsi_queue_work(struct Scsi_Host *, struct work_struct *);
 
 /* legacy interfaces */
 extern struct Scsi_Host *scsi_register(struct scsi_host_template *, int);

Re: [RFC] adding per scsi-host workqueues for defered processing

[Matthew Wilcox]

On Mon, Feb 21, 2005 at 04:09:37PM -0800, Andrew Vasquez wrote:
> * must be done from process context -- depending on transport type,
>   discovery can occur from a non-process context
> * potentially _long_ scan times -- even if discovery is done from a
>   'sleeping' capable context, halting a LLDD for discovery purposes
>   is typically undesirable.
> 
> I'd like to propose the addition of a per-Scsi_Host work-queue to
> manage these scanning as well as any other (relevant)
> lower-level-driver differed requests.

Why not use the per-host error handler thread for this?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: [RFC] adding per scsi-host workqueues for defered processing

[James.Smart]

> > 
> > I'd like to propose the addition of a per-Scsi_Host work-queue to
> > manage these scanning as well as any other (relevant)
> > lower-level-driver differed requests.
> 
> Why not use the per-host error handler thread for this?

brings a deadlock condition to mind - where the error thread is needed
in order to cancel/terminate an i/o issued via the scan.

-- james s

RE: [RFC] adding per scsi-host workqueues for defered processing

[James.Smart]

>Following discussions which resulted from the:
>
>[RFC] target code updates to support scanned targets
>http://marc.theaimsgroup.com/?l=linux-scsi&m=110850749515984&w=2
>
>thread, the overall consensus seems to be that transport-classes
>should support a 'true-hotplug' mechanism of device discovery and
>removal (this involves both registration and lun-scanning).  In order
>to facilitate this ability and to not constrain the LLDD from the
>typical restrictions of the storage scanning process:
>
>* must be done from process context -- depending on transport type,
>  discovery can occur from a non-process context
>* potentially _long_ scan times -- even if discovery is done from a
>  'sleeping' capable context, halting a LLDD for discovery purposes
>  is typically undesirable.
>
>I'd like to propose the addition of a per-Scsi_Host work-queue to
>manage these scanning as well as any other (relevant)
>lower-level-driver differed requests.

The thing I disliked about this patch was that it required the
LLDD to know that the transport needs a workq, thus set the host
template appropriately.

Instead, we should have the transport template, initialized by the
transport, indicate whether the workq needs to exist or not. This does
mean that the new interface is more restricted, as it essentially
excludes the LLDD from using it. It doesn't seem unreasonable as the
LLDD is always free to create it's own work queues.

I've attached a revised patch.

One other note:
>		scsi_scan_target(&rport->dev, rport->channel,
>			rport->scsi_target_id, SCAN_WILD_CARD, 0);

The rescan flag should be 1, not 0. If 0, all kinds of bad things can
happen as of the 2nd scan request.

-- james s



diff -puN a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
--- a/drivers/scsi/hosts.c	2005-03-05 06:55:47.000000000 -0500
+++ b/drivers/scsi/hosts.c	2005-03-05 07:13:43.000000000 -0500
@@ -129,6 +129,15 @@ int scsi_add_host(struct Scsi_Host *shos
 					 GFP_KERNEL)) == NULL)
 		goto out_del_classdev;
 
+	if (shost->transportt->create_work_queue) {
+		snprintf(shost->work_q_name, KOBJ_NAME_LEN, "scsi_wq_%d",
+			shost->host_no);
+		shost->work_q = create_singlethread_workqueue(
+					shost->work_q_name);
+		if (!shost->work_q)
+			goto out_free_shost_data;
+	}
+
 	error = scsi_sysfs_add_host(shost);
 	if (error)
 		goto out_destroy_host;
@@ -137,6 +146,10 @@ int scsi_add_host(struct Scsi_Host *shos
 	return error;
 
  out_destroy_host:
+	if (shost->work_q)
+		destroy_workqueue(shost->work_q);
+ out_free_shost_data:
+	kfree(shost->shost_data);
  out_del_classdev:
 	class_device_del(&shost->shost_classdev);
  out_del_gendev:
@@ -160,6 +173,9 @@ static void scsi_host_dev_release(struct
 		shost->eh_notify = NULL;
 	}
 
+	if (shost->work_q)
+		destroy_workqueue(shost->work_q);
+
 	scsi_proc_hostdir_rm(shost->hostt);
 	scsi_destroy_command_freelist(shost);
 	kfree(shost->shost_data);
@@ -393,3 +409,27 @@ int scsi_is_host_device(const struct dev
 	return dev->release == scsi_host_dev_release;
 }
 EXPORT_SYMBOL(scsi_is_host_device);
+
+/**
+ * scsi_queue_work - Queue work to the Scsi_Host workqueue.
+ * @shost:	Pointer to Scsi_Host.
+ * @work:	Work to queue for execution.
+ *
+ * Return value:
+ * 	0 on success / != 0 for error
+ **/
+int scsi_queue_work(struct Scsi_Host *shost, struct work_struct *work)
+{
+	if (unlikely(!shost->work_q)) {
+		printk(KERN_ERR
+			"ERROR: Scsi host '%s' attempted to queue scsi-work, "
+			"when no workqueue created.\n", shost->hostt->name);
+		dump_stack();
+
+		return -EINVAL;
+	}
+
+	return queue_work(shost->work_q, work);
+}
+EXPORT_SYMBOL_GPL(scsi_queue_work);
+
diff -puN a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
--- a/include/scsi/scsi_host.h	2005-03-05 06:56:48.000000000 -0500
+++ b/include/scsi/scsi_host.h	2005-03-05 07:07:12.000000000 -0500
@@ -4,6 +4,7 @@
 #include <linux/device.h>
 #include <linux/list.h>
 #include <linux/types.h>
+#include <linux/workqueue.h>
 
 struct block_device;
 struct module;
@@ -508,6 +509,12 @@ struct Scsi_Host {
 	unsigned reverse_ordering:1;
 
 	/*
+	 * Optional work queue to be utilized by the transport
+	 */
+	char work_q_name[KOBJ_NAME_LEN];
+	struct workqueue_struct *work_q;
+
+	/*
 	 * Host has rejected a command because it was busy.
 	 */
 	unsigned int host_blocked;
@@ -570,6 +577,8 @@ static inline struct Scsi_Host *dev_to_s
 	return container_of(dev, struct Scsi_Host, shost_gendev);
 }
 
+extern int scsi_queue_work(struct Scsi_Host *, struct work_struct *);
+
 extern struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *, int);
 extern int __must_check scsi_add_host(struct Scsi_Host *, struct device *);
 extern void scsi_scan_host(struct Scsi_Host *);
diff -puN a/include/scsi/scsi_transport.h b/include/scsi/scsi_transport.h
--- a/include/scsi/scsi_transport.h	2005-03-05 07:01:29.000000000 -0500
+++ b/include/scsi/scsi_transport.h	2005-03-05 07:03:21.000000000 -0500
@@ -34,6 +34,11 @@ struct scsi_transport_template {
 	int	device_size;
 	int	target_size;
 	int	host_size;
+
+	/*
+	 * True if the transport wants to use a host-based work-queue
+	 */
+	unsigned int create_work_queue : 1;
 };
 
 #define transport_class_to_shost(tc) \
_

RE: [RFC] adding per scsi-host workqueues for defered processing

[James.Smart]

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. However, it
should always be allocated and available. No "create" flag should
be needed.

Thoughts ?

-- james s


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of Smart, James
> Sent: Saturday, March 05, 2005 8:08 AM
> To: andrew.vasquez@qlogic.com; linux-scsi@vger.kernel.org
> Subject: RE: [RFC] adding per scsi-host workqueues for defered
> processing
> 
> 
> >Following discussions which resulted from the:
> >
> >[RFC] target code updates to support scanned targets
> >http://marc.theaimsgroup.com/?l=linux-scsi&m=110850749515984&w=2
> >
> >thread, the overall consensus seems to be that transport-classes
> >should support a 'true-hotplug' mechanism of device discovery and
> >removal (this involves both registration and lun-scanning).  In order
> >to facilitate this ability and to not constrain the LLDD from the
> >typical restrictions of the storage scanning process:
> >
> >* must be done from process context -- depending on transport type,
> >  discovery can occur from a non-process context
> >* potentially _long_ scan times -- even if discovery is done from a
> >  'sleeping' capable context, halting a LLDD for discovery purposes
> >  is typically undesirable.
> >
> >I'd like to propose the addition of a per-Scsi_Host work-queue to
> >manage these scanning as well as any other (relevant)
> >lower-level-driver differed requests.
> 
> The thing I disliked about this patch was that it required the
> LLDD to know that the transport needs a workq, thus set the host
> template appropriately.
> 
> Instead, we should have the transport template, initialized by the
> transport, indicate whether the workq needs to exist or not. This does
> mean that the new interface is more restricted, as it essentially
> excludes the LLDD from using it. It doesn't seem unreasonable as the
> LLDD is always free to create it's own work queues.
> 
> I've attached a revised patch.
> 
> One other note:
> >		scsi_scan_target(&rport->dev, rport->channel,
> >			rport->scsi_target_id, SCAN_WILD_CARD, 0);
> 
> The rescan flag should be 1, not 0. If 0, all kinds of bad things can
> happen as of the 2nd scan request.
> 
> -- james s
> 
> 
> 
> diff -puN a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> --- a/drivers/scsi/hosts.c	2005-03-05 06:55:47.000000000 -0500
> +++ b/drivers/scsi/hosts.c	2005-03-05 07:13:43.000000000 -0500
> @@ -129,6 +129,15 @@ int scsi_add_host(struct Scsi_Host *shos
>  					 GFP_KERNEL)) == NULL)
>  		goto out_del_classdev;
>  
> +	if (shost->transportt->create_work_queue) {
> +		snprintf(shost->work_q_name, KOBJ_NAME_LEN, 
> "scsi_wq_%d",
> +			shost->host_no);
> +		shost->work_q = create_singlethread_workqueue(
> +					shost->work_q_name);
> +		if (!shost->work_q)
> +			goto out_free_shost_data;
> +	}
> +
>  	error = scsi_sysfs_add_host(shost);
>  	if (error)
>  		goto out_destroy_host;
> @@ -137,6 +146,10 @@ int scsi_add_host(struct Scsi_Host *shos
>  	return error;
>  
>   out_destroy_host:
> +	if (shost->work_q)
> +		destroy_workqueue(shost->work_q);
> + out_free_shost_data:
> +	kfree(shost->shost_data);
>   out_del_classdev:
>  	class_device_del(&shost->shost_classdev);
>   out_del_gendev:
> @@ -160,6 +173,9 @@ static void scsi_host_dev_release(struct
>  		shost->eh_notify = NULL;
>  	}
>  
> +	if (shost->work_q)
> +		destroy_workqueue(shost->work_q);
> +
>  	scsi_proc_hostdir_rm(shost->hostt);
>  	scsi_destroy_command_freelist(shost);
>  	kfree(shost->shost_data);
> @@ -393,3 +409,27 @@ int scsi_is_host_device(const struct dev
>  	return dev->release == scsi_host_dev_release;
>  }
>  EXPORT_SYMBOL(scsi_is_host_device);
> +
> +/**
> + * scsi_queue_work - Queue work to the Scsi_Host workqueue.
> + * @shost:	Pointer to Scsi_Host.
> + * @work:	Work to queue for execution.
> + *
> + * Return value:
> + * 	0 on success / != 0 for error
> + **/
> +int scsi_queue_work(struct Scsi_Host *shost, struct 
> work_struct *work)
> +{
> +	if (unlikely(!shost->work_q)) {
> +		printk(KERN_ERR
> +			"ERROR: Scsi host '%s' attempted to 
> queue scsi-work, "
> +			"when no workqueue created.\n", 
> shost->hostt->name);
> +		dump_stack();
> +
> +		return -EINVAL;
> +	}
> +
> +	return queue_work(shost->work_q, work);
> +}
> +EXPORT_SYMBOL_GPL(scsi_queue_work);
> +
> diff -puN a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
> --- a/include/scsi/scsi_host.h	2005-03-05 
> 06:56:48.000000000 -0500
> +++ b/include/scsi/scsi_host.h	2005-03-05 
> 07:07:12.000000000 -0500
> @@ -4,6 +4,7 @@
>  #include <linux/device.h>
>  #include <linux/list.h>
>  #include <linux/types.h>
> +#include <linux/workqueue.h>
>  
>  struct block_device;
>  struct module;
> @@ -508,6 +509,12 @@ struct Scsi_Host {
>  	unsigned reverse_ordering:1;
>  
>  	/*
> +	 * Optional work queue to be utilized by the transport
> +	 */
> +	char work_q_name[KOBJ_NAME_LEN];
> +	struct workqueue_struct *work_q;
> +
> +	/*
>  	 * Host has rejected a command because it was busy.
>  	 */
>  	unsigned int host_blocked;
> @@ -570,6 +577,8 @@ static inline struct Scsi_Host *dev_to_s
>  	return container_of(dev, struct Scsi_Host, shost_gendev);
>  }
>  
> +extern int scsi_queue_work(struct Scsi_Host *, struct work_struct *);
> +
>  extern struct Scsi_Host *scsi_host_alloc(struct 
> scsi_host_template *, int);
>  extern int __must_check scsi_add_host(struct Scsi_Host *, 
> struct device *);
>  extern void scsi_scan_host(struct Scsi_Host *);
> diff -puN a/include/scsi/scsi_transport.h 
> b/include/scsi/scsi_transport.h
> --- a/include/scsi/scsi_transport.h	2005-03-05 
> 07:01:29.000000000 -0500
> +++ b/include/scsi/scsi_transport.h	2005-03-05 
> 07:03:21.000000000 -0500
> @@ -34,6 +34,11 @@ struct scsi_transport_template {
>  	int	device_size;
>  	int	target_size;
>  	int	host_size;
> +
> +	/*
> +	 * True if the transport wants to use a host-based work-queue
> +	 */
> +	unsigned int create_work_queue : 1;
>  };
>  
>  #define transport_class_to_shost(tc) \
> _
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] adding per scsi-host workqueues for defered processing

[Andrew Vasquez]

On Sat, 05 Mar 2005, James.Smart@Emulex.Com 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

Re: [RFC] adding per scsi-host workqueues for defered processing

[Andrew Vasquez]

On Sat, 05 Mar 2005, James.Smart@Emulex.Com wrote:

> I've attached a revised patch.
> 
> One other note:
> >		scsi_scan_target(&rport->dev, rport->channel,
> >			rport->scsi_target_id, SCAN_WILD_CARD, 0);
> 
> The rescan flag should be 1, not 0. If 0, all kinds of bad things can
> happen as of the 2nd scan request.
> 

Unless I'm reading the code incorrectly, we should be safe (only by
possessing some internal knowledge of the mid-layer) passing 0 in
these contexts:

* role change to target -- no previous devices (let alone
  scsi-targets) should be hanging off the rport.
* during creation, an rport is newly created with fc_rport_create().
* during creation, an rport was found in the fc_host_rport_bindings'
  list.  Again, any attached scsi-devices would have been torn-down
  prior to the rport being originally placed in the list.
* during an unblock call, where the rport's scsi-devices have already
  been torn down since the link-down-tmo had already expired.

But, I suppose in general it's best to play it safe.

--
AV

Re: [RFC] adding per scsi-host workqueues for defered processing

[Luben Tuikov]

On 03/08/05 02:00, Andrew Vasquez wrote:
> 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.

Yes, I agree.  Domain (target, topology, etc) discovery should be
"part" of the transport class.

What I'm thinking of is that the LLDD would register a known
trasport class with the SCSI Core at/after registering a host
template and then would call something with a name like
"start_scsi" which would do whatever necessary for the domain
(SAS, FC, iSCSI, etc) before scanning for targets.  Of course
for some domains no additional work is needed.

	Luben

RE: [RFC] adding per scsi-host workqueues for defered processing

[James.Smart]

So, is there a reason we aren't just starting the workq thread
upon the first call to queue something to it ?

-- james s

> -----Original Message-----
> From: Luben Tuikov [mailto:luben_tuikov@adaptec.com]
> Sent: Tuesday, March 08, 2005 8:12 AM
> To: Andrew Vasquez
> Cc: Smart, James; linux-scsi@vger.kernel.org
> Subject: Re: [RFC] adding per scsi-host workqueues for defered
> processing
> 
> 
> On 03/08/05 02:00, Andrew Vasquez wrote:
> > 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.
> 
> Yes, I agree.  Domain (target, topology, etc) discovery should be
> "part" of the transport class.
> 
> What I'm thinking of is that the LLDD would register a known
> trasport class with the SCSI Core at/after registering a host
> template and then would call something with a name like
> "start_scsi" which would do whatever necessary for the domain
> (SAS, FC, iSCSI, etc) before scanning for targets.  Of course
> for some domains no additional work is needed.
> 
> 	Luben
> 

Re: [RFC] adding per scsi-host workqueues for defered processing

[Andrew Vasquez]

On Wed, 09 Mar 2005, James.Smart@Emulex.Com wrote:

> 
> So, is there a reason we aren't just starting the workq thread
> upon the first call to queue something to it ?
> 

I don't see any reason why that approach wouldn't work in this
circumstance..

--
av

Re: [RFC] adding per scsi-host workqueues for defered processing

[Brian King]

James.Smart@Emulex.Com wrote:
> So, is there a reason we aren't just starting the workq thread
> upon the first call to queue something to it ?

Don't you need to be at task level to create a workq thread?

-Brian


> -- james s
> 
> 
>>-----Original Message-----
>>From: Luben Tuikov [mailto:luben_tuikov@adaptec.com]
>>Sent: Tuesday, March 08, 2005 8:12 AM
>>To: Andrew Vasquez
>>Cc: Smart, James; linux-scsi@vger.kernel.org
>>Subject: Re: [RFC] adding per scsi-host workqueues for defered
>>processing
>>
>>
>>On 03/08/05 02:00, Andrew Vasquez wrote:
>>
>>>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.
>>
>>Yes, I agree.  Domain (target, topology, etc) discovery should be
>>"part" of the transport class.
>>
>>What I'm thinking of is that the LLDD would register a known
>>trasport class with the SCSI Core at/after registering a host
>>template and then would call something with a name like
>>"start_scsi" which would do whatever necessary for the domain
>>(SAS, FC, iSCSI, etc) before scanning for targets.  Of course
>>for some domains no additional work is needed.
>>
>>	Luben
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center