[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCe1h8tNaEqqUlO0@mini-arch>
Date: Fri, 16 May 2025 15:00:39 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Samiullah Khawaja <skhawaja@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
"David S . Miller " <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
almasrymina@...gle.com, willemb@...gle.com, netdev@...r.kernel.org
Subject: Re: [PATCH net v2] xsk: Bring back busy polling support in XDP_COPY
On 05/16, Samiullah Khawaja wrote:
> Commit 5ef44b3cb43b ("xsk: Bring back busy polling support") fixed the
> busy polling support in xsk for XDP_ZEROCOPY after it was broken in
> commit 86e25f40aa1e ("net: napi: Add napi_config"). The busy polling
> support with XDP_COPY remained broken since the napi_id setup in
> xsk_rcv_check was removed.
>
> Bring back the setup of napi_id for XDP_COPY so socket level SO_BUSYPOLL
> can be used to poll the underlying napi.
>
> Do the setup of napi_id for XDP_COPY in xsk_bind, as it is done
> currently for XDP_ZEROCOPY. The setup of napi_id for XDP_COPY in
> xsk_bind is safe because xsk_rcv_check checks that the rx queue at which
> the packet arrives is equal to the queue_id that was supplied in bind.
> This is done for both XDP_COPY and XDP_ZEROCOPY mode.
>
> Tested using AF_XDP support in virtio-net by running the xsk_rr AF_XDP
> benchmarking tool shared here:
> https://lore.kernel.org/all/20250320163523.3501305-1-skhawaja@google.com/T/
>
> Enabled socket busy polling using following commands in qemu,
>
> ```
> sudo ethtool -L eth0 combined 1
> echo 400 | sudo tee /proc/sys/net/core/busy_read
> echo 100 | sudo tee /sys/class/net/eth0/napi_defer_hard_irqs
> echo 15000 | sudo tee /sys/class/net/eth0/gro_flush_timeout
> ```
>
> Fixes: 5ef44b3cb43b ("xsk: Bring back busy polling support")
> Signed-off-by: Samiullah Khawaja <skhawaja@...gle.com>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
Acked-by: Stanislav Fomichev <sdf@...ichev.me>
Looks good to me. But note that I never understood why those __sk_mark_napi_id_once
calls were there in the receive path in the first place. Presumably
because of the unstable napi ids. Now, with the napi config, it should
be safe to resolve both copy/non-copy modes during the bind.
Powered by blists - more mailing lists