A principios de 2019, bpfilter todavía está en desarrollo y aún no se puede usar. El esqueleto básico está aquí e incluso puede activarse en núcleos 4.18+, pero no hace mucho por ahora, ya que no está completo. El código requerido para traducir reglas iptables a bytecode BPF, aunque enviado junto con el RFC original, no ha llegado al núcleo en este momento.

Una vez que esté listo, no debe haber ninguna herramienta específica requerida. Es probable que Bpfilter esté habilitado con algo como modprobe bpfilter, y luego la idea es reemplazar de forma transparente el back-end, dejando el front-end intacto: por lo que iptables debería ser la única herramienta necesaria para manejar las reglas, sin necesidad de ninguna opción en particular. Además, el bpftool permite inspeccionar los programas eBPF (incluidas las reglas iptables traducidas por bpfilter) cargados en el núcleo.

Puede comprobar esto si lo desea en el siguiente video (descargo de responsabilidad: por mi compañía), que muestra cómo usamos el filtro bp con una regla clásica de iptables (habíamos parcheado el núcleo con el código del RFC; y ejecutando el filtro bp.ko en la consola no será necesario en la versión final).

Aún puede conectar programas BPF al gancho XDP (a nivel de controlador), incluso sin usar bpfilter, para obtener un rendimiento mucho mejor que el que ofrece netfilter. Sin embargo, tendría que reescribir completamente sus reglas como programas en C, compilarlas en eBPF con clang y cargarlas con, por ejemplo, la herramienta ip (de iproute2). No se si esto coincidiría con su «conjunto de características». Dependiendo de lo fuerte que sea su necesidad, otra opción drástica podría ser mover su procesamiento de paquetes al espacio de usuario y volver a implementar su configuración con el marco DPDK.