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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DFZHN2KXS7UI.C1WHCBAAII2K@bootlin.com>
Date: Tue, 27 Jan 2026 16:48:11 +0100
From: Théo Lebrun <theo.lebrun@...tlin.com>
To: "Paolo Valerio" <pvalerio@...hat.com>, Théo Lebrun
 <theo.lebrun@...tlin.com>, "Andrew Lunn" <andrew@...n.ch>
Cc: <netdev@...r.kernel.org>, "Nicolas Ferre" <nicolas.ferre@...rochip.com>,
 "Claudiu Beznea" <claudiu.beznea@...on.dev>, "Andrew Lunn"
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>, "Paolo
 Abeni" <pabeni@...hat.com>, "Lorenzo Bianconi" <lorenzo@...nel.org>,
 Grégory Clement <gregory.clement@...tlin.com>, "Thomas
 Petazzoni" <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH net-next 3/8] cadence: macb: Add page pool support
 handle multi-descriptor frame rx

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 <theo.lebrun@...tlin.com> 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