On Wed, Oct 30, 2019 at 5:32 PM Toshiaki Makita <toshiaki.makita1@xxxxxxxxx> wrote: > > On 2019/10/28 4:17, David Miller wrote: > > From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > > Date: Sun, 27 Oct 2019 16:24:24 +0100 > > > >> 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. eBPF/XDP is faster only when you can by-pass/shortcut some code. If the number of features required are the same, then an eBPF implementation should be less than or equal to a kernel module's performance. "less than" because eBPF usually has some limitations so you have to redesign the data structure. It's possible that after redesigning your data structure to eBPF, it becomes faster. But there is no such case in my experience. Regards, William
