Instead of using flags to indicate a rule type, use an explicit `type`
field.
This will make it more clean in code paths what paths a rule is taking,
and will allow easier debugging as well as analyzer output.
Define the following fields:
- SIG_TYPE_IPONLY: sig meets IP-only criteria and is handled by the IP-only
engine.
- SIG_TYPE_PDONLY: sig inspects protocol detection results only.
- SIG_TYPE_DEONLY: sig inspects decoder events only.
- SIG_TYPE_PKT: sig is inspected per packet.
- SIG_TYPE_PKT_STREAM: sig is inspected against either packet payload or
stream payload.
- SIG_TYPE_STREAM: sig is inspected against the reassembled stream
- SIG_TYPE_APPLAYER: sig is inspected against an app-layer property, but not
against a tx engine.
- SIG_TYPE_APP_TX: sig is inspected the tx aware inspection engine(s).
Ticket: #6085.
Pseudo packets originating in the flow worker do not need to leave the
flow worker. Putting those in the ThreadVars::decode_pq will make them
be evaluated by the next steps in the pipeline, but those will all
ignore pseudo packets.
Instead, this patch returns them to the packet pool, while still honoring
the IPS verdict logic.
For the rules profiling, we really want to limit the performance
impact to the maximum. So let's use an hash size that is a power
of 2. This will allow to not use the modulo operation that is
costly and simply use a single binary operator.
This code is only active for rules profiling so we are backward
compatible.
This patch adds a new unix command that allows the user to trigger
a dump of the ruleset profile to the file without having to stop
Suricata.
This will be really useful to debug performance issue related to
signatures in production environment.
Performance measurement of rules is important on live Suricata
as bad rules can cause severe performance regression. This patch
introduces the --enable-profiling-rules that activate profiling
for the rules. This reduces the performance impact of full
profiling and provide visiblity on the rules performance at
the same time.
Segmented mbufs should never happen in Suricata.
Mbuf segmentation divides the received packet into multiple
mbufs. This can happen when MTU of the NIC is larger than
the allocated mbufs in the mbuf mempool. As Suricata sets the size
of the mbuf to be slightly higher than the configured MTU, mbuf
segmentation should never happen in Suricata. This is especially
true, if Suricata runs as a primary process and configures the
packet source (NIC).
Processing segmented mbufs can lead to missed/false
(pattern-matching) detections as Suricata only inspects the first
segment of the packet. It can also lead to segfault if Suricata
moves the detection window out of the segment boundaries.
Function rte_eth_stats_get is not thread-safe and
the result is only used by one thread.
Running with multiple workers led to very high values in rx_missed
counters (buffer-overflow-like behavior).
Ticket: #6006
Flow house keeping can accumulate work that wasn't taken into account
during shutdown. This could lead to flows still in the flowworker
thread context when being it was freed, leading to missed work and
memory leaks.
This patch adds a new way of checking if a thread module is still
busy.
Bug: #6062.
Until this patch the logic the flow worker flow house keeping used was:
- at most 2 flows are handled per packet
- pseudo packets could flush the entire queue
This patch changes that. Pseudo packets are fairly common, and can lead
to packet stalls / latency spikes if the number of flows in the queue
is large.
It does that by adding a new packet type only used at shutdown, which
flushes out the queues completely. All other packets will now stick
to the 2 flow rate limit.