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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 51215C433DB for ; Fri, 5 Mar 2021 13:17:46 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C205A64F60 for ; Fri, 5 Mar 2021 13:17:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C205A64F60 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ABypLj0h2M1bTuLFRv5fF8yhlSadm/zrAcFPohUIdzk=; b=TGRKh+5HXbU3vn7M99Sr47vSB ZKYnrHxC+ORj6Z5BR6A2UhUyelPlTKDnqygsU8ooafrb0U0ak2sc2zCggtIygv6gb0bvHfE8wvpDW 8O7zgBPKNgcs1kygWTH5dq/BTmCSJHdyoApAS0HYL1TvzGm2HbyBj+jEj4QVjsTAvsogkWZcW39EG 3T5DqaQecwrd3RXNsoSuVyhvADi6Q1nKnWKQOUItGA4wRYS1nlXpcEc8FyETw6IUgd7UBMccA8iUu eU06pYXhVoPwjQWxlAWj4pFzQ0x+GUWVkGT300s4WlgZv2bDTUz7Ayyrv/0MOxqkuh8uxg2Vhi39+ bzalAnF/Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIAKZ-00F4dP-PB; Fri, 05 Mar 2021 13:17:23 +0000 Received: from verein.lst.de ([213.95.11.211]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lIAKS-00F4bl-VN for linux-nvme@lists.infradead.org; Fri, 05 Mar 2021 13:17:18 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id E6C3368B05; Fri, 5 Mar 2021 14:17:11 +0100 (CET) Date: Fri, 5 Mar 2021 14:17:11 +0100 From: "hch@lst.de" To: Keith Busch Cc: Kanchan Joshi , Chaitanya Kulkarni , Kanchan Joshi , "axboe@kernel.dk" , "hch@lst.de" , "io-uring@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "anuj20.g@samsung.com" , "javier.gonz@samsung.com" Subject: Re: [RFC 3/3] nvme: wire up support for async passthrough Message-ID: <20210305131711.GA9557@lst.de> References: <20210302160734.99610-1-joshi.k@samsung.com> <20210302160734.99610-4-joshi.k@samsung.com> <20210305024133.GD32558@redsun51.ssa.fujisawa.hgst.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210305024133.GD32558@redsun51.ssa.fujisawa.hgst.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210305_131717_339938_8D8AB56B X-CRM114-Status: GOOD ( 13.74 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org On Fri, Mar 05, 2021 at 11:41:33AM +0900, Keith Busch wrote: > I'll need to think on this to consider if the memory cost is worth it > (8b to 64b), but you could replace nvme_request's 'struct nvme_command' > pointer with the struct itself and not have to allocate anything per IO. > An added bonus is that sync and async handling become more the same. This would solve a lot of mess with the async passthrough, and also more closely match what is done in SCSI. In theory we could use a cut down version without the data and metadata pointers (just 40 bytes), but I'm not sure that is really worth it given that we then need to rearrange things in the I/O path. _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme