Re: [PATCH 05/11] vhost scsi: use lio wq cmd submission helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/5/21 10:17 AM, Michael S. Tsirkin wrote:
> On Thu, Feb 04, 2021 at 05:35:07AM -0600, Mike Christie wrote:
>> @@ -1132,14 +1127,8 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct vhost_virtqueue *vq)
>>  		 * vhost_scsi_queue_data_in() and vhost_scsi_queue_status()
>>  		 */
>>  		cmd->tvc_vq_desc = vc.head;
>> -		/*
>> -		 * Dispatch cmd descriptor for cmwq execution in process
>> -		 * context provided by vhost_scsi_workqueue.  This also ensures
>> -		 * cmd is executed on the same kworker CPU as this vhost
>> -		 * thread to gain positive L2 cache locality effects.
>> -		 */
>> -		INIT_WORK(&cmd->work, vhost_scsi_submission_work);
>> -		queue_work(vhost_scsi_workqueue, &cmd->work);
>> +		target_queue_cmd_submit(tpg->tpg_nexus->tvn_se_sess,
>> +					&cmd->tvc_se_cmd);
>>  		ret = 0;
>>  err:
>>  		/*
> 
> What about this aspect? Will things still stay on the same CPU
Yes, if that is what it's configured to do.

On the submission path there is no change in behavior. target_queue_cmd_submit
does queue_work_on so it executes the cmd on the same CPU in LIO. Once
LIO passes it to the block layer then that layer does whatever is setup.

On the completion path the low level works the same. The low level
driver goes by its ISRs/softirq/completion-thread settings, the block layer
then goes by the queue settings like rq_affinity.

The change in behavior is that in LIO we will do what was configured
in the layer below us instead of always trying to complete on the same
CPU it was submitted on.



[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux