@ -15,7 +15,7 @@ There are a few ways of testing Suricata:
- **Static and dynamic analysis tools**: to help in finding bugs, memory leaks and other issues (like `scan-build <https://clang-analyzer.llvm.org/scan-build.html#scanbuild_basicusage>`_, from `clang`, which is also used for our C formatting checks; or ASAN, which checks for memory issues);
- **Fuzz testing**: especially good for uncovering existing, often non-trivial bugs. For more on how to fuzz test Suricata, check :doc:`fuzz-testing`;
- **CI checks**: each PR submitted to the project's public repositories will be run against a suit of Continuous Integration
workflows, as part of our QA process. Those cover: formatting and commit checks; fuzz tests (CI Fuzz), and several builds. See our `github workflows <https://github.com/OISF/suricata/tree/main/.github/workflows>`_ for details and those in
workflows, as part of our QA process. Those cover: formatting and commit checks; fuzz tests (CI Fuzz), and several builds. See our `github workflows <https://github.com/OISF/suricata/tree/main/.github/workflows>`_ for details and those in
action at `<https://github.com/OISF/suricata/actions>`_.
..note:: If you can run unit tests or other checks and report failures in our `issue tracker <https://redmine.openinfosecfoundation.org/projects/suricata/issues>`_, that is rather useful and appreciated!
@ -144,7 +144,7 @@ The Frame API calls parameters represent:
- ``frame_type``: type of frame it's being registering (defined in an enum, as shown further above)
- ``tx_id``: an optional transaction id, if the frame belongs to a transaction. May be set later like `frame_len`
``StreamSlice`` contains the input data to the parser, alongside other Stream-related data important in parsing context. Definition is found in *applayer.rs*:
``StreamSlice`` contains the input data to the parser, alongside other Stream-related data important in parsing context. Definition is found in *applayer.rs*:
@ -241,9 +241,9 @@ In the af-packet section of suricata.yaml config :
block-size: 1048576
That way 36 worker threads can be mapped (18 per each af-packet interface slot)
in total per CPUs NUMA 1 range - 18-35,54-71. That part is done via the
in total per CPUs NUMA 1 range - 18-35,54-71. That part is done via the
``worker-cpu-set`` affinity settings. ``ring-size`` and ``block-size`` in the
config section above are decent default values to start with. Those can be
config section above are decent default values to start with. Those can be
better adjusted if needed as explained in :doc:`tuning-considerations`.
AMD based systems
@ -359,7 +359,7 @@ this config is positioned on NUMA 0 so starting with 15 RSS queues on that
NUMA node and keeping those off for other tools in the system could offer the
best advantage.
..note:: Performance and optimization of the whole system can be affected upon regular NIC driver and pkg/kernel upgrades so it should be monitored regularly and tested out in QA/test environments first. As a general suggestion it is always recommended to run the latest stable firmware and drivers as instructed and provided by the particular NIC vendor.
..note:: Performance and optimization of the whole system can be affected upon regular NIC driver and pkg/kernel upgrades so it should be monitored regularly and tested out in QA/test environments first. As a general suggestion it is always recommended to run the latest stable firmware and drivers as instructed and provided by the particular NIC vendor.
Lukas Sismis
8 months ago
committed by
Victor Julien