Project

General

Profile

Actions

Feature #6114

open
LS LS

dpdk: wrap DPDK logs in a Suricata logger

Feature #6114: dpdk: wrap DPDK logs in a Suricata logger

Added by Lukas Sismis almost 3 years ago. Updated over 1 year ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

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

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 #4

The advice received from the DPDK users' mailing list

https://www.mail-archive.com/users@dpdk.org/msg07145.html

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
Actions

Also available in: PDF Atom