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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E29E6CEBF97 for ; Fri, 27 Sep 2024 11:29:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 841B1614D9; Fri, 27 Sep 2024 11:29:33 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id ix0znW7s42-2; Fri, 27 Sep 2024 11:29:32 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 96B16614DC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1727436572; bh=f/WFEz0A5bvXUvo45jjUU1d1+FxqRULkPKv8aYb2Y+c=; h=Date:To:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=1Kv9ddgcTc6+afYKysJUBjDcdtdzYPfAmKamPth2VLEkU73XVTtpIzChZXdIhvujd QuvO5P7ADRtJfBaiS72Ur5R6HEvxgNK2POGbVbhSKbPQE9L1GTNgw3cb3rrWA5d94r hdBgzmqUPl4WB5AGzSQ0fo26lpjgxN5PJaJZYQue6EVW6XIF4KDQG33P96slY6qzdN VqcUT8YZComQzcgZmxaMj9Ji1x3P3wXA1jO+EzTdY9pYm1jKpaE/m3gAR2LHhw1XS0 NxLwgzGReL8ispEcpIkNdcGov+eKCFh8qzdGm9MqoqLMVhZo1HbVY+msFq3MEteVwH L1McTa+FcSWVQ== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp3.osuosl.org (Postfix) with ESMTP id 96B16614DC; Fri, 27 Sep 2024 11:29:32 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 1128A1BF3ED for ; Fri, 27 Sep 2024 11:29:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id F1D8942526 for ; Fri, 27 Sep 2024 11:29:30 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id uAhbkjCGuVwL for ; Fri, 27 Sep 2024 11:29:29 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=45.249.212.191; helo=szxga05-in.huawei.com; envelope-from=linyunsheng@huawei.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp4.osuosl.org BEAAB4251F DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BEAAB4251F Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by smtp4.osuosl.org (Postfix) with ESMTPS id BEAAB4251F for ; Fri, 27 Sep 2024 11:29:28 +0000 (UTC) Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4XFSrx2nMcz2QTtc; Fri, 27 Sep 2024 19:28:33 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 2ACA31A016C; Fri, 27 Sep 2024 19:29:23 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 27 Sep 2024 19:29:22 +0800 Message-ID: <934d601f-be43-4e04-b126-dc86890a4bfa@huawei.com> Date: Fri, 27 Sep 2024 19:29:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Ilias Apalodimas References: <20240925075707.3970187-1-linyunsheng@huawei.com> <20240925075707.3970187-3-linyunsheng@huawei.com> <842c8cc6-f716-437a-bc98-70bc26d6fd38@huawei.com> <0ef315df-e8e9-41e8-9ba8-dcb69492c616@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf200006.china.huawei.com (7.185.36.61) X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Subject: Re: [Intel-wired-lan] [PATCH net v2 2/2] page_pool: fix IOMMU crash when driver has already unbound X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: imx@lists.linux.dev, Alexei Starovoitov , Alexander Duyck , linux-mm@kvack.org, Eric Dumazet , Tony Nguyen , Shenwei Wang , Mina Almasry , Ryder Lee , Daniel Borkmann , linux-rdma@vger.kernel.org, Przemek Kitszel , John Fastabend , IOMMU , liuyonglong@huawei.com, Clark Wang , zhangkun09@huawei.com, fanghaiqing@huawei.com, pabeni@redhat.com, Lorenzo Bianconi , Jesper Dangaard Brouer , Kalle Valo , Sean Wang , Wei Fang , kuba@kernel.org, Matthias Brugger , intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , Leon Romanovsky , Robin Murphy , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Tariq Toukan , Alexander Lobakin , netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, Andrew Morton , Shayne Chen , Saeed Mahameed , davem@davemloft.net, Felix Fietkau Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On 2024/9/27 17:58, Ilias Apalodimas wrote: ... >> >>> importantly, though, why does struct page need to know about this? >>> Can't we have the same information in page pool? >>> When the driver allocates pages it does via page_pool_dev_alloc_XXXXX >>> or something similar. Cant we do what you suggest here ? IOW when we >>> allocate a page we put it in a list, and when that page returns to >>> page_pool (and it's mapped) we remove it. >> >> Yes, that is the basic idea, but the important part is how to do that >> with less performance impact. > > Yes, but do you think that keeping that list of allocated pages in > struct page_pool will end up being more costly somehow compared to > struct page? I am not sure if I understand your above question here. I am supposing the question is about what's the cost between using single/doubly linked list for the inflight pages or using a array for the inflight pages like this patch does using pool->items? If I understand question correctly, the single/doubly linked list is more costly than array as the page_pool case as my understanding. For single linked list, it doesn't allow deleting a specific entry but only support deleting the first entry and all the entries. It does support lockless operation using llist, but have limitation as below: https://elixir.bootlin.com/linux/v6.7-rc8/source/include/linux/llist.h#L13 For doubly linked list, it needs two pointer to support deleting a specific entry and it does not support lockless operation. For pool->items, as the alloc side is protected by NAPI context, and the free side use item->pp_idx to ensure there is only one producer for each item, which means for each item in pool->items, there is only one consumer and one producer, which seems much like the case when the page is not recyclable in __page_pool_put_page, we don't need a lock protection when calling page_pool_return_page(), the 'struct page' is also one consumer and one producer as the pool->items[item->pp_idx] does: https://elixir.bootlin.com/linux/v6.7-rc8/source/net/core/page_pool.c#L645 We only need a lock protection when page_pool_destroy() is called to check if there is inflight page to be unmapped as a consumer, and the __page_pool_put_page() may also called to unmapped the inflight page as another consumer, there is why the 'destroy_lock' is added for protection when pool->destroy_cnt > 0. > > Thanks > /Ilias