Refactor reentrant flag to be set during channel creation.

[Dimi1010]

Split of #1668

This PR aims to standardize m_ReentrantMode to be set during the channel opening phase instead of the capture initialization phase as it is determined by the opening flags. The currently used implementation essentially assumes the what the reentrant mode is based on the function being called to start the capture, instead of recording the correct value.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 82.84%. Comparing base (6d8b747) to head (565dd15). :warning: Report is 52 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #1738      +/-   ##
==========================================
- Coverage   82.85%   82.84%   -0.01%     
==========================================
  Files         291      291              
  Lines       51565    51564       -1     
  Branches    11162    11452     +290     
==========================================
- Hits        42723    42719       -4     
- Misses       7646     8031     +385     
+ Partials     1196      814     -382     

Flag	Coverage Δ
alpine320	74.60% <ø> (ø)
fedora42	74.72% <ø> (ø)
macos-13	81.07% <ø> (ø)
macos-14	81.07% <ø> (ø)
macos-15	81.07% <ø> (ø)
mingw32	69.87% <ø> (-0.04%)	:arrow_down:
mingw64	69.86% <ø> (-0.04%)	:arrow_down:
npcap	84.73% <ø> (-0.08%)	:arrow_down:
rhel94	74.45% <ø> (-0.03%)	:arrow_down:
ubuntu2004	58.77% <ø> (+<0.01%)	:arrow_up:
ubuntu2004-zstd	58.88% <ø> (+0.02%)	:arrow_up:
ubuntu2204	74.37% <ø> (ø)
ubuntu2204-icpx	60.78% <ø> (-0.05%)	:arrow_down:
ubuntu2404	74.62% <ø> (-0.01%)	:arrow_down:
ubuntu2404-arm64	74.61% <ø> (ø)
unittest	82.84% <ø> (-0.01%)	:arrow_down:
windows-2022	84.70% <ø> (-0.08%)	:arrow_down:
windows-2025	84.83% <ø> (-0.01%)	:arrow_down:
winpcap	84.94% <ø> (ø)
xdp	51.30% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[seladb]

@Dimi1010 this code was written many years ago so I don't remember all the details, but I think the PF_RING_REENTRANT flag should be set if multiple threads are going to read from the same PF_RING device. However, if we know that a single thread is going to read from a a PF_RING device then this flag is redundant because it has a performance cost.

The problem with the current implementation is that when opening the channels we don't know how many threads will read from them:

• We could open multiple channels, but only a single thread will read from them - the flag is redundant
• We could open multiple channels, and multiple threads will read from each of them - the flag is needed
• We could open a single channel, and multiple threads will read from it - the flag is needed
• We could open a single channel, and a single thread will read from it- the flag is redundant

In addition - if opening in reentrant mode then zero copy can't be used, hence the m_ReentrantMode private member.

We may need a bigger refactor to allow the user to choose when opening the device whether multiple threads will read from each channel (and set the flag accordingly), and when start capturing verify that we don't allow multiple threads to read from the same channel.

But this is something that needs further testing with a PF_RING environment to test in - do you have such an environment?

[Dimi1010]

We may need a bigger refactor to allow the user to choose when opening the device whether multiple threads will read from each channel (and set the flag accordingly), and when start capturing verify that we don't allow multiple threads to read from the same channel.

This would work. I think a bool in the openChannel functions would be enough. Something like multithreadedCaptureSupport that controls if the flag is used.

But this is something that needs further testing with a PF_RING environment to test in - do you have such an environment?

Not fully. I have a WSL to confirm compilation, but not sure if that will work for actual capture testing.

[seladb]

This would work. I think a bool in the openChannel functions would be enough. Something like multithreadedCaptureSupport that controls if the flag is used.

Yes, something like that could work

Not fully. I have a WSL to confirm compilation, but not sure if that will work for actual capture testing.

I'm not sure it'll work well with WSL, you may need to set up an Ubuntu VM. I use VirtualBox on Windows...

[Dimi1010]

Closing this as stale for now. Might work on it again eventually.