On Mon, Dec 17, 2018 at 08:06:04AM +0100, Christoph Hellwig wrote: > On Mon, Dec 17, 2018 at 09:00:52AM +0800, Ming Lei wrote: > > On Sun, Dec 16, 2018 at 05:11:59PM +0100, Christoph Hellwig wrote: > > > On Sun, Dec 16, 2018 at 10:25:14AM +0800, Ming Lei wrote: > > > > If we don't have poll queue, its mapping should share default type's, > > > > instead of setting up one new mapping via blk_mq_map_queues(). > > > > > > No, if we don't have poll queues nr_maps should be 2. I've already > > > posted a patch for that for nvme-pci which got it wrong (my fault..) > > > > This patch doesn't touch nr_maps. > > > > The issue is that if poll_queues/write_queues are zero, all three mapping > > should be same, however they aren't actually because we still use blk_mq_map_queues() > > to build a new mapping for poll queue. > > In Jens' for-4.21 we only support polling with explicit poll queues, > and thus an explicit poll map. Which means nr_maps must be 3 if you > support poll maps, and < 3 if you don't. As said, the only user actually > got that wrong (my fault), but the fix is already queue up in the nvme > tree and on its way to Jens. OK, just not see it in Jens's tree. However, IMO, the fix in this patchset may be better, given we still can pass HCTX_MAX_TYPES no matter if poll_queues is zero or other, even in future 'poll_queues/write_queues' might become a per-controller attribute. For example, there are two NVMe controllers, one is slow and another is fast, we may just want to enable poll for fast one. Thanks, Ming
