Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp434657rwl; Thu, 6 Apr 2023 22:57:45 -0700 (PDT) X-Google-Smtp-Source: AKy350aNnz+Nnk6EeLY0MWQuHZptopJd5Vo9XpQb0dprYwnBYAnHf6Sw19h0Nat24N1NA0e85F2/ X-Received: by 2002:a17:903:27c8:b0:1a4:fffa:b99f with SMTP id km8-20020a17090327c800b001a4fffab99fmr1548540plb.14.1680847065339; Thu, 06 Apr 2023 22:57:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680847065; cv=none; d=google.com; s=arc-20160816; b=gKzTvyjfyFtmpG9WAkjqlaPfn/0G6RjKi6dFNJGhHBRBuVf+i6Fq9tUXzqDVO2ei+/ Bpns3ztTtsI3ykyeUFzLPhYtHWvgFOjHdiyPz3izBJJuzLskc0oChWSTbcdSJNKDBwA0 Qs7YwATeggwPVSA3YBg5bxgvIDfcKag+rvAi0iMgIXPBT8KzNRQIVUQCQQ6XGw4TbQVA 3MnLRUv/l8/08UzHMRYwZBoVNorWZRdxjD0jYOQ/szf+1ULmcv7dr8teyiclyGfiaphM YMz7rSdFVdwauRYgJf8Q0mjmIEtWTY7y1WUgYJY9hbSI144A4NCWlXox/N3+6/QdYeBf 4cxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=UHeGkLxJp8EXTf4GMkuuC+0GWwr0KEAlWhmGp92W/vs=; b=C/Gv+PQhNb7VJyl8L41rLC6Uv2mJUYw6JoDz3isu+xNlh71+ZFkeFk0+mAPnak8ion oi2AbRUT4wT5p477R12YpvBXNLwVqxB+QTJy+GQGxBx9b0TMsY7V0it+slzrznsY3x3S 5WDp8Ev66hpR6T9fCtQWi6wHvTUEHWkej8Dy6d2gPtZ20tEqx3jV8kgP+GJGdxS52axH vABF2dnsRZEN1mtuhwfZKcwr9c+6WIvNaSbs1/Y+f5Cf7NViE6HbyY5TfsggBsNbB4FJ H6YDZ2W6388dDUi3AUPVtsry5Z0rE/+nwN6SgGTPGMN7voZ+F4QNHdHkUi8C2iiciJWV gUfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u1-20020a170902bf4100b001a1f8e130f9si131332pls.472.2023.04.06.22.57.34; Thu, 06 Apr 2023 22:57:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232559AbjDGF5J (ORCPT + 99 others); Fri, 7 Apr 2023 01:57:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231210AbjDGF5I (ORCPT ); Fri, 7 Apr 2023 01:57:08 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78339C5; Thu, 6 Apr 2023 22:57:07 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 63FA868AFE; Fri, 7 Apr 2023 07:57:04 +0200 (CEST) Date: Fri, 7 Apr 2023 07:57:04 +0200 From: Christoph Hellwig To: Petr Tesarik Cc: Christoph Hellwig , Jonathan Corbet , Marek Szyprowski , Robin Murphy , Borislav Petkov , "Paul E. McKenney" , Andrew Morton , Randy Dunlap , Damien Le Moal , Kim Phillips , "Steven Rostedt (Google)" , "open list:DOCUMENTATION" , open list , "open list:DMA MAPPING HELPERS" , Roberto Sassu , petr@tesarici.cz, Alexander Graf Subject: Re: [RFC v1 3/4] swiotlb: Allow dynamic allocation of bounce buffers Message-ID: <20230407055704.GD6803@lst.de> References: <0334a54332ab75312c9de825548b616439dcc9f5.1679309810.git.petr.tesarik.ext@huawei.com> <20230328040724.GB25506@lst.de> <4268fa4e-4f0f-a2f6-a2a5-5b78ca4a073d@huaweicloud.com> <8cf7c515-9ce6-a2ed-0643-972aa3eba2fb@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cf7c515-9ce6-a2ed-0643-972aa3eba2fb@huaweicloud.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 28, 2023 at 02:43:03PM +0200, Petr Tesarik wrote: > Oh, wait! I can do at least something for devices which do not use > swiotlb at all. > > If a device does not use bounce buffers, it cannot pass an address > that belongs to the swiotlb. Consequently, the potentially > expensive check can be skipped. This avoids the dynamic lookup > penalty for devices which do not need the swiotlb. > > Note that the counter always remains zero if dma_io_tlb_mem is > NULL, so the NULL check is not required. Hmm, that's yet another atomic for each map/unmap, and bloats struct device. (Btw, in case anyone is interested, we really need to get started on moving the dma fields out of struct device into a sub-struct only allocated for DMA capable busses)