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]

Message-ID: <a7e72202-0fa1-633e-1564-132a1984aba1@redhat.com>
Date: Mon, 21 Aug 2023 23:54:34 +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>, Maryam Tahhan <mtahhan@...hat.com>
Subject: Re: [RFC PATCH net-next v3 0/2] net: veth: Optimizing page pool usage



On 21/08/2023 16.21, Jesper Dangaard Brouer wrote:
> 
> 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...)

It works, implemented using xdp_do_generic_redirect() and lifted
skb_head_is_locked check in veth_convert_skb_to_xdp_buff(), plus adjust
xsk_build_skb() to alloc enough headroom.

The results[1] are good approx 26% faster[1] compared to Maryam's
veth-benchmark[3] results[2].

--Jesper

[1] 
https://github.com/xdp-project/xdp-project/blob/veth-benchmark02/areas/core/veth_benchmark04.org#implemented-use-generic-xdp-redirect

[2] 
https://github.com/xdp-project/xdp-project/blob/veth-benchmark02/areas/core/veth_benchmark03.org#benchmark01-with-xdp-redirect-loaded-on-host-veth

[3] https://github.com/maryamtahhan/veth-benchmark/