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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42E35C433FE for ; Fri, 11 Mar 2022 06:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346416AbiCKG2T (ORCPT ); Fri, 11 Mar 2022 01:28:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbiCKG2R (ORCPT ); Fri, 11 Mar 2022 01:28:17 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 280991A9072; Thu, 10 Mar 2022 22:27:15 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 3664F68AFE; Fri, 11 Mar 2022 07:27:11 +0100 (CET) Date: Fri, 11 Mar 2022 07:27:10 +0100 From: Christoph Hellwig To: Kanchan Joshi Cc: Christoph Hellwig , Kanchan Joshi , Jens Axboe , Keith Busch , Pavel Begunkov , io-uring@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, sbates@raithlin.com, logang@deltatee.com, Pankaj Raghav , Javier =?iso-8859-1?Q?Gonz=E1lez?= , Luis Chamberlain , Adam Manzanares , Anuj Gupta Subject: Re: [PATCH 17/17] nvme: enable non-inline passthru commands Message-ID: <20220311062710.GA17232@lst.de> References: <20220308152105.309618-1-joshi.k@samsung.com> <20220308152105.309618-18-joshi.k@samsung.com> <20220310083652.GF26614@lst.de> <20220310141945.GA890@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Fri, Mar 11, 2022 at 12:13:24AM +0530, Kanchan Joshi wrote: > Problem is, the inline facility does not go very well with this > particular nvme-passthru ioctl (NVME_IOCTL_IO64_CMD). And it doesn't have to, because there is absolutely no need to reuse the existing structures! Quite to the contrary, trying to reuse the structure and opcode makes things confusing as hell. > And that's because this ioctl requires additional "__u64 result;" to > be updated within "struct nvme_passthru_cmd64". > To update that during completion, we need, at the least, the result > field to be a pointer "__u64 result_ptr" inside the struct > nvme_passthru_cmd64. > Do you see that is possible without adding a new passthru ioctl in nvme? We don't need a new passthrough ioctl in nvme. We need to decouple the uring cmd properly. And properly in this case means not to add a result pointer, but to drop the result from the _input_ structure entirely, and instead optionally support a larger CQ entry that contains it, just like the first patch does for the SQ.