From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AF68C7619F for ; Mon, 17 Feb 2020 10:10:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0512D20679 for ; Mon, 17 Feb 2020 10:10:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="ZSnbAFre" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729052AbgBQKKN (ORCPT ); Mon, 17 Feb 2020 05:10:13 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:36075 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728833AbgBQKKN (ORCPT ); Mon, 17 Feb 2020 05:10:13 -0500 Received: by mail-oi1-f194.google.com with SMTP id c16so16183939oic.3 for ; Mon, 17 Feb 2020 02:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7YsGCSyVBPYt/3r/sbYFtdX9xctg+GdUB7WTA5vRuN8=; b=ZSnbAFreZ9DbTHwZeUzivOorQhB9Ohztu5cmBwyG2A5fZ1tykPiXdXAw1D45vNzaP9 9DuGGYom+qJMkLAOz9KJGUwMdepRask4j+uBvfv3ZVx1esCY6wFOacegXVfezIUgK5jv S46dxw53IP0glnl4mvKysoyCwNWc80YwMXSvQ= 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=7YsGCSyVBPYt/3r/sbYFtdX9xctg+GdUB7WTA5vRuN8=; b=IBUHouLUWii8BbncqESkr/joKtp4KmF8JDmnzwGGtwchB8ARMz0szwbb7LsGASenIZ YPHnq+zNb37QmX9jDI62rImyGBbQssND7VtDEckMopqcB8bvk9XJQLmbnut/TTIxcI+d /W6AIDDKBQtF1tjDk3JognILvGV1Y+X1vIUtHtG+lyj3j7TBGX5CNOwNHD/t5VdKUUYF Xluqafraa1nSpOLZdUujRxaoRr/GsaecfEhD+y746u8/xPlmxi2KJJnsZGSc5jaP+Ybw qXFvkfaH6i0i0XSazf5SPHDRtMHU5l5OHUNEAnP0wW/7K2ip7evyv+TVFmmE+GxIcBKh PKyQ== X-Gm-Message-State: APjAAAVOFWbmdtSB7QtGNdfSjY6TCu04c5nN16/LqY4bX/tFPkxwBSLO McIFAdQ0OdPmmyANhhGvl+7Jzk9VzMZuVAkr7nbkvg== X-Google-Smtp-Source: APXvYqxPecfjOC29bfeXXI/Vrt8ZjjF3/47gJQbdzPfu2gN6TCNYWgm+GRk9yDDI+sXLOFH2c+GZLShzBjhJKeb1DAA= X-Received: by 2002:aca:1a10:: with SMTP id a16mr9683878oia.9.1581934211131; Mon, 17 Feb 2020 02:10:11 -0800 (PST) MIME-Version: 1.0 References: <20191202153914.84722-1-hare@suse.de> <20191202153914.84722-10-hare@suse.de> <11034edd-732a-3dd5-0bdc-891b9de05e56@huawei.com> In-Reply-To: From: Sumit Saxena Date: Mon, 17 Feb 2020 15:39:45 +0530 Message-ID: Subject: Re: [PATCH 09/11] megaraid_sas: switch fusion adapters to MQ To: John Garry Cc: Hannes Reinecke , "Martin K. Petersen" , Jens Axboe , Christoph Hellwig , James Bottomley , Ming Lei , Linux SCSI List , "linux-block@vger.kernel.org" , Hannes Reinecke Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, Feb 13, 2020 at 3:37 PM John Garry wrote: > > On 17/01/2020 11:18, Sumit Saxena wrote: > >>>> or doing a performance test here. > >>> Hi Hannes, > >>> > > Hi Sumit, > > >>> Sorry for the delay in replying, I observed a few issues with this patchset: > >>> > >>> 1. "blk_mq_unique_tag_to_hwq(tag)" does not return MSI-x vector to > >>> which IO submitter CPU is affined with. Due to this IO submission and > >>> completion CPUs are different which causes performance drop for low > >>> latency workloads. > >> Hi Sumit, > >> > >> So the new code has: > >> > >> megasas_build_ldio_fusion() > >> { > >> > >> cmd->request_desc->SCSIIO.MSIxIndex = > >> blk_mq_unique_tag_to_hwq(tag); > >> > >> } > >> > >> So the value here is hw queue index from blk-mq point of view, and not > >> megaraid_sas msix index, as you alluded to. > > Yes John, value filled in "cmd->request_desc->SCSIIO.MSIxIndex" is HW > > queue index. > > > >> So we get 80 msix, 8 are reserved for low_latency_index_start (that's > >> how it seems to me), and we report other 72 as #hw queues = 72 to SCSI > >> midlayer. > >> > >> So I think that this should be: > >> > >> cmd->request_desc->SCSIIO.MSIxIndex = > >> blk_mq_unique_tag_to_hwq(tag) + low_latency_index_start; > > Can you possibly test performance again with this local change, or would > you rather an updated patchset be sent? Updated patchset is not required. I will do performance run with this change and update. Thanks, Sumit > > > Agreed, this should return correct HW queue index. > >> > > > Thanks, > John