Bug #6009
closed
dpdk: incorrect final stats
Added by Lukas Sismis over 1 year ago.
Updated about 1 year ago.
Description
In more performant deployments (on live networks) where Suricata has more cores/allocated bigger chunks of memory, it takes some time between getting out of the loop and getting into deinit phase of the DPDK module. During this, the NIC is still enabled and the NIC account the undelivered packets as missed (dropped). As a result, the final stats that are e.g. printed in ExitStats function are not valid and they propose worse result than what Suricata actually reached. (e.g. not dropping packets at all when running and during the deinit phase it can increase to 10% of dropped packets)
I can see two solutions:
- do not rely on the device stats after jumping out of the Loop function
- stop the device immediately as the loop is discontinued
I think this is a generic issue that also affects other capture methods potentially. It can also happen during init. IIRC af-packet has some special logic for the init side.
Does it make sense to "fix" it (at least on the DPDK side)?
I can imagine I would be able to fix it but that would possibly change the logic a bit by moving starting/shutting process of the init/deinit stage to the loop directly to minimize the gap between the start/shutdown of the device and actual reading.
- Priority changed from Normal to Low
- Status changed from New to Assigned
- Target version changed from 7.0.0-rc2 to 7.0.0
- Target version changed from 7.0.0 to 7.0.1
- Priority changed from Low to Normal
- Target version changed from 7.0.1 to 7.0.2
- Status changed from Assigned to In Progress
- Status changed from In Progress to Closed
Also available in: Atom
PDF