We currently do not support internal load balancing; however the general assumption should be a given flow will always be handed to the same thread. There is some support for external load balancing with afpacket, but it still holds to that same assumption.
One Module and one Plugin is created globally. From there, pinit/pterm (called once) and tinit/tterm (called per thread, not at reload at the moment) can be used to set up data structures as needed. Calls to ::configure should be used to read in new Module data, especially if it interacts with other plugins as at that point, they have all been instantiated.
I thought individual packets/tracked connections are balanced between threads. If that's not the case then indeed there's probably no need.
Is there new Module instance created per each thread? Or do Option objects in all threads share single "parent" Module object?
On Mon, 11 Mar 2019, 13:38 Carter Waxman (cwaxman), <firstname.lastname@example.org> wrote:
There shouldn’t be any critical sections in an ips options. The current threading model places 1 interface set / pcap per thread, so threads shouldn’t need to share any data with each other. What global data are you trying to share?
How does multi threading work in Snort 3? I mean - i made IPS Option and I want it to be stateful (as in use global data shared amongst all ips option instances). However from what I saw in manual Snort 3 support multi threading. So how do I handle critical sections in IPS Option module code? Can I just use pthread mutexes? Or is there some other recommended way?