Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[draft] lib: example usage and "lib" runmode - v4 #11711

Closed
wants to merge 13 commits into from

Conversation

jasonish
Copy link
Member

@jasonish jasonish commented Sep 3, 2024

amirabell and others added 13 commits September 3, 2024 11:29
Add library source and runmode modules. Reorganized
library example to create a worker thread and replay a pcap
file using the library mode.
No API layer is added at this stage.

Edits by Jason Ish:
- fix guard
- add copyright/license headers
To keep the simple example simple, move the lib based capture method
example to its own example.
- the generated binaries for lib examples
- LSP files
- man pages
Worker threads not created by Suricata, but instead a library user
should not be joined, as Suricata does not have access to their thread
handle, and it may in-fact be an unjoinable thread, such as the main
process.

When the thread ID is 0, assume the thread is "externally" managed,
but still mark is as dead to satisfy Suricata's view of the thread.
Use the more conventional "--" command line handling to separate the
arguments. The first set will be passed to Suricata, and the args
after "--" will be handled by the example. Currently this is a single
PCAP filename, but will be extended to a list of PCAP filenames.
Also use a proper return type (ThreadVars *).
Update ThreadVars creation in lib mode to have the worker_id provided
by the user.
In the library capture example, show how the packet counter can be
updated.
The variable run is not needed, we can just run an infinite loop and
break when needed.
Refactor TmThreadsSlotPktAcqLoop for user provided thread by breaking
out the init and finish code into their own functions.

For user provided threads, Suricata should not "drive" the thread, but
the setup and finish code is the same.

The finish function is exported so it can be called by the user
application when its receive loop or equivalent is done.
Also remove function to set the library mode. This is easy enough to
do with SCRunmodeSet, and we don't want to add a specific setter for
each and every runmode.
Copy link

codecov bot commented Sep 3, 2024

Codecov Report

Attention: Patch coverage is 24.53988% with 123 lines in your changes missing coverage. Please review.

Project coverage is 82.60%. Comparing base (685baa9) to head (9935525).
Report is 80 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #11711      +/-   ##
==========================================
- Coverage   82.63%   82.60%   -0.03%     
==========================================
  Files         919      921       +2     
  Lines      248925   249051     +126     
==========================================
+ Hits       205703   205740      +37     
- Misses      43222    43311      +89     
Flag Coverage Δ
fuzzcorpus 60.84% <7.97%> (-0.05%) ⬇️
livemode 18.71% <23.31%> (-0.01%) ⬇️
pcap 44.07% <23.92%> (-0.07%) ⬇️
suricata-verify 61.81% <23.31%> (-0.07%) ⬇️
unittests 58.98% <7.97%> (-0.02%) ⬇️

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

Comment on lines +59 to +62
if (TmModuleLibHandlePacket(tv, device, packet, datalink, pkthdr.ts, pkthdr.len, 0, 0) !=
0) {
pthread_exit(NULL);
}
Copy link
Member Author

@jasonish jasonish Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm now thinking that TmModuleLibHandlePacket and the call to it should be changed to something like:

  • Some helper function to get a packet and perhaps some initial setup. But allow the user to to do some setup as well, like a "release" function.
  • User then calls a TmThreadsSlotProcessPkt or some wrapper around it.
    This removes one function from source-lib.c making it more functional, as well as allows post-inspection of the packet (which would make sense in workers mode, but not autofp)

@amirabell Any thoughts here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes not a bad idea.
Will there be an equivalent TmThreadFastProcessPkt to TmThreadSlowProcessPkt? And what would the difference be?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, typo.. Meant TmThreadsSlotProcessPkt.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 22392

@jasonish
Copy link
Member Author

jasonish commented Oct 9, 2024

Replaced by #11921.

@jasonish jasonish closed this Oct 9, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants