In the other blog post (linked from the top of this blog post) I wrote about the motivation for using the Wireshark-like syntax and how we also have a few custo

In the other blog post (linked from the top of this blog post) I wrote about the motivation for using the Wireshark-like syntax and how we also have a few customers with a lot of rules (tens of thousands and greater). That said, it seems obvious to us that now we have a Rust library that can parse a Wireshark-like syntax into an AST... that we don't have to just perform the matching in Rust. i.e. that we can ask the library to produce translations of the expression as SQL (for our ClickHouse), GraphQL (for our analytics API), or even eBPF. We can't run everything in eBPF, but we could check the list of the fields within an expression to see whether it could be run in eBPF, and then look at heavy hitter rules and promote the ones doing the most work inside L7 to be eBPF and to run in XDP. Even if we don't do this for customer configured rules, this might be something we do for handling denial of service attacks using the same Wireshark-like expression syntax throughout our system.