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.
