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 2BB56C07548 for ; Wed, 15 Nov 2023 09:29:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AB556B032E; Wed, 15 Nov 2023 04:29:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55B456B0332; Wed, 15 Nov 2023 04:29:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4224C6B0333; Wed, 15 Nov 2023 04:29:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 303026B032E for ; Wed, 15 Nov 2023 04:29:42 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 00CAF120238 for ; Wed, 15 Nov 2023 09:29:41 +0000 (UTC) X-FDA: 81459666204.23.C74669A Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf11.hostedemail.com (Postfix) with ESMTP id F377140007 for ; Wed, 15 Nov 2023 09:29:37 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700040578; 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=YrmRZa9fT56NhG3jkJxIVFhbvpfb86pXSjKwwoCUHEs=; b=EvmdpSTPqsWQdEXeChfivmFPPSjIc3fqXh5lEDV4vAvvqbVRnS0TyyPp10DDrT2V3bdHky v/E4A9B+mdTTTMzCx10AMMRvhzBe156EwnTy5SR0dsvBPGYcTapPhhF0GoN+qzc3mzVrQ0 7OqQM5L8/2Ei7lnLJ/sfzCcJ2uwywUg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700040578; a=rsa-sha256; cv=none; b=E3YnRzmH6TS4f6Kq5bUNLZOWcfnnCKcC2jSPMJZ7WiWXo32nTK4FxP25Q8KAPVh198Luvg qiPCUcoFnNMoUZRKAXVPI0V6wqCQFq5y6i0bGbhoSJnUxOweSatIg8xx5gnetcsy5sBmQx Tc6H0LuWnP0R+m68+ultUOMOHo1SXQI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4SVd6n2G6vzNm6J; Wed, 15 Nov 2023 17:25:05 +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.2507.31; Wed, 15 Nov 2023 17:29:17 +0800 Subject: Re: [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider To: Willem de Bruijn , Mina Almasry CC: Jakub Kicinski , , , , , Willem de Bruijn , Kaiyuan Zhang , Jesper Dangaard Brouer , Ilias Apalodimas , Eric Dumazet , =?UTF-8?Q?Christian_K=c3=b6nig?= , Jason Gunthorpe , Matthew Wilcox , Linux-MM References: <20231113130041.58124-1-linyunsheng@huawei.com> <20231113130041.58124-4-linyunsheng@huawei.com> <20231113180554.1d1c6b1a@kernel.org> <0c39bd57-5d67-3255-9da2-3f3194ee5a66@huawei.com> <3ff54a20-7e5f-562a-ca2e-b078cc4b4120@huawei.com> <6553954141762_1245c529423@willemb.c.googlers.com.notmuch> From: Yunsheng Lin Message-ID: <8b7d25eb-1f10-3e37-8753-92b42da3fb34@huawei.com> Date: Wed, 15 Nov 2023 17:29:17 +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: <6553954141762_1245c529423@willemb.c.googlers.com.notmuch> 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-Queue-Id: F377140007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: uesby59xkhdrznqxo1xp9hnudohe5aq9 X-HE-Tag: 1700040577-976577 X-HE-Meta: U2FsdGVkX1+Z8FwJjlDSrBP/D9q0snmIJpzD3GYeY1ZqHA1B2S+QCjhwBRO+s1cfExcWDTTpPVpsnp5wC+ahUxNG0jtpCfXRr9d6H6zERdxyeb7YGovJ1PoPl3vdRxd7MDVWWbRFeTIQ6OYUhAgtptf/85MmmqeBO7+m7k4mq9SeLk5V/5N3vMg1+LGw+Ofa2jgi9YluCAIn1mbI/Y5hwYC63vvfALB5rIPy+M/CLg+RSz8TRaw1lVpiV9yZx5vCZNayxBZAg1MzsUwBcklww2dq840wD59/IVo+PzngUoixbidvwu9NX1oNGWA+VokcHDk6rOA3AxyR+4wBjv0Xi6A1quFMqgaPEn41ObmDa33sZJCs6I/wWdhMYllF1XCu9KSJFwKNSvT6dgy99qjMRO57XgeHbLg0uAQSZbPCxwSIHxOhVNtAMy440RIzJWNnLuumQ9OLvaHiPGs1lk74S6y7rdQnFZsRGo+MAdj9ZDuBpR1IL548X2tZNRbncJOMNlaGpErzO+8w7wTvn9+Pu1jhJLTW7kGxTH16dA2WDHcUA4A/VUoZ0DLqJzJVyXp6YER3qNN7/TIWd1rHcs/2b7WoirWOx42TN3RqW6Ik5qAtBYzjRdHOSSmjsOA+VB49srSDuTJyeC4zfR61dCMv9vXQhEwhJvAS5WssY6sqDmopZ6HeOY8ZLyRb47QhEcVq+FdDen7VVUOvTyqdRth4vBFaF+059vbaeNkpiUP5U0IR1kwWvsCJ1m889PAkskRJKLz1jcMY0ckxXtqq+tegOUMnpQ9rZkHYh36ulLE0VzlZsIezwPBlGVfVVLGm0XhAHfBAJjTM4uMAh5WYjTg9oa9hgmCRrwXEvYi0hVZjEspsdaDEBQyCKvyrVWQePgQu3EN+eFObUAh9blbof8k9krc4o+Y3pPhnOjYBhs/KiwHDEmg6bjJAtdogeRBzBP+v+lUJjyp6ib1DkJJ7aCM 9RjQpsIl d06HkFtaC+pLk+pL7t4lBC5b376z8q92pWkAOnxWbdNEam/OVaehBhdpO6yYAExx6QsP0GugAliZFGy0cKUGdMVyXHuWsoTURohPdo065DeU5t3zQatmn+PTuHRnFtlPWHcLWK6lYrAWUub/87c6UNqytUYOggw6Ir984jZjQCKiqK8UmDxxAQd+7EAuZco3pNCMkthsyx3avJs3wFiedpzqC69dKqyKM2Hzux5J8yOxzKbRo5+zzr5hUh1t4Pos4iUvngkwndehdFqo6tDiw/QlXOL4k9nO5ofPQuKJqe6k+dXStgz0uQ8+EfXw0WXJXDz46N/TG0ByM1VeljTdQO1db1h8jThWLV7QvS8oIyBQsQxtzR4Vo5NN03W8Rs5UXR9eR 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: List-Subscribe: List-Unsubscribe: On 2023/11/14 23:41, Willem de Bruijn wrote: >> >> I am not sure dma-buf maintainer's concern is still there with this patchset. >> >> Whatever name you calling it for the struct, however you arrange each field >> in the struct, some metadata is always needed for dmabuf to intergrate into >> page pool. >> >> If the above is true, why not utilize the 'struct page' to have more unified >> handling? > > My understanding is that there is a general preference to simplify struct > page, and at the least not move in the other direction by overloading the > struct in new ways. As my understanding, the new struct is just mirroring the struct page pool is already using, see: https://elixir.free-electrons.com/linux/v6.7-rc1/source/include/linux/mm_types.h#L119 If there is simplifying to the struct page_pool is using, I think the new stuct the devmem memory provider is using can adjust accordingly. As a matter of fact, I think the way 'struct page' for devmem is decoupled from mm subsystem may provide a way to simplify or decoupled the already existing 'struct page' used in netstack from mm subsystem, before this patchset, it seems we have the below types of 'struct page': 1. page allocated in the netstack using page pool. 2. page allocated in the netstack using buddy allocator. 3. page allocated in other subsystem and passed to the netstack, such as zcopy or spliced page? If we can decouple 'struct page' for devmem from mm subsystem, we may be able to decouple the above 'struct page' from mm subsystem one by one. > > If using struct page for something that is not memory, there is ZONE_DEVICE. > But using that correctly is non-trivial: > > https://lore.kernel.org/all/ZKyZBbKEpmkFkpWV@ziepe.ca/ > > Since all we need is a handle that does not leave the network stack, > a network specific struct like page_pool_iov entirely avoids this issue. Yes, I am agree about the network specific struct. I am wondering if we can make the struct more generic if we want to intergrate it into page_pool and use it in net stack. > RFC v3 seems like a good simplification over RFC v1 in that regard to me. > I was also pleasantly surprised how minimal the change to the users of > skb_frag_t actually proved to be. Yes, I am agreed about that too. Maybe we can make it simpler by using a more abstract struct as page_pool, and utilize some features of page_pool too. For example, from the page_pool doc, page_pool have fast cache and ptr-ring cache as below, but if napi_frag_unref() call page_pool_page_put_many() and return the dmabuf chunk directly to gen_pool in the memory provider, then it seems we are bypassing the below caches in the page_pool. +------------------+ | Driver | +------------------+ ^ | | | v +--------------------------------------------+ | request memory | +--------------------------------------------+ ^ ^ | | | Pool empty | Pool has entries | | v v +-----------------------+ +------------------------+ | alloc (and map) pages | | get page from cache | +-----------------------+ +------------------------+ ^ ^ | | | cache available | No entries, refill | | from ptr-ring | | v v +-----------------+ +------------------+ | Fast cache | | ptr-ring cache | +-----------------+ +------------------+ > > . >