Re: [PATCH 10/14] blk-mq: initial support for multiple queue maps

[Bart Van Assche <bvanassche@acm.org>]

On Mon, 2018-10-29 at 13:53 -0600, Jens Axboe wrote:
> 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.

If sharing of hardware queues between hardware queue types is supported,
what should hctx->type be set to? Additionally, patch 5 adds code that uses
hctx->type as an array index. How can that code work if a single hardware
queue can be shared by multiple hardware queue types?

Thanks,

Bart.