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: <87ldhkexvq.fsf@redhat.com>
Date: Tue, 27 Jan 2026 00:51:21 +0100
From: Paolo Valerio <pvalerio@...hat.com>
To: 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>,
 Théo Lebrun <theo.lebrun@...tlin.com>, 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 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.

> Measurement incantation:
>
>    cat /proc/stat > /tmp/a && \
>    iperf3 -c $IP && \
>    cat /proc/stat > /tmp/b && \
>    awk 'NR==FNR && $1=="cpu" {user=$2;sys=$4;idle=$5;softirq=$8;next}
>         $1=="cpu" {printf "user\t%5d\n", $2-user}
>         $1=="cpu" {printf "system\t%5d\n", $4-sys}
>         $1=="cpu" {printf "idle\t%5d\n", $5-idle}
>         $1=="cpu" {printf "softirq\t%5d\n", $8-softirq}
>    ' /tmp/a /tmp/b
>
> Thanks,
>
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com