detect: Inline default pkt inspect engines

[coledishington]

Scenarios with a small number of rules, no MPM-based rules, experienced a 6%-14% performance degradation from the commit 0965afd66 detect: pkt inspect engines inwhich the default pkt inspect engines were converted to callbacks to simplify adding extra pkt inspect engines.

Avoid adding the default pkt inspect engines to the callback chain and instead call them directly in an inlined function within DetectRulePacketRules().

Bug: #6291

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• [✓] I have read the contributing guide lines at https://docs.suricata.io/en/latest/devguide/codebase/contributing/contribution-process.html
• [✓] I have signed the Open Information Security Foundation contribution agreement at https://suricata.io/about/contribution-agreement/
• [✓] I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable)

Link to redmine ticket: https://redmine.openinfosecfoundation.org/issues/6291

Describe changes: Updated from Suricata 4.0.6 to Suricata 7, this performance degradation was noticed on a setup with the following:

• 176 signatures
• 3 are inspecting packet payload
• 33 inspect application layer
• 83 are decoder event only This performance impact was significant when running a small number of lightweight rules, but was not significant on larger (and more heavy-duty) rule sets.

The changes make the default packet inspection engines inline, like they were in Suricata 4 before extra packet inspection engines were supported.

Provide values to any of the below to override the defaults.

No Suricata-verify test.

[codecov[bot]]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6896a93) 82.12% compared to head (395afd8) 82.13%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #10202      +/-   ##
==========================================
+ Coverage   82.12%   82.13%   +0.01%     
==========================================
  Files         975      975              
  Lines      271724   271701      -23     
==========================================
+ Hits       223151   223163      +12     
+ Misses      48573    48538      -35     

Flag	Coverage Δ
fuzzcorpus	62.79% <26.08%> (+0.06%)	:arrow_up:
suricata-verify	61.38% <91.30%> (-0.04%)	:arrow_down:
unittests	62.83% <26.08%> (-0.01%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

[catenacyber]

83 are decoder event only

I wonder if https://redmine.openinfosecfoundation.org/issues/6728 for decode-event would be more efficient in this scenario.

The idea would be to prefilter : a packet which has no decode events will not match any of these 83 rules (one check vs 83 checks)

[catenacyber]

ping @coledishington ?

[coledishington]

83 are decoder event only

I wonder if https://redmine.openinfosecfoundation.org/issues/6728 for decode-event would be more efficient in this scenario.

The idea would be to prefilter : a packet which has no decode events will not match any of these 83 rules (one check vs 83 checks)

Happy to close this one off if that optimisation is preferred.

[coledishington]

ping @coledishington ?

Sorry for the delay in my replies, I believe I have answered your questions.

[catenacyber]

I wonder if https://redmine.openinfosecfoundation.org/issues/6728 for decode-event would be more efficient in this scenario. The idea would be to prefilter : a packet which has no decode events will not match any of these 83 rules (one check vs 83 checks)

Happy to close this one off if that optimisation is preferred.

I will try to make some PR and ping you to test it ;-)

[catenacyber]

See https://github.com/OISF/suricata/pull/11328 for trying another optimization

[coledishington]

These changes are no longer needed with the performance enhancement https://github.com/OISF/suricata/pull/11366. Thanks @catenacyber