From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Björn Töpel" <bjorn.topel@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
bpf <bpf@vger.kernel.org>,
"Magnus Karlsson" <magnus.karlsson@gmail.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
"Jonathan Lemon" <jonathan.lemon@gmail.com>,
"Edward Cree" <ecree@solarflare.com>,
"Toke Høiland-Jørgensen" <thoiland@redhat.com>,
"Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Subject: Re: [PATCH bpf-next v3 0/6] Introduce the BPF dispatcher
Date: Wed, 11 Dec 2019 14:17:17 +0100 [thread overview]
Message-ID: <8736drgfxe.fsf@toke.dk> (raw)
In-Reply-To: <CAJ+HfNiH4KUO-MXm3L8pka3dECC1S6rHUJ9NoMfyrhPD+9s9nw@mail.gmail.com>
Björn Töpel <bjorn.topel@gmail.com> writes:
> On Mon, 9 Dec 2019 at 18:42, Björn Töpel <bjorn.topel@gmail.com> wrote:
>>
> [...]
>> > You mentioned in the earlier version that this would impact the time it
>> > takes to attach an XDP program. Got any numbers for this?
>> >
>>
>> Ah, no, I forgot to measure that. I'll get back with that. So, when a
>> new program is entered or removed from dispatcher, it needs to be
>> re-jited, but more importantly -- a text poke is needed. I don't know
>> if this is a concern or not, but let's measure it.
>>
>
> Toke, I tried to measure the impact, but didn't really get anything
> useful out. :-(
>
> My concern was mainly that text-poking is a point of contention, and
> it messes with the icache. As for contention, we're already
> synchronized around the rtnl-lock. As for the icache-flush effects...
> well... I'm open to suggestions how to measure the impact in a useful
> way.
Hmm, how about:
Test 1:
- Run a test with a simple drop program (like you have been) on a
physical interface (A), sampling the PPS with interval I.
- Load a new XDP program on interface B (which could just be a veth I
guess?)
- Record the PPS delta in the sampling interval on which the program was
loaded on interval B.
You could also record for how many intervals the throughput drops, but I
would guess you'd need a fairly short sampling interval to see anything
for this.
Test 2:
- Run an XDP_TX program that just reflects the packets.
- Have the traffic generator measure per-packet latency (from it's
transmitted until the same packet comes back).
- As above, load a program on a different interface and look for a blip
in the recorded latency.
Both of these tests could also be done with the program being replaced
being the one that processes packets on the physical interface (instead
of on another interface). That way you could also see if there's any
difference for that before/after patch...
-Toke
next prev parent reply other threads:[~2019-12-11 13:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 13:55 [PATCH bpf-next v3 0/6] Introduce the BPF dispatcher Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 1/6] bpf: move trampoline JIT image allocation to a function Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 2/6] bpf: introduce BPF dispatcher Björn Töpel
2019-12-10 5:50 ` Alexei Starovoitov
2019-12-10 5:54 ` Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 3/6] bpf, xdp: start using the BPF dispatcher for XDP Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 4/6] bpf: start using the BPF dispatcher in BPF_TEST_RUN Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 5/6] selftests: bpf: add xdp_perf test Björn Töpel
2019-12-10 11:05 ` Jesper Dangaard Brouer
2019-12-10 11:56 ` Björn Töpel
2019-12-09 13:55 ` [PATCH bpf-next v3 6/6] bpf, x86: align dispatcher branch targets to 16B Björn Töpel
2019-12-09 15:00 ` [PATCH bpf-next v3 0/6] Introduce the BPF dispatcher Toke Høiland-Jørgensen
2019-12-09 17:42 ` Björn Töpel
2019-12-11 12:38 ` Björn Töpel
2019-12-11 13:17 ` Toke Høiland-Jørgensen [this message]
2019-12-09 17:00 ` Jesper Dangaard Brouer
2019-12-09 17:45 ` Björn Töpel
2019-12-09 19:50 ` Jesper Dangaard Brouer
2019-12-10 19:28 ` Samudrala, Sridhar
2019-12-10 20:04 ` Björn Töpel
2019-12-10 19:59 ` Björn Töpel
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=8736drgfxe.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ecree@solarflare.com \
--cc=jonathan.lemon@gmail.com \
--cc=magnus.karlsson@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=thoiland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).