[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e785ba9b-18b1-985b-10b0-63fbb4d474cd@huawei.com>
Date: Fri, 30 Jun 2023 19:57:39 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Alexei Starovoitov
<ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard
Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>, Matthias
Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, <bpf@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v5 RFC 0/6] introduce page_pool_alloc() API
On 2023/6/29 22:26, Alexander Lobakin wrote:
>> v5 RFC: add a new page_pool_cache_alloc() API, and other minor
>> change as discussed in v4. As there seems to be three
>> comsumers that might be made use of the new API, so
>> repost it as RFC and CC the relevant authors to see
>> if the new API fits their need.
>
> Tested v5 against my latest tree, no regressions, perf is even a bit
> better than it was. That also might've come from that net-next pulled
> Linus' tree with a good bunch of PRs already merged, or from v4 -> v5
> update.
v4 -> v5 is mostly about adding the page pool cache API, so I believe the
perf improvement is from the net-next pull:)
>
> Re consumers, I'm planning to send the RFC series with IAVF as a
> consumer on Monday (and a couple generic Page Pool improvements today,
> will see).
Thanks.
Powered by blists - more mailing lists