Agree with Valeri Loukine that adding Multi-Queue into the diagram would complicate it a bit too much. Even though Check Point has its hooks into MQ, it is mainly a function of the NIC driver itself, is not directly part of Check Point's code, and is really more part of Gaia/Linux. Once you step over that dividing line between Gaia/Linux and Check Point's code (INSPECT, SecureXL, etc) and try to further document the box labelled "Interface" in Heiko Ankenbrand's diagram, you open a big can of worms. In my book I cover this process in a section called "A millisecond in the life of a frame"; it glosses over a few esoteric areas and the ordering may not be 100% accurate but it provides sufficient background for tuning efforts:
1) Frame arrives at NIC hardware off the wire
2) Frame placed in NIC hardware buffer (no space? ++RX-OVR)
3) Hardware interrupt begin
4) Transfer frame to NIC driver via DMA for handling
5) NIC driver performs basic error checking (frame corrupt? ++RX-ERR)
6) Place frame in receive socket buffer (none available? no registered receiver? ++RX-DRP)
7) Place descriptor referencing location of frame in the proper ring buffer (there will be more than one of these per interface if MQ enabled)
😎 Hardware interrupt end
some time later...
9) SoftIRQ run begins on SND/IRQ core
10) Process frames from ring buffer(s) and send to all registered receivers (i.e. SND, libpcap if tcpdump running)
11) Continue SoftIRQ run until all ring buffers are empty, maximum number of frames specified by net.core.netdev_budget (default 300) is reached, or two jiffies of time have elapsed
12) SoftIRQ run ends
And that was just the receive process for frames, didn't even get into the transmit process...
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com