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
| ||
|
Date: Wed, 11 Sep 2019 13:09:01 +0100 From: Toke Høiland-Jørgensen <toke@...hat.com> To: Björn Töpel <bjorn.topel@...el.com>, Yonghong Song <yhs@...com>, Sami Tolvanen <samitolvanen@...gle.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Kees Cook <keescook@...omium.org>, Martin Lau <kafai@...com>, Song Liu <songliubraving@...com>, "netdev\@vger.kernel.org" <netdev@...r.kernel.org>, "bpf\@vger.kernel.org" <bpf@...r.kernel.org>, "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>, Jesper Dangaard Brouer <brouer@...hat.com> Subject: Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled Björn Töpel <bjorn.topel@...el.com> writes: > On 2019-09-11 09:42, Yonghong Song wrote: >> I am not an expert in XDP testing. Toke, Björn, could you give some >> suggestions what to test for XDP performance here? > > I ran the "xdp_rxq_info" sample with and without Sami's patch: Thanks for doing this! > $ sudo ./xdp_rxq_info --dev enp134s0f0 --action XDP_DROP > > Before: > > Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch > XDP stats CPU pps issue-pps > XDP-RX CPU 20 23923874 0 > XDP-RX CPU total 23923874 > > RXQ stats RXQ:CPU pps issue-pps > rx_queue_index 20:20 23923878 0 > rx_queue_index 20:sum 23923878 > > After Sami's patch: > > Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch > XDP stats CPU pps issue-pps > XDP-RX CPU 20 22998700 0 > XDP-RX CPU total 22998700 > > RXQ stats RXQ:CPU pps issue-pps > rx_queue_index 20:20 22998705 0 > rx_queue_index 20:sum 22998705 > > > So, roughly ~4% for this somewhat naive scenario. Or (1/22998700 - 1/23923874) * 10**9 == 1.7 nanoseconds of overhead. I guess that is not *too* bad; but it's still chipping away at performance; anything we could do to lower the overhead? -Toke
Powered by blists - more mailing lists