Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1812709imu; Thu, 17 Jan 2019 03:45:06 -0800 (PST) X-Google-Smtp-Source: ALg8bN5BlP6Vq+WvG7OnCfqEug9itirUypXOT0YfVLJBxHxO9zL8qn24/22thTCGqr+35c83j54d X-Received: by 2002:a17:902:9047:: with SMTP id w7mr14762830plz.270.1547725506455; Thu, 17 Jan 2019 03:45:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547725506; cv=none; d=google.com; s=arc-20160816; b=0o3O5bT1E6e+bd20FnuAaxYGcqgBOBi94oltW/1A9qQws5lusfKVgVMqteIl16L495 eXxrDcQBSDOyaaW3Z4eP1vATYmwIAx3gLVFZG/Y0d15AUiFJMSUCoUcBQikgQY7FzafM Jn61FrNnE5ZeTzl8bLWw3A2r1pLGdFigrFbMyh+MQlzkbLLCgejwPd4d3x9+lu2AtQI1 qAzqd5Sa/eRdZwV/foNT3ppI78ZcbHlPfy2X/IPmbewVJi0bmEZ3KlB+7X4s76IfubPK LlvaVIACweTPspO4ZygvxkclGipntXxIPf7aDaAvAyn9GT+hOYbQqvK28iddIY+1WW+I hojg== 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=fNoveunpswuxV4esEn/S6DHmeHGHArN/JjVt1G3ye00=; b=n0cGFAKekThbl+Gw4C1nFVpaWGu7fw3wNdFnyDrBZk/jwpNY/Sh9ZNmt+hU67CTCOI 01C+qvK6YY+F0C5nGipwnWtnksPFUoAdjB54OhlQ9yEmQSOjlCDsk1Fo/5JhoM89Icxj 0G924Pi+g83DaCoS3gv6MU3omYRaIoW2iiFWZFLU5nEWnDHC88tI2ZvzAzcLbCo8mFve UjlfFGRuoLVbBdz8EMIY69Mv3XNXiHAKtMSh9YULzVo2/EI5mR7GRpfALsYrbzFgo2pO SSLgPJdSHqfquf6tys+xKN5lVQuJaNoD4BEgR8k6qCjEtSPZh3j/CLHMl7Qs46G6hLIX WSpw== 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 e25si1241570pgv.486.2019.01.17.03.44.51; Thu, 17 Jan 2019 03:45:06 -0800 (PST) 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 S1728724AbfAQJaE (ORCPT + 99 others); Thu, 17 Jan 2019 04:30:04 -0500 Received: from verein.lst.de ([213.95.11.211]:36339 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727194AbfAQJaD (ORCPT ); Thu, 17 Jan 2019 04:30:03 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 2C7566F9C5; Thu, 17 Jan 2019 10:30:02 +0100 (CET) Date: Thu, 17 Jan 2019 10:30:01 +0100 From: "hch@lst.de" To: Jason Gunthorpe Cc: "hch@lst.de" , Thomas Hellstrom , "linux-kernel@vger.kernel.org" , "yong.zhi@intel.com" , "daniel.vetter@ffwll.ch" , "linux-rdma@vger.kernel.org" , "syeh@vmware.com" , "linux-media@vger.kernel.org" , "bingbu.cao@intel.com" , "imre.deak@intel.com" , "tian.shu.qiu@intel.com" , "jian.xu.zheng@intel.com" , "shiraz.saleem@intel.com" , "sakari.ailus@linux.intel.com" , "dri-devel@lists.freedesktop.org" Subject: Re: [PATCH] lib/scatterlist: Provide a DMA page iterator Message-ID: <20190117093001.GB31303@lst.de> References: <20190104223531.GA1705@ziepe.ca> <20190110234218.GM6890@ziepe.ca> <20190114094856.GB29604@lst.de> <1fb20ab4b171b281e9994b6c55734c120958530b.camel@vmware.com> <20190115212501.GE22045@ziepe.ca> <20190116161134.GA29041@lst.de> <20190116172436.GM22045@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190116172436.GM22045@ziepe.ca> 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, Jan 16, 2019 at 10:24:36AM -0700, Jason Gunthorpe wrote: > The fact is there is 0 industry interest in using RDMA on platforms > that can't do HW DMA cache coherency - the kernel syscalls required to > do the cache flushing on the IO path would just destroy performance to > the point of making RDMA pointless. Better to use netdev on those > platforms. In general there is no syscall required for doing cache flushing, you just issue the proper instructions directly from userspace. > The reality is that *all* the subsytems doing DMA kernel bypass are > ignoring the DMA mapping rules, I think we should support this better, > and just accept that user space DMA will not be using syncing. Block > access in cases when this is required, otherwise let it work as is > today. In that case we just need to block userspace DMA access entirely. Which given the amount of problems it creates sounds like a pretty good idea anyway.