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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 8A0BFC43381 for ; Mon, 25 Mar 2019 13:48:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FB3820830 for ; Mon, 25 Mar 2019 13:48:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553521708; bh=RA5q9JPt+g4BuA2WAtZKYnH0ae0Hq57mSjDJHYpp/Qo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=YgnmG6SM4HL1hDig/XgCOTKnqStSDjY9YN7QFeiY64uYUmJuJsuEA9g8kJaPNvq4+ Ib2/62WTtls4mbelh3UQC5yEcCG886xb1hnBlrmZTedEESI3902iauDqwzk57vWXVh sTDmVA5Z79MJP0O7ixwGMVkep7HOp2J3RHx8/kKk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729126AbfCYNs0 (ORCPT ); Mon, 25 Mar 2019 09:48:26 -0400 Received: from mga01.intel.com ([192.55.52.88]:5603 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727111AbfCYNs0 (ORCPT ); Mon, 25 Mar 2019 09:48:26 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2019 06:48:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,269,1549958400"; d="scan'208";a="217363341" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga001.jf.intel.com with ESMTP; 25 Mar 2019 06:48:11 -0700 Date: Mon, 25 Mar 2019 07:49:18 -0600 From: Keith Busch To: Jianchao Wang Cc: axboe@kernel.dk, hch@lst.de, jthumshirn@suse.de, hare@suse.de, josef@toxicpanda.com, bvanassche@acm.org, sagi@grimberg.me, keith.busch@intel.com, jsmart2021@gmail.com, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 7/8] nvme: use blk_mq_queue_tag_inflight_iter Message-ID: <20190325134917.GA4328@localhost.localdomain> References: <1553492318-1810-1-git-send-email-jianchao.w.wang@oracle.com> <1553492318-1810-8-git-send-email-jianchao.w.wang@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1553492318-1810-8-git-send-email-jianchao.w.wang@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 25, 2019 at 01:38:37PM +0800, Jianchao Wang wrote: > blk_mq_tagset_inflight_iter is not safe that it could get stale request > in tags->rqs[]. Use blk_mq_queue_tag_inflight_iter here. A new helper > interface nvme_iterate_inflight_rqs is introduced to iterate > all of the ns under a ctrl. Nak, NVMe only iterates tags when new requests can't enter, allocated requests can't dispatch, and dispatched commands can't complete. So it is perfectly safe to iterate if the driver takes reasonable steps beforehand. Further, for M tags and N namespaces, we complete teardown in O(M) time, but this makes in O(M*N) without gaining anything.