Re: SCSI API generics (was Re: [PATCH] add block/unblock to iscsi class)
Andrew Vasquez wrote: On Wed, 23 Feb 2005, Mike Christie wrote: The attached patch copies the code from the fc transport class which allows a LLD to block and unblock a device. The block/unblock code is used by the iscsi-sfnet driver in replacement of a internal timer doing the same thing. I understand that the target code is under construction and our group as well as the HW iSCSI guys are trying to move to something closer to the fc's rport model, so I was not sure if it is better to wait or get this basic functionality in first so we (and other SW and HW iSCSI drivers) can kill some of our duplicated code sooner and then incrementally update the class. Speaking of which, are there any major objections to the patches proposed here: Add scsi_target_[un]block() and scsi_target_remove() generics http://marc.theaimsgroup.com/?l=linux-scsim=110867050306738w=2 [RFC] adding per scsi-host workqueues for defered processing http://marc.theaimsgroup.com/?l=linux-scsim=110903148407438w=2 When using single_threaded_workqueues do all single threaded ones in the system use the same cpu_workqueue_struct? Will this be a potential bottleneck if we end up using the workqueue for more operations in the future? - 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
Re: SCSI API generics (was Re: [PATCH] add block/unblock to iscsi class)
On Wed, 23 Feb 2005, Mike Christie wrote: Andrew Vasquez wrote: Speaking of which, are there any major objections to the patches proposed here: Add scsi_target_[un]block() and scsi_target_remove() generics http://marc.theaimsgroup.com/?l=linux-scsim=110867050306738w=2 [RFC] adding per scsi-host workqueues for defered processing http://marc.theaimsgroup.com/?l=linux-scsim=110903148407438w=2 When using single_threaded_workqueues do all single threaded ones in the system use the same cpu_workqueue_struct? Will this be a potential bottleneck if we end up using the workqueue for more operations in the future? The kernel-thread that is created for a single-threaded workqueue is not bound to any particular CPU: kthread.c:kthread() ... /* By default we can run anywhere, unlike keventd. */ set_cpus_allowed(current, CPU_MASK_ALL); -- Andrew Vasquez - 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
Re: SCSI API generics (was Re: [PATCH] add block/unblock to iscsi class)
Mike Christie wrote: Andrew Vasquez wrote: On Wed, 23 Feb 2005, Mike Christie wrote: Andrew Vasquez wrote: Speaking of which, are there any major objections to the patches proposed here: Add scsi_target_[un]block() and scsi_target_remove() generics http://marc.theaimsgroup.com/?l=linux-scsim=110867050306738w=2 [RFC] adding per scsi-host workqueues for defered processing http://marc.theaimsgroup.com/?l=linux-scsim=110903148407438w=2 When using single_threaded_workqueues do all single threaded ones in the system use the same cpu_workqueue_struct? Will this be a potential bottleneck if we end up using the workqueue for more operations in the future? The kernel-thread that is created for a single-threaded workqueue is not bound to any particular CPU: kthread.c:kthread() ... /* By default we can run anywhere, unlike keventd. */ set_cpus_allowed(current, CPU_MASK_ALL); My question is not about which cpu it is run on. I am asking about the cpu_workqueue_struct. In create_workqueue_thread cpu always equals zero so later when it is run it can be on any cpu but every single threaded workqueue will access the same cpu_workqueue_struct. Oh wait nevermind that too. I should read the code more closely next time. - 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