From: "Toke Høiland-Jørgensen" <thoiland@redhat.com>
To: "Björn Töpel" <bjorn.topel@gmail.com>,
netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net
Cc: "Björn Töpel" <bjorn.topel@intel.com>,
bpf@vger.kernel.org, magnus.karlsson@gmail.com,
magnus.karlsson@intel.com, jonathan.lemon@gmail.com
Subject: Re: [RFC PATCH bpf-next 2/4] bpf: introduce BPF dispatcher
Date: Thu, 14 Nov 2019 13:31:15 +0100 [thread overview]
Message-ID: <87o8xeod0s.fsf@toke.dk> (raw)
In-Reply-To: <20191113204737.31623-3-bjorn.topel@gmail.com>
Björn Töpel <bjorn.topel@gmail.com> writes:
> From: Björn Töpel <bjorn.topel@intel.com>
>
> The BPF dispatcher builds on top of the BPF trampoline ideas;
> Introduce bpf_arch_text_poke() and (re-)use the BPF JIT generate
> code. The dispatcher builds a dispatch table for XDP programs, for
> retpoline avoidance. The table is a simple binary search model, so
> lookup is O(log n). Here, the dispatch table is limited to four
> entries (for laziness reason -- only 1B relative jumps :-P). If the
> dispatch table is full, it will fallback to the retpoline path.
So it's O(log n) with n == 4? Have you compared the performance of just
doing four linear compare-and-jumps? Seems to me it may not be that big
of a difference for such a small N?
> An example: A module/driver allocates a dispatcher. The dispatcher is
> shared for all netdevs. Each netdev allocate a slot in the dispatcher
> and a BPF program. The netdev then uses the dispatcher to call the
> correct program with a direct call (actually a tail-call).
Is it really accurate to call it a tail call? To me, that would imply
that it increments the tail call limit counter and all that? Isn't this
just a direct jump using the trampoline stuff?
-Toke
next prev parent reply other threads:[~2019-11-14 12:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 20:47 [RFC PATCH bpf-next 0/4] Introduce xdp_call.h and the BPF dispatcher Björn Töpel
2019-11-13 20:47 ` [RFC PATCH bpf-next 1/4] bpf: teach bpf_arch_text_poke() jumps Björn Töpel
2019-11-13 20:47 ` [RFC PATCH bpf-next 2/4] bpf: introduce BPF dispatcher Björn Töpel
2019-11-13 21:40 ` Edward Cree
2019-11-14 6:29 ` Björn Töpel
2019-11-14 10:18 ` Edward Cree
2019-11-14 11:21 ` Björn Töpel
2019-11-14 13:58 ` Peter Zijlstra
2019-11-14 12:31 ` Toke Høiland-Jørgensen [this message]
2019-11-14 13:03 ` Daniel Borkmann
2019-11-14 13:09 ` Toke Høiland-Jørgensen
2019-11-14 13:56 ` Björn Töpel
2019-11-14 14:55 ` Toke Høiland-Jørgensen
2019-11-14 15:03 ` Björn Töpel
2019-11-14 15:12 ` Toke Høiland-Jørgensen
2019-11-15 0:30 ` Alexei Starovoitov
2019-11-15 7:56 ` Björn Töpel
2019-11-15 21:58 ` Alexei Starovoitov
2019-11-18 10:03 ` Björn Töpel
2019-11-18 19:36 ` Andrii Nakryiko
2019-11-18 20:11 ` Björn Töpel
2019-11-13 20:47 ` [RFC PATCH bpf-next 3/4] xdp: introduce xdp_call Björn Töpel
2019-11-13 20:47 ` [RFC PATCH bpf-next 4/4] i40e: start using xdp_call.h 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=87o8xeod0s.fsf@toke.dk \
--to=thoiland@redhat.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jonathan.lemon@gmail.com \
--cc=magnus.karlsson@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
/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).