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>,
"Björn Töpel" <bjorn.topel@intel•com>, 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>,
"Andrii Nakryiko" <andrii.nakryiko@gmail•com>,
"Tariq Toukan" <tariqt@mellanox•com>,
"Saeed Mahameed" <saeedm@mellanox•com>,
"Maxim Mikityanskiy" <maximmi@mellanox•com>
Subject: Re: [PATCH bpf-next v2 2/6] xdp: introduce xdp_call
Date: Tue, 26 Nov 2019 09:37:03 +0100 [thread overview]
Message-ID: <87o8wzyqxc.fsf@toke.dk> (raw)
In-Reply-To: <CAJ+HfNhSba7B=SFK0-zjYqFMfwjiq-AVY2Ar7E0P5Pw6gNqTJA@mail.gmail.com>
Björn Töpel <bjorn.topel@gmail•com> writes:
> On Mon, 25 Nov 2019 at 16:56, Toke Høiland-Jørgensen <toke@redhat•com> wrote:
>>
>> Björn Töpel <bjorn.topel@gmail•com> writes:
>>
>> > On Mon, 25 Nov 2019 at 12:18, Toke Høiland-Jørgensen <toke@redhat•com> wrote:
>> >>
>> >> Björn Töpel <bjorn.topel@gmail•com> writes:
>> >>
>> >> > From: Björn Töpel <bjorn.topel@intel•com>
>> >> >
>> >> > The xdp_call.h header wraps a more user-friendly API around the BPF
>> >> > dispatcher. A user adds a trampoline/XDP caller using the
>> >> > DEFINE_XDP_CALL macro, and updates the BPF dispatcher via
>> >> > xdp_call_update(). The actual dispatch is done via xdp_call().
>> >> >
>> >> > Note that xdp_call() is only supported for builtin drivers. Module
>> >> > builds will fallback to bpf_prog_run_xdp().
>> >>
>> >> I don't like this restriction. Distro kernels are not likely to start
>> >> shipping all the network drivers builtin, so they won't benefit from the
>> >> performance benefits from this dispatcher.
>> >>
>> >> What is the reason these dispatcher blocks have to reside in the driver?
>> >> Couldn't we just allocate one system-wide, and then simply change
>> >> bpf_prog_run_xdp() to make use of it transparently (from the driver
>> >> PoV)? That would also remove the need to modify every driver...
>> >>
>> >
>> > Good idea! I'll try that out. Thanks for the suggestion!
>>
>> Awesome! I guess the table may need to be a bit bigger if it's
>> system-wide? But since you've already gone to all that trouble with the
>> binary search, I guess that shouldn't have too much of a performance
>> impact? Maybe the size could even be a config option so users/distros
>> can make their own size tradeoff?
>>
>
> My bigger concern is not the dispatcher size, but that any XDP update
> will be a system wide text-poke. OTOH, this is still the case even if
> there are multiple dispatchers. No more "quickly swap XDP program in
> one packet latency".
Ah, right. I don't actually know the details of how all this kernel text
rewriting happens. I just assumed it was magic faerie dust that just
made everything faster; but now you're telling me there are tradeoffs?! ;)
When you say "no more quickly swap XDP programs" you mean that the
attach operation itself will take longer, right? I.e., it's not that it
will disrupt packet flow to the old program while it's happening? Also,
how much longer?
-Toke
next prev parent reply other threads:[~2019-11-26 8:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-23 7:12 [PATCH bpf-next v2 0/6] Introduce the BPF dispatcher and xdp_call.h Björn Töpel
2019-11-23 7:12 ` [PATCH bpf-next v2 1/6] bpf: introduce BPF dispatcher Björn Töpel
2019-11-24 1:55 ` Alexei Starovoitov
2019-11-24 6:55 ` Björn Töpel
2019-11-24 17:08 ` Alexei Starovoitov
2019-11-24 17:16 ` Björn Töpel
2019-11-25 0:08 ` kbuild test robot
2019-11-25 10:53 ` Daniel Borkmann
2019-11-25 15:20 ` Björn Töpel
2019-11-23 7:12 ` [PATCH bpf-next v2 2/6] xdp: introduce xdp_call Björn Töpel
2019-11-24 1:59 ` Alexei Starovoitov
2019-11-24 6:56 ` Björn Töpel
2019-11-25 11:18 ` Toke Høiland-Jørgensen
2019-11-25 15:21 ` Björn Töpel
2019-11-25 15:56 ` Toke Høiland-Jørgensen
2019-11-26 7:43 ` Björn Töpel
2019-11-26 8:37 ` Toke Høiland-Jørgensen [this message]
2019-11-23 7:12 ` [PATCH bpf-next v2 3/6] i40e: start using xdp_call.h Björn Töpel
2019-11-23 7:12 ` [PATCH bpf-next v2 4/6] ixgbe: " Björn Töpel
2019-11-23 7:12 ` [PATCH bpf-next v2 5/6] net/mlx4_en: " Björn Töpel
2019-11-23 7:12 ` [PATCH bpf-next v2 6/6] net/mlx5e: Start " 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=87o8wzyqxc.fsf@toke.dk \
--to=toke@redhat$(echo .)com \
--cc=andrii.nakryiko@gmail$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=bjorn.topel@gmail$(echo .)com \
--cc=bjorn.topel@intel$(echo .)com \
--cc=bpf@vger$(echo .)kernel.org \
--cc=daniel@iogearbox$(echo .)net \
--cc=ecree@solarflare$(echo .)com \
--cc=jonathan.lemon@gmail$(echo .)com \
--cc=magnus.karlsson@gmail$(echo .)com \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=maximmi@mellanox$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=saeedm@mellanox$(echo .)com \
--cc=tariqt@mellanox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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