As of early 2019, bpfilter is still under development and not usable yet. The basic skeleton is here and may even be activated in 4.18+ kernels, but does not do much for now as it is not complete. The code required for translating iptables rules to BPF bytecode, although submitted along the original RFC, has not made it to the kernel at this time.
Once it gets ready, there should not be any specific tooling required. Bpfilter will likely be enabled with something such as modprobe bpfilter, and then the whole idea is to transparently replace the back end, while leaving the front end untouched: so iptables should be the only tool required for handling the rules, without any particular option required. Additionally, the bpftool allows to inspect the eBPF programs (including iptables rules translated by bpfilter) loaded in the kernel.
You can check this if you want in the following video (disclaimer: by my company), which shows how we used bpfilter with a classic iptables rule (we had patched the kernel with the code from the RFC; and executing the bpfilter.ko in the console will not be necessary on the final version).
You can still attach BPF programs to the XDP hook (at the driver level), even without using bpfilter, to get much better performance than what netfilter offers. However, you would have to completely rewrite your rules as C programs, compile them into eBPF with clang, and load them with e.g. the ip tool (from iproute2). I don't know if this would match your “feature set”. Depending on how strong is your need, another drastic option could be to move your packet processing to user space and to reimplement your setup with the DPDK framework.
