# Real-World Data: AF\_PACKET tpacket-v3 vs v2 (Memory Impact) **URL:** \ **Category:** Uncategorized\ **Created:** [February 10, 2026, 12:26pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193 "2026-02-10T12:26:36Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![itcmsgr](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/itcmsgr/32/3812_2.png) [@itcmsgr](https://forum.suricata.io/u/itcmsgr)\ **Post date:** [February 10, 2026, 12:26pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/1 "2026-02-10T12:26:36Z")
I’d like to share production data showing the **memory impact of enabling `tpacket-v3`** when using AF\_PACKET capture mode in Suricata. #### Test Environment - Suricata **7.x** - ~ **48,000 ET Open rules** - AF\_PACKET + `use-mmap` - Multiple distros, identical configs where possible #### Measured Results (Production) | Server | OS | Before (v2) | After (v3) | Reduction | | --- | --- | --- | --- | --- | | Alma #1 | AlmaLinux 9.7 | **1,828 MB** | **454 MB** | **75%** | | Alma #2 | AlmaLinux 9.7 | ~900 MB | **168 MB** | **81%** | | Alma #3 | AlmaLinux 9.7 | ~900 MB | **167 MB** | **81%** | | Ubuntu | 24.04 | n/a | 358 MB | (already v3) | Ubuntu 24.04 already defaults to tpacket-v3; Alma/RHEL do not. * * * #### Root Cause - **TPACKET\_V2** uses **fixed-size ring buffers** sized for worst-case MTU - Memory scales as: `ring-size × block-size × threads` - With large rings (e.g. 100k), this alone can exceed **700–900 MB** **TPACKET\_V3** uses **variable-sized blocks** , allocating based on actual traffic, not worst-case assumptions. * * * #### The Clue in Logs Before the fix: ```auto [Warning] - AF_PACKET tpacket-v3 is recommended for non-inline operation ``` This warning disappears after enabling v3. * * * #### Fix (30 seconds) ```auto af-packet: - interface: eth0 use-mmap: yes tpacket-v3: yes ``` Or: ```auto sed -i '/use-mmap: yes/a\ tpacket-v3: yes' /etc/suricata/suricata.yaml systemctl restart suricata ``` * * * #### Impact in Practice Before: - Suricata consumed **45% of RAM** on 4 GB VPS nodes - Swap activity during `suricata-update` - OOM risk under load After: - Memory ~ **10% of system RAM** - No swap pressure - Faster reloads - More predictable performance * * * #### Recommendation Always explicitly set: ```auto tpacket-v3: yes ``` …regardless of distro. It’s a **zero-cost optimization** with **massive memory savings** on systems that still default to v2. ### ---
**Author:** ![itcmsgr](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/itcmsgr/32/3812_2.png) [@itcmsgr](https://forum.suricata.io/u/itcmsgr)\ **Post date:** [February 10, 2026, 12:59pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/2 "2026-02-10T12:59:20Z")
**Update / correction: After further testing on multiple Ubuntu 24.04 systems, my earlier assumption that Ubuntu defaults to TPACKET\_V3 was incomplete. . Details below.** ## Distro-Specific Defaults | Distribution | Package | Default | | --- | --- | --- | | Ubuntu 24.04 | apt | **v2** | | Debian 12 | apt | **v2** | | AlmaLinux 9 | EPEL | **v2** | | Rocky Linux 9 | EPEL | **v2** | | Centos 10 | EPEL | v2 or v3 (varies) | | | | | ## Ring Buffer Math Example With tpacket-v2: ```auto 100000 × 2048 bytes × 4 threads ≈ 780 MB ``` With tpacket-v3: ```auto Memory allocated dynamically based on packet sizes Typical: ~100–200 MB ``` ## Performance Summary | Metric | v2 | v3 | Result | | --- | --- | --- | --- | | Memory usage | 900–1800 MB | 160–450 MB | 75–81% less | | Ring efficiency | Fixed | Variable | Better | | Packet loss | Higher | Lower | Improved | | CPU overhead | Slightly higher | Slightly lower | Marginal | ---
**Author:** ![ish](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/ish/32/8_2.png) [@ish](https://forum.suricata.io/u/ish)\ **Post date:** [February 10, 2026, 4:55pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/3 "2026-02-10T16:55:18Z")
Thanks for the info, this is great. Can you tell me where you see `v3` enabled by default for Suricata 7.0? On Ubuntu, I don’t see it enabled by default in Ubuntu’s repos, or our own PPA. Likewise for CentOS/EPEL 10. I’m just trying to figure out where/how it’s enabled by default. Suricata 8.0 uses `v3` by default though. ---
**Author:** ![itcmsgr](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/itcmsgr/32/3812_2.png) [@itcmsgr](https://forum.suricata.io/u/itcmsgr)\ **Post date:** [February 10, 2026, 5:56pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/4 "2026-02-10T17:56:25Z")
Thanks for the notice. After rechecking all my Ubuntu 24.04 lab systems, I can confirm why this was confusing. The stock Ubuntu `suricata.yaml` has both `use-mmap` and `tpacket-v3` commented out, so TPACKET\_V3 is **not explicitly enabled by the package** (Jason’s statement is correct). However, once `use-mmap: yes` is enabled **without setting `tpacket-v3`** , Suricata appears to auto-select **TPACKET\_V3** at runtime on Ubuntu 24.04 (based on stats and memory behavior). This explains why Ubuntu systems seemed to be “already on V3”. This behavior was **not observed on RPM-based distributions** , which is why it wasn’t noticeable before. To avoid ambiguity across distros, explicitly setting: ```auto use-mmap: yes tpacket-v3: yes ``` is the only portable way to guarantee V3. Can someone confirm whether Suricata 7.x intentionally auto-selects `PACKET_VERSION=3` when `tpacket-v3` is unset? ---
**Author:** ![ish](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/ish/32/8_2.png) [@ish](https://forum.suricata.io/u/ish)\ **Post date:** [February 10, 2026, 6:06pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/5 "2026-02-10T18:06:19Z")
I checked, and `use-mmap` does not enable `tpacket-v3` as its always enabled, for example, if you try to set it to false: ```auto W: af-packet: br0: "use-mmap" option is obsolete: mmap is always enabled ``` This option has been removed in 8 completely, and just exists in 7 to provide a warning as needed that it can be removed. Note: I’m not questioning your results. Just trying to track down if any packages do happen to enable it by default. ---
**Author:** ![itcmsgr](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/itcmsgr/32/3812_2.png) [@itcmsgr](https://forum.suricata.io/u/itcmsgr)\ **Post date:** [February 10, 2026, 8:55pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/6 "2026-02-10T20:55:55Z")
Jason, thanks for the patience and for pointing me in the right direction. After rebuilding multiple Ubuntu 24.04 systems from scratch and validating with strace, I can confirm my earlier conclusion was incorrect. What went wrong in my initial test I initially assumed: presence of capture.afpacket.polls stats ⇒ TPACKET\_V3 absence of poll stats ⇒ TPACKET\_V2 This assumption was wrong. Both TPACKET\_V2 and TPACKET\_V3 use poll(). The afpacket.polls counter only shows that Suricata is polling the AF\_PACKET socket, not which PACKET\_VERSION is in use. So stats alone are not sufficient to distinguish V2 vs V3. What actually proves the PACKET version The only definitive proof is the kernel call: setsockopt(fd, SOL\_PACKET, PACKET\_VERSION, &version, sizeof(version)) Where: 1 = TPACKET\_V2 2 = TPACKET\_V3 Using strace -e setsockopt, I verified the following on a clean Ubuntu 24.04.3 LTS install: Verified results (Suricata 7.0.3, Ubuntu universe package) Default config (both commented): #use-mmap: yes #tpacket-v3: yes → setsockopt(PACKET\_VERSION, [1]) // V2 Explicit tpacket-v3: false: → setsockopt(PACKET\_VERSION, [1]) // V2 Explicit tpacket-v3: yes: → setsockopt(PACKET\_VERSION, [2]) // V3 Conclusion (correction) Ubuntu does not enable TPACKET\_V3 by default use-mmap being present or obsolete is not relevant Poll-based stats are not an indicator of V3 Jasons statement was correct The only portable and unambiguous way to enable V3 is: tpacket-v3: yes Jason thanks again for the guidance — this helped clarify both my misunderstanding and the correct way to validate PACKET\_VERSION reliably. ---
**Author:** ![itcmsgr](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/itcmsgr/32/3812_2.png) [@itcmsgr](https://forum.suricata.io/u/itcmsgr)\ **Post date:** [February 10, 2026, 9:16pm UTC](https://forum.suricata.io/t/real-world-data-af-packet-tpacket-v3-vs-v2-memory-impact/6193/7 "2026-02-10T21:16:27Z")
**Final clarification with full lab comparison (root cause identified)** I extended the testing to a full multi-distro lab comparison. With this data, the root cause of the memory differences is now clear. ### Complete lab server comparison ```auto ● Proof - Before vs After ● ┌────────┬───────────────┬──────────┬─────────┬──────┬────────────────────┬───────────────────┬───────────────┐ │ Server │ Distro │ Suricata │ CPU │ RAM │ ring-size (before) │ ring-size (after) │ Memory Change │ ├────────┼───────────────┼──────────┼─────────┼──────┼────────────────────┼───────────────────┼───────────────┤ │ lab │ Debian 12 │ 6.0.10 │ 2 cores │ 3.7G │ 300,000 │ 20,000 │ 1,600→652 MB │ ├────────┼───────────────┼──────────┼─────────┼──────┼────────────────────┼───────────────────┼───────────────┤ │ lab1 │ AlmaLinux 9.7 │ 7.0.13 │ 2 cores │ 3.5G │ 100,000 │ 20,000 │ 804→533 MB │ ├────────┼───────────────┼──────────┼─────────┼──────┼────────────────────┼───────────────────┼───────────────┤ │ lab2 │ Ubuntu 24.04 │ 7.0.3 │ 2 cores │ 3.7G │ 20,000 │ 20,000 │ 45→102 MB │ ├────────┼───────────────┼──────────┼─────────┼──────┼────────────────────┼───────────────────┼───────────────┤ │ lab3 │ AlmaLinux 9.7 │ 7.0.13 │ 2 cores │ 3.5G │ 100,000 │ 20,000 │ 482→531 MB │ ├────────┼───────────────┼──────────┼─────────┼──────┼────────────────────┼───────────────────┼───────────────┤ │ lab4 │ AlmaLinux 9.7 │ 7.0.13 │ 2 cores │ 3.5G │ 100,000 │ 20,000 │ 806→531 MB │ └────────┴───────────────┴──────────┴─────────┴──────┴────────────────────┴───────────────────┴───────────────┘ Current labs are 2-core/~3.5GB systems *lab2 increased because mmap was enabled (better performance) ``` ### Key findings **Memory correlates directly with `ring-size`, not with TPACKET version** ```auto ┌─────────────────────┬─────────┐ │ ring-size │ Memory │ ├─────────────────────┼─────────┤ │ 300000 │ ~1.6 GB │ │ 100000 │ ~800 MB │ │ default (commented) │ ~44 MB │ └─────────────────────┴─────────┘ ``` ### What this proves 1. **Ubuntu 24.04 (lab2)** uses very little memory because: 2. **AlmaLinux systems (lab1/lab3/lab4)** consume ~800 MB because: 3. **Debian system (lab)** consumes ~1.6 GB because: ### Why my initial conclusion was wrong In my original testing, I incorrectly attributed the lower memory usage on Ubuntu to TPACKET\_V3. After rebuilding systems from scratch and validating with `strace`, it is clear that: - Ubuntu 24.04 Suricata 7.0.3 defaults to **TPACKET\_V2** - The memory difference was **not caused by V2 vs V3** - The real drivers were **ring-size and mmap configuration** ### Final conclusions - Ubuntu 24.04 Suricata 7.0.3 defaults to **TPACKET\_V2** (verified via `setsockopt(PACKET_VERSION, [1])`) - V2 vs V3 has **minimal impact on memory usage** - **Ring-size dominates AF\_PACKET memory usage** - To enable V3 explicitly and portably: Thanks for the discussion — the extended lab testing clarified both my earlier mistake and the real source of the memory differences.