af-packet: speed up thread sync during startup #11828
Conversation
Threads are initialized sequentially to allow for a predictable mapping of threads and queues. Not all parts of the start up need to be done sequentially. The setting up of the rings can be very expensive, taking of a couple of hundred milliseconds. The ring setup doesn't need to be done sequentially though. This patch releases the thread early, after bind but before the ring setups. Ticket: OISF#7272.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #11828 +/- ##
==========================================
+ Coverage 82.57% 82.59% +0.01%
==========================================
Files 912 912
Lines 249357 249358 +1
==========================================
+ Hits 205918 205961 +43
+ Misses 43439 43397 -42
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: QA ran without warnings. Pipeline 22793 |
There was a problem hiding this comment.
Thanks for the work.
CI : ok
Commits segmentation : ok
Commit messages : ok
Git ID set : ok
CLA : you already contributed
Doc update : not needed
Redmine ticket : thanks for the ticket
Rustfmt : no rust
Tests : I do not think we have a good way to test such optimizations, do we ?
Dependencies added: none
Code : good
|
@victorjulien are you not merging this ? |
|
I think I saw one case where this didn't start up, but I did not record it. So want to do some more testing. |
|
I've been running this in a loop for a long time, and under load. Haven't seen issues. |
|
Merged in #12222, thanks! |
Threads are initialized sequentially to allow for a predictable mapping of threads and queues. Not all parts of the start up need to be done sequentially. The setting up of the rings can be very expensive, taking of a couple of hundred milliseconds. The ring setup doesn't need to be done sequentially though.
This patch releases the thread early, after bind but before the ring setups.
Ticket: #7272.
Replace #11806
https://redmine.openinfosecfoundation.org/issues/7272