On Mon, Jun 03, 2019 at 08:08:18AM +0200, Hannes Reinecke wrote: > On 6/1/19 1:06 AM, Ming Lei wrote: > > On Fri, May 31, 2019 at 12:26:56PM +0200, Hannes Reinecke wrote: > >> On 5/31/19 10:46 AM, Ming Lei wrote: > [ .. ] > >> First we check for the 'slot_index_alloc()' callback to handle weird v2 > >> allocation rules, _then_ we look for a tag, and only if we do _not_ have > >> a tag we're using the bitmap. > > > > OK, looks I miss the above change. > > > >> And the bitmap is already correctly sized, as otherwise we'd have a > >> clash between internal and tagged I/O commands even now. > > > > But now the big problem is in the following two line code: > > > > + else if (blk_tag != (u32)-1) > > + rc = blk_mq_unique_tag_to_tag(blk_tag); > > > > Request from different blk-mq hw queue has same tag returned from > > blk_mq_unique_tag_to_tag(). > > > Yes, but the sbitmap allocator will ensure that each command will get a > unique tag.
Each hw queue has independent sbitmap allocator, so commands with same tag can come from different hw queue. So you meant this RFC patch depends on the host-wide tags patchset I posted? > > > Now the biggest question is that if V3 hw supports per-queue tags, > > If yes, it should be real MQ hardware, otherwise I guess commands with > > same tag at the same time may not work for host-wide tags. > > > > Of course you can't have different commands with the same tag. But the > sbitmap allocator prevents this from happening, as for host-wide tags > the tagset is _shared_ between all devices, so the sbitmap allocator > will only ever run on _one_ tagset for all commands. But blk-mq doesn't support host-wide tags yet, so how can this single patch work? Thanks, Ming
