public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Sagar.Biradar@microchip.com, john.g.garry@oracle.com,
	Don.Brace@microchip.com, Gilbert.Wu@microchip.com,
	linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	brking@linux.vnet.ibm.com, stable@vger.kernel.org,
	Tom.White@microchip.com
Subject: Re: [PATCH] aacraid: reply queue mapping to CPUs based of IRQ affinity
Date: Tue, 18 Apr 2023 13:12:36 -0400	[thread overview]
Message-ID: <c5405999615929ba304988ebe18faf3853cc9a95.camel@linux.ibm.com> (raw)
In-Reply-To: <BYAPR11MB3606BFE903D1BBE56C89D31BFA959@BYAPR11MB3606.namprd11.prod.outlook.com>

[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@microchip.com 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


  parent reply	other threads:[~2023-04-18 17:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 21:41 [PATCH] aacraid: reply queue mapping to CPUs based of IRQ affinity Sagar Biradar
2023-03-29  7:08 ` John Garry
2023-04-10 21:17   ` Sagar.Biradar
2023-04-12  9:38     ` John Garry
2023-04-12 19:29       ` Sagar.Biradar
2023-04-13 21:52         ` Sagar.Biradar
2023-04-14  7:20           ` John Garry
2023-04-14 20:07       ` Sagar.Biradar
2023-04-18 16:36         ` Sagar.Biradar
2023-04-18 17:12     ` James Bottomley [this message]
2023-04-18 23:55       ` Sagar.Biradar
2023-04-19  7:42         ` John Garry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5405999615929ba304988ebe18faf3853cc9a95.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=Don.Brace@microchip.com \
    --cc=Gilbert.Wu@microchip.com \
    --cc=Sagar.Biradar@microchip.com \
    --cc=Tom.White@microchip.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=john.g.garry@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox