Re: [PATCH net-next] net/mlx5e: Prefetch packets of upcoming CQEs in the linear MPWQE path

[Antonio Quartulli]

Hi Alexei,

thank you very much for the review!!

On 04/11/2026 01:39, Alexei Starovoitov wrote:
> can we prefetch 4 strides ahead without the CQE, like gve_rx() ?

Yep! I measured your version against this patch on the same system (one
RX queue, MTU 1500, mean of 3 runs, gain over stock):

                                   v1      yours    yours + shinfo
  UDP 512B flood, packets/s       +39%      +35%      +36%
  TCP, 1 stream                    +7%       +5%       +8%
  TCP in an ovpn UDP tunnel       +36%       +4%      +34%
  XDP_DROP reading the packet,
    NAPI CPU cycles/packet        -38%      -45%      -32%
  XDP_TX, cycles/packet           -35%      -30%      -33%


It matches my v1, except where every packet becomes its own skb, like the
records of a VPN tunnel (ovpn from a development tree here).
In that case I got only +4% instead of +36%.
Dropping only the skb_shared_info prefetch from v1 gives +5% there, so
that line is the one that matters.

Its position depends on the packet length, which needs the CQE, but in
bulk flows the next packets have the length of the current one. So v2
will be your patch plus a prefetchw of the skb_shared_info line computed
with the current packet's length: +34% for the tunnel, the rest
unchanged, no CQE peek and no state bit, and it also covers CQE
compression, where v1 did nothing: with it on, UDP floods gain 26%,
TCP 6% (-46% cycles/packet) and the tunnel 32%.

> Pls add XDP_DROP and XDP_TX numbers.

In the table above. XDP_DROP without touching the packet doesn't change
with any of them. With the prefetch the XDP rates hit the limit of the
sender (12-16 Mpps) before the NAPI CPU saturates, so I quote cycles per
packet there.

I'll send v2 with your Suggested-by soonish.


Thanks!

--
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com