Any reason to keep "--disable-protochain" configure option?

[fxlb]

The only information I found is the commit 5b7ead9 with
title:
add configure option --disable-protochain, to make Arne happier.
and in it a comment:
dnl to pacify those who hate protochain insn.

[infrastation]

Would you like to add some filter tests for protochain? This often helps to identify discrepancies with documentation and space for potential improvements.

[infrastation]

These tests would need to be conditional on the NO_PROTOCHAIN macro in config.h.

[fxlb]

Same question sent to the Mailing List on 17/02/2025.

[infrastation]

Commits af0312e and dd3c932 implement the tests.

[infrastation]

A bit more in commits bc10764 and 732df31.

[infrastation]

See also cilium/pwru#549.

[infrastation]

For posterity, a substantial problem with the current implementation is that it implements a loop using ja with a negative offset (e.g. #1521), which is not valid in kernel BPF implementations and thus causes userland filtering. This is likely the motivation for having the build option.

The best alternative to this approach I can currently see would be to implement the same as what Caper BPF generator implements: produce a fixed number of code paths to allow up to N levels of the IPv6 headers.

This would generate quite some more instructions and a fixed choice of N may not fit every use case, so a possible solution to that could be defaulting N to some sensible value (e.g. 4) and allowing to change it for a pcap_t before compiling the filter using something along these lines:

pcap_setopt(p, PCAP_PROTOCHAIN_LIMIT, 8);

See also #1133.

[guyharris]

The best alternative to this approach I can currently see would be to implement the same as what Caper BPF generator implements: produce a fixed number of code paths to allow up to N levels of the IPv6 headers.

I.e., limiting the number of trips through the loop and unrolling the loop.

[infrastation]

Yes, exactly.