William Tu [off-list ref] writes:

On Thu, Nov 14, 2019 at 2:06 AM Toshiaki Makita
[off-list ref] wrote:

quoted

On 2019/11/13 2:50, William Tu wrote:

quoted

On Wed, Oct 30, 2019 at 5:32 PM Toshiaki Makita
[off-list ref] wrote:

quoted

On 2019/10/28 4:17, David Miller wrote:

quoted

From: Toke Høiland-Jørgensen <redacted>
Date: Sun, 27 Oct 2019 16:24:24 +0100

quoted

The results in the paper also shows somewhat disappointing performance
for the eBPF implementation, but that is not too surprising given that
it's implemented as a TC eBPF hook, not an XDP program. I seem to recall
that this was also one of the things puzzling to me back when this was
presented...

Also, no attempt was made to dyanamically optimize the data structures
and code generated in response to features actually used.

That's the big error.

The full OVS key is huge, OVS is really quite a monster.

But people don't use the entire key, nor do they use the totality of
the data paths.

So just doing a 1-to-1 translation of the OVS datapath into BPF makes
absolutely no sense whatsoever and it is guaranteed to have worse
performance.

1-to-1 translation has nothing to do with performance.

I think at least key size matters.
One big part of hot spots in xdp_flow bpf program is hash table lookup.
Especially hash calculation by jhash and key comparison are heavy.
The computational cost heavily depends on key size.

If umh can determine some keys won't be used in some way (not sure if it's
practical though), umh can load an XDP program which uses less sized
key. Also it can remove unnecessary key parser routines.
If it's possible, the performance will increase.

Yes, that's a good point.
In other meeting people also gave me this suggestions.

Basically it's "on-demand flow key parsing using eBPF"
The key parsing consists of multiple eBPF programs, and
based on the existing rules, load the program and parse minimum
necessary fields required by existing rules. This will definitely
have better performance.

See the xdp-filter program[0] for a simple example of how to do this
with pre-compiled BPF programs. Basically, what it does is generate
different versions of the same program with different subsets of
functionality included (through ifdefs). The feature set of each program
is saved as a feature bitmap, and the loader will dynamically select
which program to load based on which features the user enables at
runtime.

The nice thing about this is that it doesn't require dynamic program
generation, and everything can be compiled ahead of time. The drawback
is that you'll end up with a combinatorial explosion of program variants
if you want full granularity in your feature selection.

-Toke

[0] https://github.com/xdp-project/xdp-tools/tree/master/xdp-filter