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 E9366C07548 for ; Wed, 15 Nov 2023 09:33:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F7EB8D002F; Wed, 15 Nov 2023 04:33:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A7928D001A; Wed, 15 Nov 2023 04:33:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6964C8D002F; Wed, 15 Nov 2023 04:33:36 -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 594D48D001A for ; Wed, 15 Nov 2023 04:33:36 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2269912059D for ; Wed, 15 Nov 2023 09:33:36 +0000 (UTC) X-FDA: 81459676032.29.A503FD4 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf04.hostedemail.com (Postfix) with ESMTP id 8BD2640008 for ; Wed, 15 Nov 2023 09:33:33 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.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=1700040814; 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=VAk3gLOh2KyK8DlMm4i/izxvoyeMOgdTuS4CzJ+BT6M=; b=lM3/RVfkAyUOFCZIT/NoqkXCsVrSCAA4Ul98K69ZlSWq8WzCe4xjLDFfqC9sKFw8euga/o CaVPKIJCtuSbM9qomexpNRdoZ5Dw4fcQdQgOuHXBpyecoqL54T8j7dzKlMJ0A3WuUDi3DM avxpzWq+PYLcayivCH8pJtK0AqeLjyc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.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=1700040814; a=rsa-sha256; cv=none; b=JftbTzWjzxlrwxptQs7BzYEMXvntChJC+Rsdca9FaE4Y7L5JA4lCzInTkUVTmjg8+Ggd3R jhnLTCcPyfgMpL5avVn1sHs1X86BgaLOBaC303IniSeuLeLNa8XvYB/ImQSomLOiUJekAV YaycAs7WYGv8JYa5/tOYRpVikXKXOQA= Received: from dggpemm500005.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4SVdHl2pfNzWh7S; Wed, 15 Nov 2023 17:32:51 +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:33:14 +0800 Subject: Re: [PATCH RFC 3/8] memory-provider: dmabuf devmem memory provider To: Jakub Kicinski CC: Mina Almasry , , , , , 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> <20231114172534.124f544c@kernel.org> From: Yunsheng Lin Message-ID: <56314b48-5273-6885-f3eb-5d60535faba0@huawei.com> Date: Wed, 15 Nov 2023 17:33:13 +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: <20231114172534.124f544c@kernel.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.30.204] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500005.china.huawei.com (7.185.36.74) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 8BD2640008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: cqe1jfmps6okfhowi1znnmj636w8fhqg X-HE-Tag: 1700040813-872490 X-HE-Meta: U2FsdGVkX1/diE6vA9S//mH2mi26uFwSQpHon2tnLJceeeNmJWOVgjRxWsy2UQi8fk6jAlCfS/gx+QSfiqhfl3iMwbjnYkHda0J79ConIxnvdqsMJbifpprzr8sGlk+JxEAjCLXmrSBN8eyjyN2BUaW37pwQojX5JiPVfrnL//NMMkGBfYiS/tEXQNFyMTXi881nS7GzkXQ/Xr0JbJ6Qp/TUgah6MOTpPjPDmqpeaW76QbM/nPw57B+7xvf7lS1yJfbyveDcoCoD6CGJnH8qt09zHsiU+a9EHcDArfqJxhiwo7kmQnhBQp7aZW6IwyZhapzWHq28auZp7YM7lF+VpOCaM5WZMwSjaCDZsF9EGDeD8pT2hmqMh/Z7++rCn8Lf8bU8P7fNfkssqa0n0Y9bJQVqkSBCuh6ZFh8PagXgZoe0NeQxs1jdJTqy1TleByEiMitCLDFywJ4EsuMSv2W1jW8hmWd/HyKyoEleWUGShU0if1qOjuKP17+O5KEOShUorrAqQMvdpyXoKNLuKQMTq2lBJt/10tZT6wMUX2fZvpMkMrG+cQU2HhZE4Adq+JeMYgV9ULt/9XvH2huS+3QlksyvQiQnuFKLKEhJN030OFUWlAsLgDaVxjykRYQsYckys4YSqkYLLVcJK5zK9Sqg6rK1VRlyfQo1GOv1vzgQX5M2S6B9YTJexXpYpdF07tVAfZ7p4nrX3kfxBIxWpvksfAYGs1geqm3bE3tHh4dOuWg5a21D/pHTOsiy/7mxv4yt9rtJdlbk/CDGT9BXZhmoN5RdKyimdXa8NmiNrPYMZ13a87nIrpWkLVTFZue8aYkzzB6MVPAdUf91HzI9XuVCR6XQrQ+tXt2wZ/QB8seQ1kR2PN830/hDLEqbFe3SSKsILTr4wDV0w/QLotfYoaYoLEMpSAHfgaymUjXHAI3uXAwx1pTwXuFxqhXvyrF2zsykkjoVc4nlXwMyxQUbwPg t/+Kz1Ni xYTkLL9bsQck+r1lKsXCI9EXibWTmAqt59xphl80lLezax7R+7vBMNvBaHetNVbrrsm9iIb+sJxWDN8334jeAbflcjX1qJ6LEdPNh5vt0CJvfqwBfCL8vTrs4uVQdSUfpHp7SOH+nGPmnvzc= 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/15 6:25, Jakub Kicinski wrote: > On Tue, 14 Nov 2023 16:23:29 +0800 Yunsheng Lin wrote: >> I would expect net stack, page pool, driver still see the 'struct page', >> only memory provider see the specific struct for itself, for the above, >> devmem memory provider sees the 'struct page_pool_iov'. > > You can't lie to the driver that an _iov is a page either. Yes, agreed about that. As a matter of fact, the driver should be awared of what kind of memory provider is using when it calls page_pool_create() during init process. > The driver must explicitly "opt-in" to using the _iov variant, > by calling the _iov set of APIs. > > Only drivers which can support header-data split can reasonably > use the _iov API, for data pages. But those drivers can still allow allocating normal memory, right? sometimes for data and header part, and sometimes for the header part. Do those drivers need to support two sets of APIs? the one with _iov for devmem, and the one without _iov for normal memory. It seems somewhat unnecessary from driver' point of veiw to support two sets of APIs? The driver seems to know which type of page it is expecting when calling page_pool_alloc() with a specific page_pool instance. Or do we use the API with _iov to allocate both devmem and normal memory in the new driver supporting devmem page? If that is the case, does it really matter if the API is with _iov or not? > . >