Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add new neteventebpfext eBPF extension for processing network events. #28

Merged
merged 73 commits into from
Jun 11, 2024

Conversation

gtrevi
Copy link
Contributor

@gtrevi gtrevi commented Apr 27, 2024

Description

This PR:

  • Adds a new neteventebpfext eBPF extension for capturing network events.
  • Adds a new netevent_sim kernel driver, which simulates an event provider for testing purposes.
  • Adds an new netevent_monitor eBPF program that will be invoked by the neteventebpfext extension upon receiving "special" events (actual or simulator), which will store the events in a ring-buffer map.
  • Adds e2e tests in generating events from netevent_sim kernel driver, flowing from the neteventebpfext eBPF extension, into the netevent_monitor eBPF program, into the ring-buffer map and ultimately into a UM app (i.e. the unit test) being called back upon every event insertion.
  • Removes duplicate store_helper library files, already implemented in EbpfApi.dll.

Testing

Local, CICD.

Documentation

  • README.md
  • docs\neteventebpfext.md

Installation

n.a.

@gtrevi gtrevi changed the title Add new pktmonebpfext eBPF extension for processing Packet Monitor (pktmon) events. [DRAFT] Add new pktmonebpfext eBPF extension for processing Packet Monitor (pktmon) events. Apr 27, 2024
@gtrevi gtrevi changed the title [DRAFT] Add new pktmonebpfext eBPF extension for processing Packet Monitor (pktmon) events. [DRAFT NOT FOR REVIEW] Add new pktmonebpfext eBPF extension for processing Packet Monitor (pktmon) events. May 10, 2024
@dv-msft
Copy link
Contributor

dv-msft commented Jun 5, 2024

As a general comment, this PR contains significant code re-org. While this re-org is certainly worthwhile, it seems orthogonal to the actual extension code payload. 'As-is', reverting this PR (for any reason) will cause all that re-org to be reverted as well.

Is it possible to separate out the code re-org into a separate PR?

@gtrevi
Copy link
Contributor Author

gtrevi commented Jun 5, 2024

As a general comment, this PR contains significant code re-org. While this re-org is certainly worthwhile, it seems orthogonal to the actual extension code payload. 'As-is', reverting this PR (for any reason) will cause all that re-org to be reverted as well.

Is it possible to separate out the code re-org into a separate PR?

This repo was designed to offer a library of boilerplate code to accelerate the development of eBPF extensions, and host multiple other extensions that build on top of that.
Upon its creation, it was self-checked in with the ntosebpfext placed in the root, therefore missing to offer a structured design to host other future extensions, in a well understandable, ordered way.

Happens that upon adding the second extension, the structure and other minor refactoring had to be adapted to have the repo comply to its design intent in the first place, which was missing.

@gtrevi gtrevi merged commit 3a813bf into microsoft:main Jun 11, 2024
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants