From: Simon Horman <simon.horman@corigine.com>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Eric Dumazet <edumazet@google.com>, Wei Fang <wei.fang@nxp.com>,
Shenwei Wang <shenwei.wang@nxp.com>,
Clark Wang <xiaoning.wang@nxp.com>,
NXP Linux Team <linux-imx@nxp.com>,
Sunil Goutham <sgoutham@marvell.com>,
Geetha sowjanya <gakula@marvell.com>,
Subbaraya Sundeep <sbhatta@marvell.com>,
hariprasad <hkelam@marvell.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Felix Fietkau <nbd@nbd.name>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Ryder Lee <ryder.lee@mediatek.com>,
Shayne Chen <shayne.chen@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>, Kalle Valo <kvalo@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
linux-rdma@vger.kernel.org, bpf@vger.kernel.org,
linux-wireless@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next] page_pool: split types and declarations from page_pool.h
Date: Mon, 24 Jul 2023 17:14:01 +0200 [thread overview]
Message-ID: <ZL6VOQ4SL/Zk0FdL@corigine.com> (raw)
In-Reply-To: <20230719121339.63331-1-linyunsheng@huawei.com>
On Wed, Jul 19, 2023 at 08:13:37PM +0800, Yunsheng Lin wrote:
Hi Yunsheng,
...
> diff --git a/include/net/page_pool_types.h b/include/net/page_pool_types.h
...
> +struct page_pool {
> + struct page_pool_params p;
> +
> + struct delayed_work release_dw;
> + void (*disconnect)(void *);
> + unsigned long defer_start;
> + unsigned long defer_warn;
> +
> + u32 pages_state_hold_cnt;
> + unsigned int frag_offset;
> + struct page *frag_page;
> + long frag_users;
> +
> +#ifdef CONFIG_PAGE_POOL_STATS
> + /* these stats are incremented while in softirq context */
> + struct page_pool_alloc_stats alloc_stats;
> +#endif
> + u32 xdp_mem_id;
> +
> + /*
> + * Data structure for allocation side
> + *
> + * Drivers allocation side usually already perform some kind
> + * of resource protection. Piggyback on this protection, and
> + * require driver to protect allocation side.
> + *
> + * For NIC drivers this means, allocate a page_pool per
> + * RX-queue. As the RX-queue is already protected by
> + * Softirq/BH scheduling and napi_schedule. NAPI schedule
> + * guarantee that a single napi_struct will only be scheduled
> + * on a single CPU (see napi_schedule).
> + */
> + struct pp_alloc_cache alloc ____cacheline_aligned_in_smp;
> +
> + /* Data structure for storing recycled pages.
> + *
> + * Returning/freeing pages is more complicated synchronization
> + * wise, because free's can happen on remote CPUs, with no
> + * association with allocation resource.
> + *
> + * Use ptr_ring, as it separates consumer and producer
> + * effeciently, it a way that doesn't bounce cache-lines.
I know this is moved from elsewhere, but: effeciently -> efficiently
> + *
> + * TODO: Implement bulk return pages into this structure.
> + */
> + struct ptr_ring ring;
> +
> +#ifdef CONFIG_PAGE_POOL_STATS
> + /* recycle stats are per-cpu to avoid locking */
> + struct page_pool_recycle_stats __percpu *recycle_stats;
> +#endif
> + atomic_t pages_state_release_cnt;
> +
> + /* A page_pool is strictly tied to a single RX-queue being
> + * protected by NAPI, due to above pp_alloc_cache. This
> + * refcnt serves purpose is to simplify drivers error handling.
> + */
> + refcount_t user_cnt;
> +
> + u64 destroy_cnt;
> +};
...
prev parent reply other threads:[~2023-07-24 15:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 12:13 [PATCH net-next] page_pool: split types and declarations from page_pool.h Yunsheng Lin
2023-07-19 14:01 ` Jeff Johnson
2023-07-19 16:42 ` Alexander Lobakin
2023-07-20 11:07 ` Yunsheng Lin
2023-07-20 16:22 ` Jakub Kicinski
2023-07-21 11:12 ` Yunsheng Lin
2023-07-21 14:56 ` Jakub Kicinski
2023-07-21 15:51 ` Alexander Lobakin
2023-07-22 1:29 ` Jakub Kicinski
2023-07-24 10:18 ` Alexander Lobakin
2023-07-20 18:18 ` Alexander Lobakin
2023-07-19 17:03 ` Alexander Lobakin
2023-07-24 15:14 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZL6VOQ4SL/Zk0FdL@corigine.com \
--to=simon.horman@corigine.com \
--cc=aleksander.lobakin@intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=hawk@kernel.org \
--cc=hkelam@marvell.com \
--cc=ilias.apalodimas@linaro.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=leon@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ryder.lee@mediatek.com \
--cc=saeedm@nvidia.com \
--cc=sbhatta@marvell.com \
--cc=sean.wang@mediatek.com \
--cc=sgoutham@marvell.com \
--cc=shayne.chen@mediatek.com \
--cc=shenwei.wang@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).