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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 07266C4332F for ; Tue, 8 Nov 2022 12:44:16 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osNuL-00013c-Dn; Tue, 08 Nov 2022 07:40:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osNtr-0000wG-AY; Tue, 08 Nov 2022 07:40:19 -0500 Received: from ssh.movementarian.org ([139.162.205.133] helo=movementarian.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osNtn-00033A-OA; Tue, 08 Nov 2022 07:40:19 -0500 Received: from movement by movementarian.org with local (Exim 4.95) (envelope-from ) id 1osNtT-005hGC-To; Tue, 08 Nov 2022 12:39:55 +0000 Date: Tue, 8 Nov 2022 12:39:55 +0000 From: John Levon To: Klaus Jensen Cc: Jinhao Fan , qemu-devel , Keith Busch , Stefan Hajnoczi , "open list:nvme" Subject: Re: [PATCH v3 4/4] hw/nvme: add polling support Message-ID: References: <20220827091258.3589230-1-fanjinhao21s@ict.ac.cn> <20220827091258.3589230-5-fanjinhao21s@ict.ac.cn> <3ffebed8-997d-e276-bf4a-c75508b0be11@ict.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.movementarian.org/ Received-SPF: pass client-ip=139.162.205.133; envelope-from=movement@movementarian.org; helo=movementarian.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Fri, Nov 04, 2022 at 07:32:12AM +0100, Klaus Jensen wrote: > On Nov 3 21:19, Jinhao Fan wrote: > > On 11/3/2022 8:10 PM, Klaus Jensen wrote: > > > I agree that the spec is a little unclear on this point. In any case, in > > > Linux, when the driver has decided that the sq tail must be updated, > > > it will use this check: > > > > > > (new_idx - event_idx - 1) < (new_idx - old) > > > > When eventidx is already behind, it's like: > > > > 0 > > 1 <- event_idx > > 2 <- old > > 3 <- new_idx > > 4 > > . > > . > > . > > > > In this case, (new_idx - event_idx - 1) = 3-1-1 = 1 >= (new_idx - old) = > > 3-2=1, so the host won't update sq tail. Where am I wrong in this example? > > That becomes 1 >= 1, i.e. "true". So this will result in the driver > doing an mmio doorbell write. The code is: static inline int nvme_dbbuf_need_event(u16 event_idx, u16 new_idx, u16 old) { return (u16)(new_idx - event_idx - 1) < (u16)(new_idx - old); } which per the above is "return 1 < 1;", or false. So the above case does *not* do an mmio write. No? regards john