[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5ef2e4f-fcba-2e06-86ec-17522744b6a8@gmail.com>
Date: Tue, 23 Mar 2021 08:57:57 -0600
From: David Ahern <dsahern@...il.com>
To: Matteo Croce <mcroce@...ux.microsoft.com>, netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
Jonathan Lemon <jonathan.lemon@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Saeed Mahameed <saeedm@...dia.com>,
Saeed Mahameed <saeed@...nel.org>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH net-next 0/6] page_pool: recycle buffers
On 3/22/21 11:02 AM, Matteo Croce wrote:
> From: Matteo Croce <mcroce@...rosoft.com>
>
> This series enables recycling of the buffers allocated with the page_pool API.
> The first two patches are just prerequisite to save space in a struct and
> avoid recycling pages allocated with other API.
> Patch 2 was based on a previous idea from Jonathan Lemon.
>
> The third one is the real recycling, 4 fixes the compilation of __skb_frag_unref
> users, and 5,6 enable the recycling on two drivers.
patch 4 should be folded into 3; each patch should build without errors.
>
> In the last two patches I reported the improvement I have with the series.
>
> The recycling as is can't be used with drivers like mlx5 which do page split,
> but this is documented in a comment.
> In the future, a refcount can be used so to support mlx5 with no changes.
Is the end goal of the page_pool changes to remove driver private caches?
Powered by blists - more mailing lists