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 29BECC5ACB3 for ; Thu, 16 Nov 2023 11:12:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD8E744015D; Thu, 16 Nov 2023 06:12:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B88556B0458; Thu, 16 Nov 2023 06:12:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A78AE44015D; Thu, 16 Nov 2023 06:12:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 972F86B0456 for ; Thu, 16 Nov 2023 06:12:40 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6C886C0C19 for ; Thu, 16 Nov 2023 11:12:40 +0000 (UTC) X-FDA: 81463554480.14.E47712C Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf24.hostedemail.com (Postfix) with ESMTP id 1EE47180004 for ; Thu, 16 Nov 2023 11:12:37 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 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=1700133158; 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=8B8xnhgQUCroBs86VdMR6ZlWeJGY184CE0d85TiYM7c=; b=bdrNAlbjkQcWSACOEpQ9hJSA69YvDBxsRJOVSUPUW+QLlbmaNb0HWa7lKe+IYi+B6WlMCA OnVFPyKsGEEyNe7OHdHaRsg3JIeTNq4SsUiSCgH/XGZmFIirO/KHWmOUqk+4s+horutO0X 7F83AuTNkMtwTKzmjPWAWBq/llMJ4gc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700133158; a=rsa-sha256; cv=none; b=dDGoOyHq4wFez432NRhT3oE+JNoEQL0agrUxZ38VtJ1oobeGuDfvtaZibBWyv1NwOlI0Rc aS2O0uV7fujMVZPKnZW0mhEY0H2QkmWeR2Nw6MjouiUXHjDx5orjxJKB6OxDqNCW4ORxSQ 1jm9jVNAERLVhhOQZDSa4RlPZwx/BUk= Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4SWHS01cx5zvQpM; Thu, 16 Nov 2023 19:12:16 +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; Thu, 16 Nov 2023 19:12:33 +0800 Subject: Re: [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider To: David Ahern , Jason Gunthorpe , Mina Almasry CC: Jakub Kicinski , , , , , Willem de Bruijn , Kaiyuan Zhang , Jesper Dangaard Brouer , Ilias Apalodimas , Eric Dumazet , =?UTF-8?Q?Christian_K=c3=b6nig?= , 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> From: Yunsheng Lin Message-ID: <15c404e4-8efa-cc1c-174f-0752005b6755@huawei.com> Date: Thu, 16 Nov 2023 19:12:33 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 1EE47180004 X-Rspam-User: X-Stat-Signature: etejmnbndgxbiiy9cs97tgcxb13p6g1r X-Rspamd-Server: rspam01 X-HE-Tag: 1700133157-889929 X-HE-Meta: U2FsdGVkX1+rbZ9nPbMc44E7/ORIRMaAddMDxvDyECuaqtRZ3vSEqo5GTSWtTVc3VlfO1b6dm9NEocIo8ja7OZtQxe9wg6HmHEYmc1IlI5j8UtFUHxCZG59rnuFC5wziigofCC8wOD1dVMp5O8Bi6ZBlofFLQT6EsgpsZ+FPZEi0abFDuts4qiNKrsUisYkjRDKP2U4GEcZBC+wVM6XwvPqkLQZaMo15fNy6LPk7yNNBCbUV2rBYiG0K2uPa6rAgT1k+pPtVQhAZ0bA7usEq0GwcBRY8SblMHhPEgIgDpVSwSjNMU1rWYKU0nkEm9xlH0dOPYefJWt0+RT17nUqRoysjhqzh79KlnjWoU/MnC1b0barHuH1UtVGl/OlbVXsqpa9XPRtlpoGBmmONdgz8hZuRboAfKg0drwCI7cEGwH6r9pyPufDikB7rJ6OFKhfShjiPy/gU9ah/qWkM+7yHTcJ2e91LhMsgRA02crlmd9TjAB9kK4J16760m7Lom+I7If/7NiI9pfLgumI85wHu3MGtdu08fO2V0sL4vLMVKNetaXCQtjniTJTXrbafhZpPuZqEK+3np2kdRCh7NIKcSdOd+lR4nq8weEinsHCCWRr6oeZaNMvdEStX3/yxnhHt89lyO78TPhVGArWWD04U1Z150x0oADCUsLQy4u+zoz6XDm1Znlhhfkfjm4bYKX5uwl3r/0UEfzNel41oWtRRChE8SdXFdEahwnEOsJJi4YYSKISIX2Ieq2Gvns0ACM3eshHFgPsSffrXgAhfMGQlI7UrCif1xjEx1RhXHIldPTA2ieuO0LTPRiCfaqqqP+8OBdeh3ebCJsMKyYVNB6AU0DFiQQ99R8kXzj72x/fLHTEccIGTWMjHd/+i2FTm9RiGzvHRnF9ni5QoO7pomQXkxhEf3P0l5UWzcnC/vAMWepFbr/sUkQ20mawzgwmHRowwdD/Ql+dVwSyrFmIaEO4 WDazLIV0 r5wCiAXSUcGWgLoobpA36Eawsv2uc/7C3udHku9u/NlBeohtQ3yfmJMGsSqkALar7YzY1q67As2/p5uE5PBYOZdlNgIQEKIg7B3shc3wqCO83FEE9vkKNdF1EmDgGXmiWsbJN6YzSlA+t1nd+Y1zhuuK8lK+TPWt6mRZ3fNWYy7vMmabqzH+Yfcew32mX800uHjTXl8WTYseXpTkvFK02IJLW2g== 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/16 1:57, David Ahern wrote: > On 11/15/23 2:21 AM, Yunsheng Lin wrote: >> On 2023/11/14 21:16, Jason Gunthorpe wrote: >>> On Tue, Nov 14, 2023 at 04:21:26AM -0800, Mina Almasry wrote: >>> >>>> Actually because you put the 'strtuct page for devmem' in >>>> skb->bv_frag, the net stack will grab the 'struct page' for devmem >>>> using skb_frag_page() then call things like page_address(), kmap, >>>> get_page, put_page, etc, etc, etc. >>> >>> Yikes, please no. If net has its own struct page look alike it has to >>> stay entirely inside net. A non-mm owned struct page should not be >>> passed into mm calls. It is just way too hacky to be seriously >>> considered :( >> >> Yes, that is something this patchset is trying to do, defining its own >> struct page look alike for page pool to support devmem. >> > > Networking needs to be able to move away from struct page references. > The devmem and host memory for Rx use cases do not need to be page based. Yes, I am agreed the ultimate goal is to move away from struct page references. But I am not sure if we can do it right away as there still are different types of existing 'struct page' in the netstack, see: https://lore.kernel.org/all/8b7d25eb-1f10-3e37-8753-92b42da3fb34@huawei.com/ > > > . >