On Mon, 17 Jun 2024 23:43:19 +0300 Isaac Boukris <[email protected]> wrote:
> On Mon, Jun 17, 2024 at 10:37 PM Isaac Boukris <[email protected]> wrote: > > > > > Just a quick update that I still see the issue in my env with the > > > master branch (24.07.0-rc0), I'm now testing by adding the filter to > > > 'sample_filters' in test_bpf.c and running: > > > time sudo build/app/dpdk-test bpf_convert_autotest > > > > > > With 5 hosts it takes less than 2 secs, with 6 it takes about 25 secs, > > > i'll try to strace it maybe. > > > > strace was useless, no syscalls for ~18 secs, not sure how to debug it > > further, valgrind / callgrind don't work on dpdk.. > > > > It doesn't seem to be about the size though, I was able to produce > > larger bpf code with ipv4 addresses and it worked fine too. > > Debugged a bit further with gdb, it looks like it is stuck in a while > loop in lib/bpf/bpf_validate.c:evaluate(), there is a comment saying > "make sure we evaluate each node only once" but it seem to go back and > forth on the same idx's afaict. No idea, only original author understands the verifier. Having our own unique verifier may not be a good idea. There some other userspace BPF projects, seems like a good place for convergence. https://lpc.events/event/17/contributions/1639/attachments/1280/2585/userspace-ebpf-bpftime-lpc.pdf
