netdev - Re: [RFC PATCH net-next v3 0/2] net: veth: Optimizing page pool usage

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] [thread-next>] [day] [month] [year] [list]

Date: Mon, 21 Aug 2023 16:21:55 +0200
From: Jesper Dangaard Brouer <jbrouer@...hat.com>
To: Liang Chen <liangchen.linux@...il.com>, hawk@...nel.org,
 horms@...nel.org, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, linyunsheng@...wei.com
Cc: brouer@...hat.com, ilias.apalodimas@...aro.org, daniel@...earbox.net,
 ast@...nel.org, netdev@...r.kernel.org,
 Lorenzo Bianconi <lorenzo.bianconi@...hat.com>,
 Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [RFC PATCH net-next v3 0/2] net: veth: Optimizing page pool usage

On 16/08/2023 14.30, Liang Chen wrote:
> Page pool is supported for veth, but at the moment pages are not properly
> recyled for XDP_TX and XDP_REDIRECT. That prevents veth xdp from fully
> leveraging the advantages of the page pool. So this RFC patchset is mainly
> to make recycling work for those cases. With that in place, it can be
> further optimized by utilizing the napi skb cache. Detailed figures are
> presented in each commit message, and together they demonstrate a quite
> noticeable improvement.
> 

I'm digging into this code path today.

I'm trying to extend this and find a way to support SKBs that used
kmalloc (skb->head_frag=0), such that we can remove the
skb_head_is_locked() check in veth_convert_skb_to_xdp_buff(), which will
allow more SKBs to avoid realloc.  As long as they have enough headroom,
which we can dynamically control for netdev TX-packets by adjusting
netdev->needed_headroom, e.g. when loading an XDP prog.

I noticed netif_receive_generic_xdp() and bpf_prog_run_generic_xdp() can
handle SKB kmalloc (skb->head_frag=0).  Going though the code, I don't
think it is a bug that generic-XDP allows this.

Deep into this rabbit hole, I start to question our approach.
  - Perhaps the veth XDP approach for SKBs is wrong?

The root-cause of this issue is that veth_xdp_rcv_skb() code path (that
handle SKBs) is calling XDP-native function "xdp_do_redirect()". I
question, why isn't it using "xdp_do_generic_redirect()"?
(I will jump into this rabbit hole now...)

--Jesper

> Changes from v2:
> - refactor the code to make it more readable
> - make use of the napi skb cache for further optimization
> - take the Page pool creation error handling patch out for separate
>    submission
> 
> Liang Chen (2):
>    net: veth: Improving page pool recycling
>    net: veth: Optimizing skb reuse in NAPI Context
> 
>   drivers/net/veth.c | 66 ++++++++++++++++++++++++++++++++++++++++------
>   net/core/skbuff.c  |  1 +
>   2 files changed, 59 insertions(+), 8 deletions(-)
>