[I'm with Jon: your email style makes digging information out of the emails very hard, which is why I only quote this section] On Mon, 2023-04-10 at 21:17 +0000, Sagar.Biradar@xxxxxxxxxxxxx wrote: > ***blk-mq already does what you want here, including handling for the > case I mention above. It maintains a CPU -> HW queue mapping, and > using a reply map in the LLD is the old way of doing this. > > We also tried implementing the blk-mq mechanism in the driver and we > saw command timeouts. > The firmware has limitation of fixed number of queues per vector and > the blk-mq changes would saturate that limit. > That answers the possible command timeout. Could we have more details on this, please? The problem is that this is a very fragile area of the kernel, so you rolling your own special snowflake implementation in the driver is going to be an ongoing maintenance problem (and the fact that you need this at all indicates you have long tail customers who will be around for a while yet). If the only issue is limiting the number of queues per vector, we can look at getting the block layer to do that. Although I was under the impression that you can do it yourself with the ->map_queues() callback. Can you say a bit about why this didn't work? James
