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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 277E3C433ED for ; Mon, 3 May 2021 18:28:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8DC60610FC for ; Mon, 3 May 2021 18:28:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DC60610FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 02D266B0036; Mon, 3 May 2021 14:28:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1E1F6B0070; Mon, 3 May 2021 14:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBEA26B0071; Mon, 3 May 2021 14:28:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id BECDC6B0036 for ; Mon, 3 May 2021 14:28:16 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 80320180AD830 for ; Mon, 3 May 2021 18:28:16 +0000 (UTC) X-FDA: 78100754592.39.BEFD9C3 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf28.hostedemail.com (Postfix) with ESMTP id 618132000241 for ; Mon, 3 May 2021 18:28:16 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 16D2068BEB; Mon, 3 May 2021 20:28:12 +0200 (CEST) Date: Mon, 3 May 2021 20:28:11 +0200 From: Christoph Hellwig To: Jason Gunthorpe Cc: Logan Gunthorpe , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Stephen Bates , Christoph Hellwig , Dan Williams , Christian =?iso-8859-1?Q?K=F6nig?= , John Hubbard , Don Dutile , Matthew Wilcox , Daniel Vetter , Jakowski Andrzej , Minturn Dave B , Jason Ekstrand , Dave Hansen , Xiong Jianxin , Bjorn Helgaas , Ira Weiny , Robin Murphy Subject: Re: [PATCH 05/16] dma-mapping: Introduce dma_map_sg_p2pdma() Message-ID: <20210503182811.GC17174@lst.de> References: <20210408170123.8788-1-logang@deltatee.com> <20210408170123.8788-6-logang@deltatee.com> <20210427193157.GQ2047089@ziepe.ca> <3c9ba6df-750a-3847-f1fc-8e41f533d1a2@deltatee.com> <20210427230113.GV2047089@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210427230113.GV2047089@ziepe.ca> User-Agent: Mutt/1.5.17 (2007-11-01) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=none (imf28.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 618132000241 X-Stat-Signature: w95wmt1x8hysd46qtf15oxhnxpkw84kk Received-SPF: none (lst.de>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=verein.lst.de; client-ip=213.95.11.211 X-HE-DKIM-Result: none/none X-HE-Tag: 1620066496-901478 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 27, 2021 at 08:01:13PM -0300, Jason Gunthorpe wrote: > At a high level I'm OK with it. dma_map_sg_attrs() is the extra > extended version of dma_map_sg(), it already has a different > signature, a different return code is not out of the question. > > dma_map_sg() is just the simple easy to use interface that can't do > advanced stuff. > > > I'm not that opposed to this. But it will make this series a fair bit > > longer to change the 8 map_sg_attrs() usages. > > Yes, but the result seems much nicer to not grow the DMA API further. We already have a mapping function that can return errors: dma_map_sgtable. I think it might make more sense to piggy back on that, as the sg_table abstraction is pretty useful basically everywhere that we deal with scatterlists anyway. In the hopefully no too long run I plan to get rid of scatterlists in at least NVMe and other high performance devices anyway.