Subject: Re: [PATCH net-next 3/8] cadence: macb: Add page pool support handle multi-descriptor frame rx

From: Théo Lebrun <[email-masked]>
Date: Tue, 27 Jan 2026 16:48:11 +0100

On Tue Jan 27, 2026 at 12:51 AM CET, Paolo Valerio wrote:
> On 26 Jan 2026 at 07:45:29 PM, Théo Lebrun <[email-masked]> wrote:
>> On Mon Jan 26, 2026 at 3:29 PM CET, Andrew Lunn wrote:
>>>> > I was more interested in plain networking, not XDP. Does it perform
>>>> > better with page pool? You at least need to show it is not worse, you
>>>> > need to avoid performance regressions.
>>>> 
>>>> I retested with iperf3. The target has a single rx queue with iperf3
>>>> running with no cpu affinity set.
>>>> 
>>>> |              |  64 | 128 |
>>>> | baseline     | 273 | 545 |
>>>> | pp (page)    | 273 | 544 |
>>>> | pp (2 frags) | 272 | 544 |
>>>
>>> So no real difference. That is unusual, it is typically faster, or if
>>> it is always doing line rate, it uses less CPU time. That might
>>> suggest the page pool integration is not optimal?
>>
>> One more data point. I get line rate with & without page_pool so below
>> are CPU times from /proc/stat:
>>
>>          upstream    pp
>> user            1     1
>> system        179    91 (!!!)
>> idle         7874  7303
>> softirq        35    37
>>
>> 16K pages on Mobileye EyeQ5 (MIPS), 7 fragments per page.
>>
>> Paolo shared 64 versus 128 measurements but I am unsure what those stand
>> for; I doubt it can be packet size as xdp-bench does not have it as a
>> parameter. https://man.archlinux.org/man/extra/xdp-tools/xdp-bench.8.en
>
> 64 and 128 are packet size in bytes.
> For the first test I used xdp-trafficgen on the sender side and
> xdp-bench (skb-mode) to count the drops in pps on my board.
>
> For the stack test I used iperf3 (UDP) similarly with 64 and 128 for the
> length option.

|           |    64 | 128 |
| baseline  |  75.3 | 145 |
| page_pool |  79.3 | 154 |

Call is: iperf3 -c $IP -u -A2 -b1G -l64   # or -l128

CPU affinity is important. I get approx -30% on CPU0 (where IRQs land)
and -12% on CPU1 (2nd thread of CPU0).

I looked at ftrace function_graph and it looks sensible. Baseline spends
16% of macb_rx_poll() in gem_rx_refill(). This goes down to 10% with
page_pool.

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com