Project

General

Profile

Actions

Bug #2826

closed

afpacket doesn't wait for all capture threads to start (4.0.x)

Added by Victor Julien about 5 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

afpacket already starts processing packets on threads while others are still starting up. This time window can be significant if a sensor uses large bpfs or very large buffers or if there are many capture threads.

The synchronize start logic should prevent this, but does not work. It is broken for tpacket-v3 and disabled for tpacket-v2.

The effect can be that the hashing for load balancing is not stable during the start up phase. If a socket has 4 listening threads a certain flow may end up in queue 1, but when there are 5 threads the same flow may end up in queue 3.

I've observed this on several sensors, where the 'wrong_thread' counter is huge right after startup, but then stops increasing after that.

It can be easily simulated in the afpacket startup, by adding a sleep(tv->id) per thread which lets the threads sleep for increasingly longer times (t1 for 1s, t2 for 2s, etc). Before all threads are started packets are already being processed.


Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #2788: afpacket doesn't wait for all capture threads to startClosedVictor JulienActions
Actions #1

Updated by Victor Julien about 5 years ago

  • Copied from Bug #2788: afpacket doesn't wait for all capture threads to start added
Actions #2

Updated by Victor Julien about 5 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF