Good idea. I configured Suricata to log pcap and alert debug logs. (Very useful features). Then I reconfigured suricata.yaml to only listen on two of the 46 queues. (That limits the deluge of information.) The end result is essentially what you suggested, a sampled dataset of alerts and the corresponding pcap.
I then used tshark to review the pcap and compare it to the alerts, although that’s still under review. There are some messages about “ACKed unseen segment, previous segment not captured”. I’ll have to compare with a pre-suricata capture of the traffic to really know if Suricata’s packet processing pipeline is dropping traffic. If not then it may involve dropped packets much farther upstream.
At this point I’m reading the source code and documentation to better understand the packet processing pipeline and stream engine with the approach I’m using. If there’s a system or suricata configuration induced problem I’d expect to find an indication in stats.log. (maybe undersized buffers… or cpu worker config. )
Fwiw I’m seeing the ioctl errors described here [1] but I don’t think they are related. I reviewed runmode-pfring.c and it suggests the errors are being generated because the pfring virtual interfaces are not capable of reporting/setting ethtool interface configuration info via ioctls. To be sure I compared all of the interface settings once more and find they are congruent with what runmode-pfring.c would expect.
[1] Failure when trying to set feature via ioctl - #3 by zlvinas