Slightly outdated example for "auto" runmode.
Suricata has multiple run modes, each of which initializes the threads, queues, and plumbing necessary for operation. These modes are usually tied to the choice of capture device and whether the mode is IDS or IPS. Example of capture devices: pcap, pcap file, nfqueue, ipfw, or a proprietary capture device. Only one run mode is chosen at startup -- the -i option is for pcap devices, -r for pcap files, -q for nfqueue, etc.
Modules are used to encapsulate a single primary function with lifecycle callbacks (e.g., init, deinit). Each thread in the packet pipeline is an instance of a module. These threads are initialized by the runmode defined in 'runmodes.c'. The runmode also initializes the queues and packet handlers used for moving packets between modules and queues. A thread is marked runnable after the all the steps from the runmode initialization are complete.
Management threads are used to perform tasks outside of the packet pipeline. More details on management threads should go here.
This information focuses on the pcap device runmode.
The pcap device is initialized using the name provided, for example: "eth0". Once a device is initialized it will begin gathering packets and passing them to Suricata. Suricata then acts as a thin wrapper around the data provided, making it compatible with the link type decoders.
Decoding is the process of taking a buffer and converting its content to a Suricata support data structure. These buffers are handed off to a specific link type decoder. The currently supported link types are as follows: LINKTYPE_LINUX_SLL, LINKTYPE_ETHERNET, LINKTYPE_PPP, LINKTYPE_RAW.
The detection module takes care of multiple complex tasks: loading all signatures, initializing detection plugins, creating detection groups for packet routing, and finally running packets through all applicable rules.