[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac755067-1432-54ce-6a4f-c7383f1ecc9d@kernel.dk>
Date: Mon, 29 Oct 2018 13:53:12 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Bart Van Assche <bvanassche@....org>, linux-block@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/14] blk-mq: initial support for multiple queue maps
On 10/29/18 1:40 PM, Bart Van Assche wrote:
> On Mon, 2018-10-29 at 10:37 -0600, Jens Axboe wrote:
>> -static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
>> +static int cpu_to_queue_index(struct blk_mq_queue_map *qmap,
>> + unsigned int nr_queues, const int cpu)
>> {
>> - return cpu % nr_queues;
>> + return qmap->queue_offset + (cpu % nr_queues);
>> }
>>
>> [ ... ]
>>
>> --- a/include/linux/blk-mq.h
>> +++ b/include/linux/blk-mq.h
>> @@ -78,10 +78,11 @@ struct blk_mq_hw_ctx {
>> struct blk_mq_queue_map {
>> unsigned int *mq_map;
>> unsigned int nr_queues;
>> + unsigned int queue_offset;
>> };
>
> I think it's unfortunate that the blk-mq core uses the .queue_offset member but
> that mapping functions in block drivers are responsible for setting that member.
> Since the block driver mapping functions have to set blk_mq_queue_map.nr_queues,
> how about adding a loop in blk_mq_update_queue_map() that derives .queue_offset
> from .nr_queues from previous array entries?
It's not a simple increment, so the driver has to be the one setting it. If
we end up sharing queues, for instance, then the driver will need to set
it to the start offset of that set. If you go two patches forward you
can see that exact construct.
IOW, it's the driver that controls the offset, not the core.
--
Jens Axboe
Powered by blists - more mailing lists