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

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. If you are tempted to adopt pcap filters then check out pflua from Igalia: https://fosdem.org/2015/schedule/event/packet_filtering_pflua/ https://fosdem.org/2015/schedule/event/packet_filtering_pflu...