On 10/02/2012 06:51 PM, John, Sony wrote: >> Creating UNBOUND WQ for each EQ in the driver. >> What is the benefit of doing this vs per hba like before? > EQ's are created based on the NUM_CPU in the machine. Notification for task completion comes on an EQ. There could be multiple entries in the EQ that need to be processed and driver iterates the list of entries on that EQ does the required processing and then re-arms EQ for further interrupts. The issue with per hba WQ was it was not possible to get the EQ on which the interrupt has come. > > In the new infrastructure a single_thread WQ is assigned to each EQ that is created. The EQ structure ptr is passed as the device data structure while registering the interrupts. When interrupts comes, driver can just queue_work for that EQ from the interrupt handler. > Why not? Maybe I am not understanding you. You can allocate a workqueue_struct per hba, but embed a work struct in each be_queue_info. Then do: queue_work(phba->wq, &eq->work_cqs); You would then keep + INIT_WORK(&pbe_eq->work_cqs, beiscsi_process_all_cqs); in your patch and in the the work function for the eq->work_cqs you would get the eq like you wanted. You also then do not have to worry about too many workqueues being made and you do not have to use WQ_UNBOUND as a work around. >> Why WQ_UNBOUND? It seems other drivers prefer it the other way. > The intention of using the flag WQ_UNBOUND was to have a single_work_queue across all cores for each EQ created. Default implementation of "alloc_workqueue" is creating workqueue per core, in driver EQ creation depends on NUM_CPU and based on that too many workqueues will be created which can be counter productive. This scenario is hit only in blk_iopoll disable mode and the latest kernel it is always enabled. So used the WQ_UNBOUND flag to make is as single thread. > > Thanks > Sony > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
