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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DD5BC54EBD for ; Fri, 13 Jan 2023 02:19:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 489B48E0002; Thu, 12 Jan 2023 21:19:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4395D8E0001; Thu, 12 Jan 2023 21:19:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 300968E0002; Thu, 12 Jan 2023 21:19:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 209838E0001 for ; Thu, 12 Jan 2023 21:19:26 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D56AB1C5E4D for ; Fri, 13 Jan 2023 02:19:25 +0000 (UTC) X-FDA: 80348169090.06.934DC9C Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf30.hostedemail.com (Postfix) with ESMTP id 6C46980004 for ; Fri, 13 Jan 2023 02:19:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673576362; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VqSpGJ9jYKHk4WjL9cLBIs+QBCAw54JE4I41Zm1zigw=; b=7hR8+lmGpabwjBx0pd3dvYCs0JuQfshUTaSsSeMVgtBwoEBDR8thHve9sd5TkZULXse85e NDXLjk9JXNwy8CPIYxjZ7DJzm66M/gUaXFR/YI3PJlhZFauvpWBaMAHn1MGTYJPRr97//N OGu2t8bJE1CaUf70+Exw/jghadDpBcA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673576362; a=rsa-sha256; cv=none; b=1GdZsKy4OngFwDAYNxmIedbfrxuCEwIr4r1kIWrNrikyNA8OVbsrPuYNn8U0vHXpz8KwNM 4lpCUQkjhpvpOxTcaIDONGVgyH5YSdDE6oGbnSPoV8FWSVMmvsfb+D8MSJp6kj6E0IuZ4F x0zPPcNkXM40zIKMUelyHshE0hbQEb8= Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NtQ6f43y4zRrFK; Fri, 13 Jan 2023 10:17:30 +0800 (CST) Received: from [10.69.30.204] (10.69.30.204) by dggpemm500005.china.huawei.com (7.185.36.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 13 Jan 2023 10:19:14 +0800 Subject: Re: [PATCH v3 00/26] Split netmem from struct page To: Jesper Dangaard Brouer , Matthew Wilcox CC: , Jesper Dangaard Brouer , Ilias Apalodimas , , , Shakeel Butt References: <20230111042214.907030-1-willy@infradead.org> <9cdc89f3-8c00-3673-5fdb-4f5bebd95d7a@redhat.com> From: Yunsheng Lin Message-ID: <9857b63e-5f7d-e45a-d837-bae8737c3c55@huawei.com> Date: Fri, 13 Jan 2023 10:19:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <9cdc89f3-8c00-3673-5fdb-4f5bebd95d7a@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6C46980004 X-Stat-Signature: 3x5t3sjmrexwye9uowxep1r8oc9mpz34 X-Rspam-User: X-HE-Tag: 1673576360-180942 X-HE-Meta: U2FsdGVkX1+NmbRNmvGJOgoF/ftJnrPJi0LBlWZlwS72Uw1egMkkAAIn2a2SH6RRa7uA8tFO4k5zmDyUTLVz1wXaRHvy8y30HGJdOEBP4xemXEiYXFdmF5Hc4pic0++0M2oYrow6s/rZ7D8DdTq3nfoFLf3q9XIB+QqmHw+rXvOmya6x4Ovn5b73TV3sYlaExqWmBwB5TCmKPVN6syBpWFMoTJkwREaGyTVXsvsdapC46I17qPn08Il+IF56tkIEZwMb4gv1eg5bqYoqxsx19kvdIN9auXDr67ZCyUiHIo0j0wcbV8pEcJZ+GpisWQg/cJBFOJxcXcfCYec8XMVMmaODJwqb7x0/DgXBNXBLiXyM1esVXIv2LRtlLgPWGzCYmVUS55SLyU/dKt4e9fo5YogN6gqN8cLG+amsyskUudUneKIXJak1nsbqLQmWh907vkJGDy17lkhsde2Rse652XbbF9nWOdyEjSZmC0AQQ3Wa0EKcGCeVBfziep31y4tarG+2ttQwwzhaVmtL40ul7krqSPRlSykMyJtY92sj6QiFXIeH2tZmGkUrPp1Ur8dOzNafWGLKbz0eMPk5WzfVrHXbQo87H+kgA8I0yTKxkhLivclJ8XrWME7h1arczu76gKvg3AUbiNV3jQUAkjbQsEbj25hcEQ6hMLID7y7/AyWBgZymWWmzGG9Az7moVS1y0P0obsiuqli9pDWbq4iNgAxTPM64hxXGpfh23mZOZ0RgzGZerlVxIYUPiArOFtoMM/B47vN03g07pj+nyjoQGCgVDg3PWP4BwPhwuu8xSzt1VSQ1ZJrbsb87HmfehzFlMYDpgbdhtSg= 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 2023/1/12 18:15, Jesper Dangaard Brouer wrote:> On 11/01/2023 14.21, Matthew Wilcox wrote: >> On Wed, Jan 11, 2023 at 04:25:46PM +0800, Yunsheng Lin wrote: >>> On 2023/1/11 12:21, Matthew Wilcox (Oracle) wrote: >>>> The MM subsystem is trying to reduce struct page to a single pointer. >>>> The first step towards that is splitting struct page by its individual >>>> users, as has already been done with folio and slab. This patchset does >>>> that for netmem which is used for page pools. >>> As page pool is only used for rx side in the net stack depending on the >>> driver, a lot more memory for the net stack is from page_frag_alloc_align(), >>> kmem cache, etc. >>> naming it netmem seems a little overkill, perhaps a more specific name for >>> the page pool? such as pp_cache. >>> >>> @Jesper & Ilias >>> Any better idea? > > I like the 'netmem' name. Fair enough. I just pointed out why netmem might not be appropriate when we are not figuring out how netmem will work through the whole networking stack yet. It is eventually your and david/jakub's call to decide the naming anyway. > >>> And it seem some API may need changing too, as we are not pooling 'pages' >>> now. > > IMHO it would be overkill to rename the page_pool to e.g. netmem_pool. > as it would generate too much churn and will be hard to follow in git > as the code filename page_pool.c would also have to be renamed. > It guess we keep page_pool for historical reasons ;-) I think this is a matter of conflict between backward and forward maintainability. IMHO we should prefer forward maintainability over backward maintainability. And greg offers a possible way to fix the backport problem: https://www.spinics.net/lists/kernel/msg4648826.html For git history, I suppose that is a pain we have to pay for the future maintainability. > >> I raised the question of naming in v1, six weeks ago, and nobody had >> any better names. Seems a little unfair to ignore the question at first >> and then bring it up now. I'd hate to miss the merge window because of >> a late-breaking major request like this. >> >> https://lore.kernel.org/netdev/20221130220803.3657490-1-willy@infradead.org/ >> >> I'd like to understand what we think we'll do in networking when we trim >> struct page down to a single pointer, All these usages that aren't from >> page_pool -- what information does networking need to track per-allocation? >> Would it make sense for the netmem to describe all memory used by the >> networking stack, and have allocators other than page_pool also return >> netmem, > > This is also how I see the future, that other netstack "allocators" can > return and work-with 'netmem' objects. IMHO we are already cramming I am not sure how "other netstack 'allocators' can return and work-with 'netmem' objects" works, I suppose putting different union for different allocators in struct netmem like struct page does? Isn't that bringing the similar problem Matthew is trying to fix in this patchset? > too many use-cases into page_pool (like the frag support Yunsheng > added). IMHO there are room for other netstack "allocators" that can I do not understand why frag support is viewed as "cramming use-cases to page pool". In my defence, the frag support for rx is fix in the page pool, it just extend the page pool to return smaller buffer than before. If I create other allocator for that, I might invent a lot of wheel page pool already invented. > utilize netmem. The page_pool is optimized for RX-NAPI workloads, using > it for other purposes is a mistake IMHO. People should create other > netstack "allocators" that solves their specific use-cases. E.g. The TX > path likely needs another "allocator" optimized for this TX use-case. >