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 50A64C4167B for ; Mon, 11 Dec 2023 03:31:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61B066B008A; Sun, 10 Dec 2023 22:31:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CC786B008C; Sun, 10 Dec 2023 22:31:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BA316B0092; Sun, 10 Dec 2023 22:31:24 -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 3E3EC6B008A for ; Sun, 10 Dec 2023 22:31:24 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5ED0D1605C0 for ; Mon, 11 Dec 2023 03:31:23 +0000 (UTC) X-FDA: 81553112046.29.FEA3BC0 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf30.hostedemail.com (Postfix) with ESMTP id 7D6CE8000E for ; Mon, 11 Dec 2023 03:31:21 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kqUTOZak; spf=pass (imf30.hostedemail.com: domain of liangchen.linux@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=liangchen.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702265481; 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:dkim-signature; bh=gQSL4X30hGfSGTxRuYdgtKDfvYwjWus1QS3Y5VELUiA=; b=QyK7Iv8uxiLLv0gDHOPjWhGvJZZFX4IgHcRl6qtMgEtzDFnUdTs2VlSishe3aBBEqMqDvF GCOgZRXZfDBXMnZ7V8UeF4uKwApDx1pe4uRXtPQFevDw25We0d34q16ij08SQ29+v0Eq8+ yR802WEFFTXXnxLDtRd/JRMpxoMVIFo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702265481; a=rsa-sha256; cv=none; b=8XEs55GlDF3rXRDydKIAtjBCHbUjiRfW9Q//vw8Z63jjlcV9NtMCx4iPqcdXotAhSYe0NA T5fwepxsOjlyNIP0x6kepJ4KdlK11XK8L5Dfd+KuKlge1pgDLFJaBgaGoRmKQw/OqASMxE 3Lv7TzPfTTjCbHve5aEGD7w00K8qoEk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kqUTOZak; spf=pass (imf30.hostedemail.com: domain of liangchen.linux@gmail.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=liangchen.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2cc2238f597so4386371fa.3 for ; Sun, 10 Dec 2023 19:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702265480; x=1702870280; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gQSL4X30hGfSGTxRuYdgtKDfvYwjWus1QS3Y5VELUiA=; b=kqUTOZak97JE+UGsd/rAbbjfjJ0sen5L7n1hNu9MrYALqIsWpfk1+m6Vo0k2RbI24X RzarU+lawQrd2omTWuL8zI2WFczFSN2B2sgPX1ab0DDbDiIKH6eh+zy3IzUn+T9S5gso seTkwamGAlxTcQ23xXyh+o2l19XaWdaBRXLaS+h7Ugk+LvBweLz1e600yD36aTaYTeaA vMoJV4zSGC4WeDksSsjhGS/9bpSUXY5m4mPYzzZYyhoYx9phP4cEPfTogt8yCf6Prqxg bZzstZMFIVlAPUrsUL2XD9/YfmYY1Nx3r52E3UY3luLe/9MdtHUDkBFceLZpevc1TJuU esPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702265480; x=1702870280; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gQSL4X30hGfSGTxRuYdgtKDfvYwjWus1QS3Y5VELUiA=; b=pakuef8UxRRVZj8benEZDmTTfC3z7oFs0wuj0sLaS+7WrxWDaSHffPdKBgklTY3wRF Lq4SDk1nhQ5OOFHXq/Ea7tWe1gl+25afsr1O+207sJgtmyllm89C3MGIgQ77xTyDpn2Y XdAvzJvrxbY7ptMRrBeuPYV0UUxBO3FJLxyQ6Wu+euUNvDLRScUKQiH6SZCdyl4oRbd3 b0yHTqHb/UPsiV++vEr0mc4DDG4Zsxwk44UrgLEK0t4+K1VW0XsAv+qD/qMSWF9vkxAR GtChKrdocaCAZ0qzUn85jGa8Zz/neqZU7/XyUKd6mczutTsTAd8MtpBRq2s3cY2hbVD8 sTTw== X-Gm-Message-State: AOJu0YyVohcW9Prvn0pqSAAspA+eCO9QcZNAecoP8CyXRnaTL0pJUhlG UN+bjeZ1HWnIU+ghiullUJBOctuZIYFW8uMcmIQ= X-Google-Smtp-Source: AGHT+IE1adiREpDOlI+/gfB18LJB7AaiHcJG2gpFXbiATLuTpugOdaHu3uWiIuOgFyFgQyY/HhAeJsPRdtGCmB+Di+Q= X-Received: by 2002:a2e:9d51:0:b0:2c9:f658:6a37 with SMTP id y17-20020a2e9d51000000b002c9f6586a37mr600097ljj.66.1702265479415; Sun, 10 Dec 2023 19:31:19 -0800 (PST) MIME-Version: 1.0 References: <20231206105419.27952-1-liangchen.linux@gmail.com> <20231206105419.27952-2-liangchen.linux@gmail.com> <20231208173816.2f32ad0f@kernel.org> In-Reply-To: <20231208173816.2f32ad0f@kernel.org> From: Liang Chen Date: Mon, 11 Dec 2023 11:31:06 +0800 Message-ID: Subject: Re: [PATCH net-next v7 1/4] page_pool: transition to reference count management after page draining To: Jakub Kicinski Cc: davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, hawk@kernel.org, ilias.apalodimas@linaro.org, linyunsheng@huawei.com, netdev@vger.kernel.org, linux-mm@kvack.org, jasowang@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7D6CE8000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: qapmd3jmc8pf79d6ykam5qn4x64iyffj X-HE-Tag: 1702265481-948091 X-HE-Meta: U2FsdGVkX1+/BR1bpsuxro0e8Atg2s3ZcNtXSYhB27JOIYHdzl4yOztcEdjKGeCvkQ8La1ku0Mtx/7B9qaFCOuBgTHto6zyXL4Ca4+cd2p1jYNFxePBhRUuQq3ctd392BRmlhvx2EN2Cog0sevOdKVzt/jZeUBYp7zxJ9J1sjwSwi+2tHrseQ0D7kLFBOQ85X24xrRll/+uJicEFIFANuGfHBhtR4r9oeK/wcAGlNHZAdU/dNeJVYUhakuhQrCXaF3KDASL6p12BGyikkS0kTB61sLKgZNJ8trb+MSIyTOX7ZrAD9z6sFXbn720qRs2zJ4+0BM4IPkMrLzmC8kJ2BtDf9tYhRF+I1vll4ksi1JMyJZSpLAfNp8nxkxHCORuZR4bTpNvslZBq1IpKGeRhTZPqG32EfMjbI4fYT0KDRTCAtxv5QJ6ON0imAq+eA1KcOToSgnqIWRgfoDR6JJMAPSDb4Ucy+uLZI1+zOmqyNmQamZuGEzVol1jaX3bRs317TFwNlXnGNOXh+Idf9vJxcNio/A5LbBn1yzuHN08u1eX1M8a28OJMlyjRrLWDWM2ME73vSjlpLgc4tpHMtavU/d2Cpoeno7RkiyqRtEHjiV570WDa4xbTihP0IJWdp9J++WPMs+14eD6FFh4vU2O+7SDTfuI700Pl5VwmuRsY4slAxlJx5KUZNIRp5cz8gdAKxaiOL/6ujb7GhhofdWxUCmec2GwYpHcPZakfWnFTrP6lfqAA+G78FktLqCF5O1ZiFp0dirrl3LCCNSnmjDlsk6Bqs0QG6pnCsbv98OluYoymj0L7U8w8D4+H8rZXAWS3lNvHu2ptP/hku6TCOe62FTCnKsBmKZBv5/qkOIbqYNI5eO4l0Qah41GRdEjcYp3M6Pq+wvw7tolUDeRf32yX57p6VPaRvp7WgGYuEFhQJ4P4N2f5UrogJ1pix0ODcDsxySmmNcfPXFuUtXzqlgS S45f9MRD Coha40mewYvJGjqbHEq6UaYl9+E2l9qVe95JnOw0N3Vm3rBBwquoqC0viQFUOIGNpT66s+iHy8hAdtsyuP5ZxlZZslvmVbC3GH7KYifAexf/PiNLfYlEqq9630hj6xLIT5bK8rY+o7kWtD9MM9weNlXe6an4xTh7nK/PH8w9ILiEDH34zIEdVxZHRwMW6o1xyEIRdxjWtkb1arqCEGxJBpIiilkhVIKjyvsIny4b6eyf1HQOK2ZiO0Ij1R3XP7RrNDyqODTtspY51LAzfUV84yCJ0KZjhAZpn8HpmhyRSdn/2hScpptI5OPUGVGGxNVCcdEwjFKFUzRv1AEMxcm5/kenxcFdQb9VLpWEAZOY639Q0lJXSqwGgFgYm71rogIgxx8UjNERcDIbFzEBsbq+vJwHPYuYjhyxo9qnamSxJtKikY8pbcAXZbvNtTUZI1Cv4k0IPJRBejyX5AkXHkdJ/zDJ6FAtmTwU6UEDiNIXS1/+wfS5FTsartL1/Bg== 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 Sat, Dec 9, 2023 at 9:38=E2=80=AFAM Jakub Kicinski wro= te: > > On Wed, 6 Dec 2023 18:54:16 +0800 Liang Chen wrote: > > -/* pp_frag_count represents the number of writers who can update the p= age > > +/* pp_ref_count represents the number of writers who can update the pa= ge > > * either by updating skb->data or via DMA mappings for the device. > > * We can't rely on the page refcnt for that as we don't know who migh= t be > > * holding page references and we can't reliably destroy or sync DMA m= appings > > * of the fragments. > > * > > - * When pp_frag_count reaches 0 we can either recycle the page if the = page > > + * pp_ref_count initially corresponds to the number of fragments. Howe= ver, > > + * when multiple users start to reference a single fragment, for examp= le in > > + * skb_try_coalesce, the pp_ref_count will become greater than the num= ber of > > + * fragments. > > + * > > + * When pp_ref_count reaches 0 we can either recycle the page if the p= age > > * refcnt is 1 or return it back to the memory allocator and destroy a= ny > > * mappings we have. > > */ > > Sorry to nit pick but I think this whole doc has to be rewritten > completely. It does state the most important thing which is that > the caller must have just allocated the page. > > How about: > > /** > * page_pool_fragment_page() - split a fresh page into fragments > * @.. fill these in > * > * pp_ref_count represents the number of outstanding references > * to the page, which will be freed using page_pool APIs (rather > * than page allocator APIs like put_page()). Such references are > * usually held by page_pool-aware objects like skbs marked for > * page pool recycling. > * > * This helper allows the caller to take (set) multiple references > * to a freshly allocated page. The page must be freshly allocated > * (have a pp_ref_count of 1). This is commonly done by drivers > * and "fragment allocators" to save atomic operations - either > * when they know upfront how many references they will need; or > * to take MAX references and return the unused ones with a single > * atomic dec(), instead of performing multiple atomic inc() > * operations. > */ > > I think that's more informative at this stage of evolution of > the page pool API, when most users aren't experts on internals. > But feel free to disagree.. > Thanks for the help! This is certainly better. > > static inline void page_pool_fragment_page(struct page *page, long nr) > > { > > - atomic_long_set(&page->pp_frag_count, nr); > > + atomic_long_set(&page->pp_ref_count, nr); > > } > > The code itself and rest of the patches LGTM, although it would be > great to get ACKs from pp maintainers..