Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2206848pxb; Mon, 11 Jan 2021 04:00:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJznKmjM9EpJkjHnbYmfauZA+yB/eT36IREVQURbUJHhLku4CajoqxWltAEiMbmO5iReoeRT X-Received: by 2002:a50:e84d:: with SMTP id k13mr13530510edn.154.1610366435372; Mon, 11 Jan 2021 04:00:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610366435; cv=none; d=google.com; s=arc-20160816; b=ChEV39YgckIseXmil9AOtVMNhQCpGNo11YhaC4WDETB/Aswi0FDLF0N1oLlYLhyxkn Gm0X7X3q3KN97c6dectUsjCcxH+WfZFYaETKTovo4h+hhpPSIrYIMttYrvWIGYS1stmO +EQ9mw6/iTVFFWKvXlvhuSg77sXitFQi5b21Ag5jpy1lop28aXtPTTWI+7S1D/JJx0xD uX49Mjz9ekfoIUN50hIBtnHB9efnOAZUVGTcO2v0hPvY4BM+hYPAwxwcvPGbf3U6UWiQ nWXDAjJTAycX2axwAphKRfvxlRRlUcP1mPSEQKHg8WvFL1RDcinf+F1i82pVDoppHKbt wz0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3a/SOwrE/x7Mq5AUuCGgo7i/Ivq/zLoasPchczS3M28=; b=XmkbWSU82MRgx+N2QFtpf6L1BdbDPlrstQKGMnjDeG2Z+1AzdXvBDa3dt57Hx4r9uH 9H48LRWILUU9UoZJ6vwAotisTUBNkSG9SUp4Ft3J0X323vBKjZlEvHQ+T9ONb8Hha5iH GhEwYI/jhamaQ7JkHg+Z5jIbGA8tTjaTCHg3GGvEV7BRx71g49ke5wk/MdNclO+njfzm seTRu5K+v851mKCpiZTopzwHTPRimMM2peC8hnqlaNDk6+KWG0h6MlGgzw5Sao1UQBkG A7RuefL7zCd/761RmAbKo8qiqOqlTUOVOdqbTibVyZf/ifedVz38zz1t3BCsM52nnaHD C1yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cloud.ionos.com header.s=google header.b=Cmc+HjMn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ionos.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si6901309edw.310.2021.01.11.04.00.11; Mon, 11 Jan 2021 04:00:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cloud.ionos.com header.s=google header.b=Cmc+HjMn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ionos.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729533AbhAKL6k (ORCPT + 99 others); Mon, 11 Jan 2021 06:58:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729401AbhAKL6j (ORCPT ); Mon, 11 Jan 2021 06:58:39 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0992C061794 for ; Mon, 11 Jan 2021 03:57:58 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id qw4so24223891ejb.12 for ; Mon, 11 Jan 2021 03:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.ionos.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3a/SOwrE/x7Mq5AUuCGgo7i/Ivq/zLoasPchczS3M28=; b=Cmc+HjMnVzrq6oOxdAKbM4c8V4K6hquq83tInn6NRIcboLbWsL1uRsj5KmvQ9bo8BP RTIjYdBy17ttiEfD8LaSkV86q2Jx847myJQJgaoEll0b4IbCUThHFxQDcxe0fD/RntyD 5RuE6/PI5YzJiuuFF7+l7iBvASL+v5eycw4d+4DQ2SLcphVbBdR+K41xCQvfiisVJrVJ XPJuVMRppkDdlI0cqHjr27ZycGQ4KnooSqwAB6XQvo4o727OiikKGftqwxuClvJoeYhm mhvF1oGg/pA7e+psl2d/ddMOrW7HS20IyKWxozxvm+k053hInp3zQ7cIL2/kh57HTB+b X9/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3a/SOwrE/x7Mq5AUuCGgo7i/Ivq/zLoasPchczS3M28=; b=ZrIoAJnZO66OhDfhLmRhk1qv2cB56gCOcZ0H2l6FGJ7HlKknJdpG4iP5/coSAUDhzP f2ftahw+O+6ue8ry6wu5DKRBnYbVOQHo7wTXX51fs/4d/0pDRJd1BCZyzOISoMolxpOG q4icDBSmR0YvJkmmAVVuf1FnCftJ6K/d5ly7Auw7+xIIdjJVW0m74/PmHbMLlAv0bI8V KA7vSVlfrX1bviaOlcncy/XxPjNLGnRHDPNFuJlPzfet1ROCOQ4JSgcofeh7CLUo1YHm Ma5lwU/SyaTTGIwCBAMIg5STes6hxrMukpXx746LMjbb2S0vKid4sNQoVgmEl3avInof lbOQ== X-Gm-Message-State: AOAM531KTUVj6wLvELn4cikCd5jS6MrLkatJMpUvjVtU+PUGBax+Deem rN0unG/73F04BGrINfcO7pbH8Cl9Jwd3FUqeSOcd/g== X-Received: by 2002:a17:906:94ca:: with SMTP id d10mr10062461ejy.62.1610366277600; Mon, 11 Jan 2021 03:57:57 -0800 (PST) MIME-Version: 1.0 References: <1609845423-110410-1-git-send-email-john.garry@huawei.com> In-Reply-To: <1609845423-110410-1-git-send-email-john.garry@huawei.com> From: Jinpu Wang Date: Mon, 11 Jan 2021 12:57:46 +0100 Message-ID: Subject: Re: [RFC/RFT PATCH] scsi: pm8001: Expose HW queues for pm80xx hw To: John Garry , Viswas G Cc: "James E.J. Bottomley" , "Martin K. Petersen" , akshatzen@google.com, Ruksar.devadi@microchip.com, Radha Ramachandran , bjashnani@google.com, vishakhavc@google.com, Ashokkumar.N@microchip.com, Linux SCSI Mailinglist , open list , Hannes Reinecke , Kashyap Desai , ming.lei@redhat.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, On Tue, Jan 5, 2021 at 12:21 PM John Garry wrote: > > In commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported > queues"), support for 80xx chip was improved by enabling multiple HW > queues. > > In this, like other SCSI MQ HBA drivers, the HW queues were not exposed > to upper layer, and instead the driver managed the queues internally. > > However, this management duplicates blk-mq code. In addition, the HW queue > management is sub-optimal for a system where the number of CPUs exceeds > the HW queues - this is because queues are selected in a round-robin > fashion, when it would be better to make adjacent CPUs submit on the same > queue. And finally, the affinity of the completion queue interrupts is not > set to mirror the cpu<->HQ queue mapping, which is suboptimal. > > As such, for when MSIX is supported, expose HW queues to upper layer. Flag > PCI_IRQ_AFFINITY is set for allocating the MSIX vectors to automatically > assign affinity for the completion queue interrupts. > > Signed-off-by: John Garry > > --- > I sent as an RFC/RFT as I have no HW to test. In addition, since HW queue > #0 is used always for internal commands (like in send_task_abort()), if > all CPUs associated with HW queue #0 are offlined, the interrupt for that > queue will be shutdown, and no CPUs would be available to service any > internal commands completion. To solve that, we need [0] merged first and > switch over to use the new API. But we can still test performance in the > meantime. > > I assume someone else is making the change to use the request tag for IO > tag management. > > [0] https://lore.kernel.org/linux-scsi/47ba045e-a490-198b-1744-529f97192d3b@suse.de/ Thanks for the patch, maybe Viswas can help to test? Regards!