The Hyperscan library itself is also single-threaded: instead, we provide facilities for
re-entrant use of the library (immutable database bytecode, scratch space per execution
context, etc) and leave control of the concurrency model up to the calling application.
So, the best way to use multiple cores with Snort 2.x and the Hyperscan patch right now is
still the traditional approach of running multiple processes. With Snort 3 and Suricata,
which have Hyperscan support in upstream already, you can scale across multiple cores with
a single process – and you get the memory usage advantages of not needing to duplicate all
the Hyperscan databases.
From: Hyperscan [mailto:email@example.com] On Behalf Of David Wharton
Sent: Friday, February 10, 2017 2:09 AM
Subject: Re: [Hyperscan] Hyperscan Snort patch v3 available (for Snort 126.96.36.199 and
Since Snort 2.9 is (largely) single threaded, if I run a single Snort process on a machine
with multiple CPUs/cores, will the Hyperscan library take advantage of all available cores
even though Snort can't?
On 01/16/2017 07:29 PM, Viiret, Justin wrote:
The Hyperscan team is pleased to announce the release of a new version of our patch
enabling Hyperscan use within Snort 2.x. This patch has been tested against Snort 188.8.131.52
(the same target as our previous patches) and Snort 184.108.40.206 (the current release).
This releases fixes the bug related to Snort reload on receipt of a HUP signal reported
late in December by 寻风之迹.
You can find it here: