So, a couple of extra anecdotes from after I published that post.
I linked that post to our internal chat, and our support manager was all "Oh wow, that VLAN section totally explains why those filters at customer X two weeks ago didn't work". This is 4 years into trying to make sure that everyone using the filters to configure our system knows about this pitfall. They knew about a couple of failure modes in the list, but not all of them :-(
An hour after that I had a discussion with someone who knows the language very well, and we were puzzled about why the silly "look for a specific TCP option" filter was compiling to something that looked like it wouldn't work with ipv6. Turns out that while "tcp" works with IPv4 and IPv6, "tcp[]" works only on IPv4. He knew it but had forgotten, while I'd never parsed the documentation correctly to know about it. (There's a comment in the code generator suggesting that this is maybe not how things should work).
We have three main use cases for pcap filters (based on pflua) in Snabb Switch:
First is ad-hoc filtering in applications. "If this is an IPv6 control message for the address of interest then put the packet on this queue." The filter notation is convenient for this and if the filters run as fast as hand-written code then why not use them.
Second is end-user configuration. For example we have a "snabbnfv traffic" program that connects a 10G NIC to several QEMU virtual machines with Virtio-net. We support defining stateful packet filters by pcap filter expressions. This is a powerful tool that is already documented and familiar so it is easy for us to use in the interface. It is a power tool though and you can easily write an expression that does not do what you mean. (Happens to me too.)
Third is as an intermediate language. For example, we translate OpenStack "Security Group" rules (ACLs) into pcap filter expressions for the snabbnfv traffic process. This allows OpenStack to provide a simple and limited interface to the user and for us to map that onto our more general mechanism underneath. I see this as future proof in terms of supporting more front-ends besides OpenStack and also supporting extensions for special needs e.g. matching on exotic protocol headers.
So I am pretty happy with the current state of affairs. I do think there is a lot of potential for pflua to move things forward and I am looking forward to seeing more projects pick it up so that we can cooperate on this.
There are different trade-offs for the capture filter language and the display filter language.
The capture filter language considers short and bounded runtime (no loops) to be paramount. Roughly, when you're capturing, it's important that your filters eat a limited amount of resources. Juha talks about this in the article.
The display filter language abandons the careful runtime limits in favour of being more powerful. You can go higher up in the stack, you can use regexes, etc. That's acceptable because you're usually doing it offline.
The conclusion of Juha's article is, roughly, "the libpcap DSL is sometimes frustrating, but I'm not aware of a clearly better alternative". I agree. I'd love it if someone invented something prettier but still solid.
I linked that post to our internal chat, and our support manager was all "Oh wow, that VLAN section totally explains why those filters at customer X two weeks ago didn't work". This is 4 years into trying to make sure that everyone using the filters to configure our system knows about this pitfall. They knew about a couple of failure modes in the list, but not all of them :-(
An hour after that I had a discussion with someone who knows the language very well, and we were puzzled about why the silly "look for a specific TCP option" filter was compiling to something that looked like it wouldn't work with ipv6. Turns out that while "tcp" works with IPv4 and IPv6, "tcp[]" works only on IPv4. He knew it but had forgotten, while I'd never parsed the documentation correctly to know about it. (There's a comment in the code generator suggesting that this is maybe not how things should work).