Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753732AbbKGA6n (ORCPT ); Fri, 6 Nov 2015 19:58:43 -0500 Received: from mga14.intel.com ([192.55.52.115]:5368 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbbKGA6k (ORCPT ); Fri, 6 Nov 2015 19:58:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,254,1444719600"; d="scan'208";a="813841362" Date: Sat, 7 Nov 2015 00:58:24 +0000 From: Keith Busch To: "Elliott, Robert (Persistent Memory)" Cc: Jens Axboe , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "hch@infradead.org" Subject: Re: [PATCH 4/5] NVMe: add blk polling support Message-ID: <20151107005824.GC15185@localhost.localdomain> References: <1446830423-25027-1-git-send-email-axboe@fb.com> <1446830423-25027-5-git-send-email-axboe@fb.com> <94D0CD8314A33A4D9D801C0FE68B40295BE10552@G4W3202.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B40295BE10552@G4W3202.americas.hpqcorp.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 47 On Fri, Nov 06, 2015 at 03:46:07PM -0800, Elliott, Robert (Persistent Memory) wrote: > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > > owner@vger.kernel.org] On Behalf Of Jens Axboe > > Sent: Friday, November 6, 2015 11:20 AM > ... > > Subject: [PATCH 4/5] NVMe: add blk polling support > > > > Add nvme_poll(), which will check a specific completion queue for > > command completions. Wire that up to the new block layer poll > > mechanism. > > > > Later on we'll setup specific sq/cq pairs that don't have interrups > > enabled, so we can do more efficient polling. As of this patch, an > > IRQ will still trigger on command completion. > ... > > -static int nvme_process_cq(struct nvme_queue *nvmeq) > > +static void __nvme_process_cq(struct nvme_queue *nvmeq, unsigned int > > *tag) > > { > > u16 head, phase; > > > > @@ -953,6 +953,8 @@ static int nvme_process_cq(struct nvme_queue *nvmeq) > > head = 0; > > phase = !phase; > > } > > + if (tag && *tag == cqe.command_id) > > + *tag = -1; > > ctx = nvme_finish_cmd(nvmeq, cqe.command_id, &fn); > > fn(nvmeq, ctx, &cqe); > > } > > The NVMe completion queue entries are 16 bytes long. Although it's > most likely to write them from 0..15 in one PCIe Memory Write > transaction, the NVMe device could write those bytes in any order. > It could thus update the command identifier before the other bytes, > causing this code to process invalid stale values in the other > fields. That's a very interesting point. We are okay if we can rely on the phase bit, which we can by my reading of the spec. Coalescing would not work if the driver can observe a new phase in a partially written CQE. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/