Feature #6114
opendpdk: wrap DPDK logs in a Suricata logger
Added by Lukas Sismis almost 3 years ago. Updated over 1 year ago.
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
| clipboard-202306221714-u2wfs.png (101 KB) clipboard-202306221714-u2wfs.png | Lukas Sismis, 06/22/2023 03:14 PM | ||
| clipboard-202306221747-cb94u.png (71.9 KB) clipboard-202306221747-cb94u.png | Lukas Sismis, 06/22/2023 03:47 PM |
LS Updated by Lukas Sismis almost 3 years ago Actions #1
- Subject changed from dpdk: wrap DPDK logs in Suricata logger to dpdk: wrap DPDK logs in a Suricata logger
LS Updated by Lukas Sismis almost 3 years ago Actions #2
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
LS Updated by Lukas Sismis almost 3 years ago Actions #3
- File clipboard-202306221747-cb94u.png clipboard-202306221747-cb94u.png added
- Description updated (diff)
LS Updated by Lukas Sismis almost 3 years ago Actions #4
The advice received from the DPDK users' mailing list
JI Updated by Jason Ish almost 3 years ago Actions #5
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.
VJ Updated by Victor Julien almost 3 years ago Actions #6
- Priority changed from Low to Normal
- Target version changed from 7.0.0 to 8.0.0-beta1
VJ Updated by Victor Julien over 1 year ago Actions #7
- Target version changed from 8.0.0-beta1 to 9.0.0-beta1