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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6D4CDC54E5D for ; Thu, 14 Mar 2024 03:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=aoKBKj8KilraxshgAcULgOI/OFYBC4+FD08MBVlYwPs=; b=UDLY/naDJ7N8vc I/HXkl94pkx0SDQLLc9DgNznJ7VgviXh9y6JcAoF12IaeuVXKyGOpvPaFxfga08GPwxFUhPPDMUxr UfkI4PLn/TBVhf66BA3cUE1TNmsbIBTjp35RfSOEmyO+kB0HD8iMQrhjj2iCsnTJhpoiyAnGbGHLv 5vUZvs1jCriZejXTWiOEQeOVL27w98weRnhd9kGh/Fz0h4mxRqGzaA4vQMN+v3n93Dwzkj28Yc8D/ hyZqszmtqjk/rafYSz65MRVgG9OWSU+PW+d93G7vCFw9PGQBLsxa607HljSwmj4o4I1E6bpUyeGbY pq7tCOROjrWqPT015iIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkbwW-0000000Cpat-2SMA; Thu, 14 Mar 2024 03:39:44 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rkbwT-0000000CpaH-2zZQ for linux-riscv@lists.infradead.org; Thu, 14 Mar 2024 03:39:43 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B64D1CE1A7E; Thu, 14 Mar 2024 03:39:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 821A1C433C7; Thu, 14 Mar 2024 03:39:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710387579; bh=TuxkWK7dMQI2KIPAcDcm4V21xNZ8im/k/MzYg+G5fkA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WVadQJjbFZWBHG8GHuRdNgykOmEZ6ttbZpUFa7bbjwG33qWdzE9Ps3YMtBVDcmDrT AZhleZ2b5KGHZn6mlT+Ppl91rUD3fmzePpss0CcononvFMwAVQWsJueQXgOAcWisW6 17TNVXGujlARAFx0dOClWZVRo9M5ZdB8GrztoFCUfZ6mOc4ioQL7YyrbNJJYsMUY2q 2QHvBR6ErUNomLNV7PYbHWa+EUGBF8CzpjKQY9a4ulHPZ//c+BMcSOcLBEDYj5eXxA 4vVRN7V0xAFFYJtaN07PZu3jgBrVyMmttjepaDsCj0AJQlm/w3phUmnxLOKmeyXXra IrNmeu+2wKGkQ== Date: Wed, 13 Mar 2024 21:39:34 -0600 From: Keith Busch To: Kevin Xie Cc: Lorenzo Pieralisi , Palmer Dabbelt , Minda Chen , Conor Dooley , "kw@linux.com" , "robh+dt@kernel.org" , "bhelgaas@google.com" , "tglx@linutronix.de" , "daire.mcnamara@microchip.com" , "emil.renner.berthing@canonical.com" , "krzysztof.kozlowski+dt@linaro.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-pci@vger.kernel.org" , Paul Walmsley , "aou@eecs.berkeley.edu" , "p.zabel@pengutronix.de" , Mason Huo , Leyfoon Tan Subject: Re: [PATCH v15,RESEND 22/23] PCI: starfive: Offload the NVMe timeout workaround to host drivers. Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240313_203941_951304_C2D52601 X-CRM114-Status: UNSURE ( 5.89 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, Mar 13, 2024 at 08:51:29PM -0600, Keith Busch wrote: > I suppose we could quirk a non-posted transaction in the interrupt > handler to force flush pending memory updates, but that will noticeably > harm your nvme performance. Maybe if you constrain such behavior to the > spurious IRQ_NONE condition, then it might be okay? I don't know. Hm, that may not be good enough: if nvme completions can be reordered with their msi's, then I assume data may reorder with their completion. Your application will inevitably see stale and corrupted data, so it sounds like you need some kind of barrier per completion. Ouch! _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv