[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ+HfNhSba7B=SFK0-zjYqFMfwjiq-AVY2Ar7E0P5Pw6gNqTJA@mail.gmail.com>
Date: Tue, 26 Nov 2019 08:43:31 +0100
From: Björn Töpel <bjorn.topel@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Netdev <netdev@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Björn Töpel <bjorn.topel@...el.com>,
bpf <bpf@...r.kernel.org>,
Magnus Karlsson <magnus.karlsson@...il.com>,
"Karlsson, Magnus" <magnus.karlsson@...el.com>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Edward Cree <ecree@...arflare.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
Tariq Toukan <tariqt@...lanox.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Maxim Mikityanskiy <maximmi@...lanox.com>
Subject: Re: [PATCH bpf-next v2 2/6] xdp: introduce xdp_call
On Mon, 25 Nov 2019 at 16:56, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Björn Töpel <bjorn.topel@...il.com> writes:
>
> > On Mon, 25 Nov 2019 at 12:18, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >>
> >> Björn Töpel <bjorn.topel@...il.com> writes:
> >>
> >> > From: Björn Töpel <bjorn.topel@...el.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".
Still, definitely worth a try. And configurable dispatcher size might
be a good idea as well! Thanks!
Cheers,
Björn
> -Toke
>
Powered by blists - more mailing lists