# A question about the AF\_PACKET TPACKET\_V3 implementation

**URL:** <https://forum.suricata.io/t/a-question-about-the-af-packet-tpacket-v3-implementation/6415>\
**Category:** Developers\
**Tags:** suricata\
**Created:** [July 16, 2026, 9:27pm UTC](https://forum.suricata.io/t/a-question-about-the-af-packet-tpacket-v3-implementation/6415 "2026-07-16T21:27:08Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jal](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/jal/32/3948_2.png) [@Jal](https://forum.suricata.io/u/Jal)\
**Post date:** [July 16, 2026, 9:27pm UTC](https://forum.suricata.io/t/a-question-about-the-af-packet-tpacket-v3-implementation/6415/1 "2026-07-16T21:27:08Z")

</div>

Hi,

While reading the AF\_PACKET TPACKET\_V3 implementation in Suricata,I have a question and hope to gain some insight

In `AFPReadFromRingV3()`, the ownership of a block is returned to the kernel by writing:

```auto
pbd->hdr.bh1.block_status = TP_STATUS_KERNEL;

```

and block readiness is checked by directly reading `block_status`.

I noticed that libpcap introduced acquire/release semantics for the same ownership transfer in the following commit:

> <https://github.com/the-tcpdump-group/libpcap/commit/a1119a18874410d4d51a61d2e582d25b7c578a54>
>
> Release and acquire packets using GCC builtins (compatible with
> many other commo…n-place compilers).
> 
> Should fix #898.

using `__atomic_load_n(...,__ATOMIC_ACQUIRE)` and `__atomic_store_n(...,__ATOMIC_RELEASE)`.

I was wondering whether Suricata intentionally relies on plain loads/stores here, or whether there are assumptions about the AF\_PACKET implementation that make explicit acquire/release semantics unnecessary.

It’s entirely possible that I’m missing some background or historical context, so I’d appreciate any insight into the reasoning behind the current implementation.

I’d appreciate any explanation or pointers if this has already been discussed.

Thank you!

---

<div class="post-metadata">

**Author:** ![lukashino](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/lukashino/32/1150_2.png) [@lukashino](https://forum.suricata.io/u/lukashino)\
**Post date:** [July 17, 2026, 8:21am UTC](https://forum.suricata.io/t/a-question-about-the-af-packet-tpacket-v3-implementation/6415/2 "2026-07-17T08:21:08Z")

</div>

Hi Jal,

Considering the age of the code (contributed 12 years ago), I don’t think there is a particular reason why it is like that.

If I understand that correctly, the right solution would be to change the access to atomic, as there is a potential for concurrent edits by kernel/application threads?

Thanks.

---

<div class="post-metadata">

**Author:** ![Jal](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/jal/32/3948_2.png) [@Jal](https://forum.suricata.io/u/Jal)\
**Post date:** [July 20, 2026, 2:21am UTC](https://forum.suricata.io/t/a-question-about-the-af-packet-tpacket-v3-implementation/6415/3 "2026-07-20T02:21:58Z")

</div>

Hi Lukas,

Thanks for the clarification.

Yes, I agree with your understanding. I appreciate the insight.

Thanks again.