The linked page says "High level != inefficient" and shows an example program which will print "every TCP packet". With no "if" anywhere in the code, I wondered how it knew to print only TCP packets and not others. And the answer turns out to be that it throws a C++ exception on every non-TCP packet! If most of the packets on your network are TCP, this is sort of OK. But if you have mostly non-TCP packets, this toy p…
There are plenty of ways they can keep the current API while eventually approaching optimal, for example, a chain of exceptions could incrementally refine the framework's idea of what the callback function expects, which could be turned into a BPF filter. So for the cost of a few expensive frames at start, afterwards no exceptions get thrown. Generally speaking though, I'm only replying because I hate people negging…
If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point)
GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.".
While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.