Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp29706imm; Wed, 5 Sep 2018 13:10:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaQLZVlx92TzzZ62hcdB8TRRR4AjwwCJArF9BKDZwD1WEnnf9ehsSze6GFvq/d0nMP88k9h X-Received: by 2002:a17:902:8b86:: with SMTP id ay6-v6mr41001341plb.25.1536178240304; Wed, 05 Sep 2018 13:10:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536178240; cv=none; d=google.com; s=arc-20160816; b=GlnnmmYJDRYz45pkiDxaZOwMTAV3/3T7rnHzpkbEstdUecqoFCr32POKaMqOzvZV7Y /WK7P6ukUYldGGnFTo62xkTYu8c0sS0P28uV6WfkWuSTdOkQq8jgwbdzW5NRU/mSXeXo Juxh0aZB8eJFY71mKBLZMQKc+BDIMhgiscFXWPfHXnMdj228UMx+xS7gWF2qaFicwZ9B gWlay2xTYzUpY2Yn23mMkribZh4+7vWX3VKiAxF+CRgavqqSfCZTPRKVL4YagS2rud1K zjA/SLHmo0ovzOYJCOZ00PDCVGQSSNY7oiiEpE57fv6CSiO6KHmQxAEBpP8qKuTOyHhY GHkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=bnuVKeZiKFKR06ttE5NJYMIyZaOSL+2E0SJq64wnciI=; b=EIdjf7fux7wI7zNwXpirqlskUCz7PRYpxGCcrUtP1kiqzlI36EQzwO13EgkcNpj0IF 1E92xjGyaam1x/c9z/QB6BiHXsU9QlYdyunNpJgcuBk6dsKKy7gKo6O8BlUD+IjQJtCw o/R/yypqEm/tbI1Pk3Li4g1bUIKG9h8qpWqBrLX/K/M4rGN1QRhGoO/wdPm04FnEOuIX fXEhOKcgrlPG26Hg37Qz7xsevbZuMuW1vQzAF27/Rojxr3Qtu3dKMgkxHALU3mNiB304 dG5l4vL5qZP9gnCGMCeRJiZ3NwqNuwavy0jbDjZretbOGnTPzuI8EsxoQKahRXQboAaU 9yAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u13-v6si2935799pgg.263.2018.09.05.13.10.22; Wed, 05 Sep 2018 13:10:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727858AbeIFAj7 (ORCPT + 99 others); Wed, 5 Sep 2018 20:39:59 -0400 Received: from verein.lst.de ([213.95.11.211]:47098 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727254AbeIFAj7 (ORCPT ); Wed, 5 Sep 2018 20:39:59 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id E280468D40; Wed, 5 Sep 2018 22:11:52 +0200 (CEST) Date: Wed, 5 Sep 2018 22:11:52 +0200 From: Christoph Hellwig To: Jens Axboe Cc: Christoph Hellwig , Logan Gunthorpe , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, linux-block@vger.kernel.org, Stephen Bates , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?iso-8859-1?B?Suly9G1l?= Glisse , Benjamin Herrenschmidt , Alex Williamson , Christian =?iso-8859-1?Q?K=F6nig?= Subject: Re: [PATCH v5 07/13] block: Add PCI P2P flag for request queue and check support for requests Message-ID: <20180905201152.GA1893@lst.de> References: <20180830185352.3369-1-logang@deltatee.com> <20180830185352.3369-8-logang@deltatee.com> <20180901082812.GB670@lst.de> <5f79c012-c6e1-56bb-62fd-0689181fb2c9@deltatee.com> <59b28977-8f2a-6228-2050-03fae6bdbedd@kernel.dk> <1b4283da-44df-4a02-3167-e295243cef78@deltatee.com> <09258b9b-3aed-9890-b31a-bd70a133966c@kernel.dk> <20180905195647.GA1626@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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 05, 2018 at 01:54:31PM -0600, Jens Axboe wrote: > On 9/5/18 1:56 PM, Christoph Hellwig wrote: > > On Wed, Sep 05, 2018 at 01:45:04PM -0600, Jens Axboe wrote: > >> The point is that the caller doesn't necessarily know where the bio > >> will end up, hence the caller can't fully check if the whole stack > >> supports P2P. > > > > The caller must necessarily know where the bio will end up, as for P2P > > support we need to query if the bio target is P2P capable vs the > > source of the P2P memory. > > Then what's the point of having the check at all? Just an additional little safe guard. If you think it isn't worth it I guess we can just drop it for now.