On Tue, Nov 23, 2021 at 3:02 PM Maciej Żenczykowski <maze@xxxxxxxxxx> wrote: > > Note: this is more of an RFC... question in patch format... is this > even a good idea? > > On Tue, Nov 23, 2021 at 12:56 PM Maciej Żenczykowski > <zenczykowski@xxxxxxxxx> wrote: > > > > From: Maciej Żenczykowski <maze@xxxxxxxxxx> > > > > skfilter bpf programs can read the packet directly via llvm.bpf.load.byte/ > > /half/word which are 8/16/32-bit primitive bpf instructions and thus > > behave basically as well as DPA reads. But there is no 64-bit equivalent, > > due to the support for the equivalent 64-bit bpf opcode never having been > > added (unclear why, there was a patch posted). > > DPA uses a slightly different mechanism, so doesn't suffer this limitation. > > > > Using 64-bit reads, 128-bit ipv6 address comparisons can be done in just > > 2 steps, instead of the 4 steps needed with llvm.bpf.word. > > > > This should hopefully allow simpler (less instructions, and possibly less > > logic and maybe even less jumps) programs. Less jumps may also mean vastly > > faster bpf verifier times (it can be exponential in the number of jumps...). > > > > This can be particularly important when trying to do something like scan > > a netlink message for a pattern (2000 iteration loop) to decide whether > > a message should be dropped, or delivered to userspace (thus waking it up). > > > > I'm requiring CAP_NET_ADMIN because I'm not sure of the security > > implications... I don't know BPF_PROG_TYPE_SOCKET_FILTER very well, but the patch seems reasonable to me. It will be great if we can show the performance impact with a benchmark or a selftests. Thanks, Song
