Feature #6114
opendpdk: wrap DPDK logs in a Suricata logger
Description
Analyze the plausibility of wrapping DPDK logs into the Suricata logger. If it is possible then implement it.
Example of the inconsistent output
Files
Updated by Lukas Sismis over 1 year ago
- Subject changed from dpdk: wrap DPDK logs in Suricata logger to dpdk: wrap DPDK logs in a Suricata logger
Updated by Lukas Sismis over 1 year ago
DPDK does not have any logging callbacks implemented. I could however think of one solution.
There could be a separate thread called e.g. SC_DPDK_LOGGER. This thread would have access to a pipe. The pipe would receive logs from the DPDK and SC_DPDK_LOGGER thread would periodically read from this pipe. The content would then be parsed into individual messages where e.g. delimiter would be a newline character. Each message then can be logged through the SCLogInfo() logger in the SC_DPDK_LOGGER thread. On the DPDK side, the DPDK logging destination could be configured by using rte_openlog_stream(). The default logging destination for DPDK is stderr by default.
How this could work is illustrated on the image below.
Pros:
- all messages are logged through DPDK
- the output is unified
Cons:
- yet another management thread
- DPDK message output might not be instantaneous
- a quite complex solution and a bit hackish it seems
Would appreciate any feedback
Updated by Lukas Sismis over 1 year ago
- File clipboard-202306221747-cb94u.png clipboard-202306221747-cb94u.png added
- Description updated (diff)
Updated by Lukas Sismis over 1 year ago
The advice received from the DPDK users' mailing list
Updated by Jason Ish over 1 year ago
Makes sense. One thread waiting on a stream isn't much. Ideally we'd already have an existing, non packet capture thread in a select/poll loop, and we only have that in the UNIX socket which is optional, so not ideal for hooking into.
Updated by Victor Julien over 1 year ago
- Priority changed from Low to Normal
- Target version changed from 7.0.0 to 8.0.0-beta1