Re: [PATCH V3 7/8] scsi: hpsa: improve scsi_mq performance via .host_tagset

2018-03-08 Thread Ming Lei
On Thu, Mar 08, 2018 at 08:54:43AM +0100, Christoph Hellwig wrote:
> > +   /* 256 tags should be high enough to saturate device */
> > +   int max_queues = DIV_ROUND_UP(h->scsi_host->can_queue, 256);
> > +
> > +   /* per NUMA node hw queue */
> > +   h->scsi_host->nr_hw_queues = min_t(int, nr_node_ids, max_queues);
> 
> I don't think this magic should be in a driver.  The per-node hw_queue
> selection seems like something we'd better do in the core code.

The thing is that driver code may need to know if multiple queues are used,
then driver may partition its own resource into multi hw queues, and
improve its .queuecommand and .complete_command. That seems what
megaraid_sas should do in next time.

> 
> Also the whole idea to use nr_hw_queues for just partitioning tag
> space on hardware that doesn't really support multiple hardware queues
> seems more than odd.

The per-node hw queue is used together with BLK_MQ_F_HOST_TAGS, which is
really for improving the single queue case(single tagset). If driver/device
supports real multiple hw queues, they don't need this approach.

Thanks,
Ming


Re: [PATCH V3 7/8] scsi: hpsa: improve scsi_mq performance via .host_tagset

2018-03-07 Thread Christoph Hellwig
> + /* 256 tags should be high enough to saturate device */
> + int max_queues = DIV_ROUND_UP(h->scsi_host->can_queue, 256);
> +
> + /* per NUMA node hw queue */
> + h->scsi_host->nr_hw_queues = min_t(int, nr_node_ids, max_queues);

I don't think this magic should be in a driver.  The per-node hw_queue
selection seems like something we'd better do in the core code.

Also the whole idea to use nr_hw_queues for just partitioning tag
space on hardware that doesn't really support multiple hardware queues
seems more than odd.