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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 B8F77C282C4 for ; Tue, 12 Feb 2019 10:06:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91F832186A for ; Tue, 12 Feb 2019 10:06:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728454AbfBLKGc (ORCPT ); Tue, 12 Feb 2019 05:06:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56908 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728084AbfBLKGb (ORCPT ); Tue, 12 Feb 2019 05:06:31 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2824C49DDD; Tue, 12 Feb 2019 10:06:30 +0000 (UTC) Received: from carbon (ovpn-200-42.brq.redhat.com [10.40.200.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id CAD275C21A; Tue, 12 Feb 2019 10:06:22 +0000 (UTC) Date: Tue, 12 Feb 2019 11:06:20 +0100 From: Jesper Dangaard Brouer To: Matthew Wilcox Cc: netdev@vger.kernel.org, linux-mm@kvack.org, Toke =?UTF-8?B?SMO4aWxh?= =?UTF-8?B?bmQtSsO4cmdlbnNlbg==?= , Ilias Apalodimas , Saeed Mahameed , Andrew Morton , mgorman@techsingularity.net, "David S. Miller" , Tariq Toukan , brouer@redhat.com, Willem de Bruijn Subject: Re: [net-next PATCH 1/2] mm: add dma_addr_t to struct page Message-ID: <20190212110620.5ceb5366@carbon> In-Reply-To: <20190211165551.GD12668@bombadil.infradead.org> References: <154990116432.24530.10541030990995303432.stgit@firesoul> <154990120685.24530.15350136329514629029.stgit@firesoul> <20190211165551.GD12668@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 12 Feb 2019 10:06:31 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, 11 Feb 2019 08:55:51 -0800 Matthew Wilcox wrote: > On Mon, Feb 11, 2019 at 05:06:46PM +0100, Jesper Dangaard Brouer wrote: > > The page_pool API is using page->private to store DMA addresses. > > As pointed out by David Miller we can't use that on 32-bit architectures > > with 64-bit DMA > > > > This patch adds a new dma_addr_t struct to allow storing DMA addresses > > > > Signed-off-by: Jesper Dangaard Brouer > > Signed-off-by: Ilias Apalodimas > > Reviewed-by: Matthew Wilcox > > > + struct { /* page_pool used by netstack */ > > + /** > > + * @dma_addr: Page_pool need to store DMA-addr, and > > s/need/needs/ > > > + * cannot use @private, as DMA-mappings can be 64-bit > > s/DMA-mappings/DMA addresses/ > > > + * even on 32-bit Architectures. > > s/A/a/ Yes, that comments needs improvement. I think I'll use AKPMs suggestion. > > + */ > > + dma_addr_t dma_addr; /* Shares area with @lru */ > > It also shares with @slab_list, @next, @compound_head, @pgmap and > @rcu_head. I think it's pointless to try to document which other fields > something shares space with; the places which do it are a legacy from > before I rearranged struct page last year. Anyone looking at this should > now be able to see "Oh, this is a union, only use the fields which are > in the union for the type of struct page I have here". I agree, I'll strip that comment. > Are the pages allocated from this API ever supposed to be mapped to > userspace? I would like to know what fields on struct-page we cannot touch if we want to keep this a possibility? That said, I hope we don't need to do this. But as I integrate this further into the netstack code, we might have to support this, or at-least release the page_pool "state" (currently only DMA-addr) before the skb_zcopy code path. First iteration will not do zero-copy stuff, and later I'll coordinate with Willem how to add this, if needed. My general opinion is that if an end-user want to have pages mapped to userspace, then page_pool (MEM_TYPE_PAGE_POOL) is not the right choice, but instead use MEM_TYPE_ZERO_COPY (see enum xdp_mem_type). We are generally working towards allowing NIC drivers to have a different memory type per RX-ring. > You also say in the documentation: > > * If no DMA mapping is done, then it can act as shim-layer that > * fall-through to alloc_page. As no state is kept on the page, the > * regular put_page() call is sufficient. > > I think this is probably a dangerous precedent to set. Better to require > exactly one call to page_pool_put_page() (with the understanding that the > refcount may be elevated, so this may not be the final free of the page, > but the page will no longer be usable for its page_pool purpose). Yes, this actually how it is implemented today, and the comment should be improved. Today __page_pool_put_page() in case of refcount is elevated do call __page_pool_clean_page() to release page page_pool state, and is in principle no longer "usable" for page_pool purposes. BUT I have considered removing this, as it might not fit how want to use the API. In our current RFC we found a need for (and introduced) a page_pool_unmap_page() call (that call __page_pool_clean_page()), when driver hits cases where the code path doesn't have a call-back to page_pool_put_page() but instead end-up calling put_page(). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer