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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 747BAC433E6 for ; Tue, 16 Mar 2021 17:17:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3005E65125 for ; Tue, 16 Mar 2021 17:17:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237706AbhCPRQd (ORCPT ); Tue, 16 Mar 2021 13:16:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:54782 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237835AbhCPRQc (ORCPT ); Tue, 16 Mar 2021 13:16:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 02AE165087; Tue, 16 Mar 2021 17:16:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615914991; bh=fdcmLeCKntdm771dazuCVoEbNhFZVVC6Ghj+TWf/STk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CCDR/xpjvR4QU7lzoqi/3tosKKyd7W5ENo4MsTOL1gmsrGkGvfcqH54Bqrc+7BRa4 UwovXz7O2fLYr8Miki19T7vkIiAbntxwqnKYDzdL3ZtE/UIdKAMxZ7UkGJuQv0ESdl uGBDgVJB4qcjS0I6p30h2lTUj845V0AS+s7ipAKxfTiQebursMB0wDOxDB9K79szTg OnYtAEUft1o93r6faS0Hg+6qRYLpJyHsOdPQueRPPogT8QUmfhgd1cU/iLOZpOv4pL MQw8TKtTtXLbZ7l0tCY9ssBXsxJ+y9ddnccOEBSP0Euw2TwyBjSF4iJHO+0FJokpti kyW7XzEStEuwQ== Date: Tue, 16 Mar 2021 10:16:28 -0700 From: Keith Busch To: Kanchan Joshi Cc: axboe@kernel.dk, hch@lst.de, chaitanya.kulkarni@wdc.com, io-uring@vger.kernel.org, linux-nvme@lists.infradead.org, anuj20.g@samsung.com, javier.gonz@samsung.com, nj.shetty@samsung.com, selvakuma.s1@samsung.com Subject: Re: [RFC PATCH v3 2/3] nvme: keep nvme_command instead of pointer to it Message-ID: <20210316171628.GA4161119@dhcp-10-100-145-180.wdc.com> References: <20210316140126.24900-1-joshi.k@samsung.com> <20210316140126.24900-3-joshi.k@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210316140126.24900-3-joshi.k@samsung.com> Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Tue, Mar 16, 2021 at 07:31:25PM +0530, Kanchan Joshi wrote: > nvme_req structure originally contained a pointer to nvme_command. > Change nvme_req structure to keep the command itself. > This helps in avoiding hot-path memory-allocation for async-passthrough. I have a slightly different take on how to handle pre-allocated passthrough commands. Every transport except PCI already preallocates a 'struct nvme_command' within the pdu, so allocating another one looks redundant. Also, it does consume quite a bit of memory for something that is used only for the passthrough case. I think we can solve both concerns by always using the PDU nvme_command rather than have the transport drivers provide it. I just sent the patch here if you can take a look. It tested fine on PCI and loop (haven't tested any other transports). http://lists.infradead.org/pipermail/linux-nvme/2021-March/023711.html