From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andy Gospodarek <andrew.gospodarek@broadcom.com>
Cc: Tariq Toukan <ttoukan.linux@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Andy Gospodarek <andrew.gospodarek@broadcom.com>,
ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net,
hawk@kernel.org, john.fastabend@gmail.com, andrii@kernel.org,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
kpsingh@kernel.org, lorenzo.bianconi@redhat.com,
netdev@vger.kernel.org, bpf@vger.kernel.org,
Jesper Dangaard Brouer <brouer@redhat.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
gal@nvidia.com, Saeed Mahameed <saeedm@nvidia.com>,
tariqt@nvidia.com
Subject: Re: [PATCH net-next v2] samples/bpf: fixup some tools to be able to support xdp multibuffer
Date: Fri, 06 Jan 2023 18:54:37 +0100 [thread overview]
Message-ID: <87k01zzgyq.fsf@toke.dk> (raw)
In-Reply-To: <87v8lkzlch.fsf@toke.dk>
>>> So my main concern would be that if we "allow" this, the only way to
>>> write an interoperable XDP program will be to use bpf_xdp_load_bytes()
>>> for every packet access. Which will be slower than DPA, so we may end up
>>> inadvertently slowing down all of the XDP ecosystem, because no one is
>>> going to bother with writing two versions of their programs. Whereas if
>>> you can rely on packet headers always being in the linear part, you can
>>> write a lot of the "look at headers and make a decision" type programs
>>> using just DPA, and they'll work for multibuf as well.
>>
>> The question I would have is what is really the 'slow down' for
>> bpf_xdp_load_bytes() vs DPA? I know you and Jesper can tell me how many
>> instructions each use. :)
>
> I can try running some benchmarks to compare the two, sure!
Okay, ran a simple test: a program that just parses the IP header, then
drops the packet. Results as follows:
Baseline (don't touch data): 26.5 Mpps / 37.8 ns/pkt
Touch data (ethernet hdr): 25.0 Mpps / 40.0 ns/pkt
Parse IP (DPA): 24.1 Mpps / 41.5 ns/pkt
Parse IP (bpf_xdp_load_bytes): 15.3 Mpps / 65.3 ns/pkt
So 2.2 ns of overhead from reading the packet data, another 1.5 ns from
the parsing logic, and a whopping 23.8 ns extra from switching to
bpf_xdp_load_bytes(). This is with two calls to bpf_xdp_load_bytes(),
one to get the Ethernet header, and another to get the IP header.
Dropping one of them also drops the overhead in half, so it seems to fit
with ~12 ns of overhead from a single call to bpf_xdp_load_bytes().
I pushed the code I used for testing here, in case someone else wants to
play around with it:
https://github.com/xdp-project/xdp-tools/tree/xdp-load-bytes
It's part of the 'xdp-bench' utility. Run it as:
./xdp-bench drop <iface> -p parse-ip
for DPA parsing and
./xdp-bench drop <iface> -p parse-ip -l
to use bpf_xdp_load_bytes().
-Toke
next prev parent reply other threads:[~2023-01-06 17:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 17:54 [PATCH net-next v2] samples/bpf: fixup some tools to be able to support xdp multibuffer Andy Gospodarek
2022-06-22 2:00 ` patchwork-bot+netdevbpf
2023-01-03 12:55 ` Tariq Toukan
2023-01-03 15:19 ` Toke Høiland-Jørgensen
2023-01-04 1:21 ` Jakub Kicinski
2023-01-04 8:44 ` Lorenzo Bianconi
2023-01-04 12:28 ` Toke Høiland-Jørgensen
2023-01-05 1:17 ` Jakub Kicinski
2023-01-05 7:20 ` Tariq Toukan
2023-01-05 15:43 ` Toke Høiland-Jørgensen
2023-01-05 16:57 ` Andy Gospodarek
2023-01-05 18:16 ` Jakub Kicinski
2023-01-06 13:56 ` Andy Gospodarek
2023-01-08 12:33 ` Tariq Toukan
[not found] ` <8369e348-a8ec-cb10-f91f-4277e5041a27@nvidia.com>
2023-01-08 12:42 ` Tariq Toukan
2023-01-09 13:50 ` Toke Høiland-Jørgensen
2023-01-05 22:07 ` Toke Høiland-Jørgensen
2023-01-06 17:54 ` Toke Høiland-Jørgensen [this message]
2023-01-05 16:22 ` Andy Gospodarek
2023-01-10 20:59 ` Maxim Mikityanskiy
2023-01-13 21:07 ` Tariq Toukan
2023-01-25 12:49 ` Tariq Toukan
2023-01-05 16:18 ` Andy Gospodarek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k01zzgyq.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=gal@nvidia.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=songliubraving@fb.com \
--cc=tariqt@nvidia.com \
--cc=ttoukan.linux@gmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.