git: af4c6c1fd5 - main - Status/2023Q2/epoch-netgraph.adoc: Add report

From: Lorenzo Salvadore <>
Date: Sat, 22 Jul 2023 13:09:48 UTC
The branch main has been updated by salvadore:


commit af4c6c1fd57ff93e10cb979391be171119b5ab90
Author:     Zain Khan <>
AuthorDate: 2023-07-22 12:56:21 +0000
Commit:     Lorenzo Salvadore <>
CommitDate: 2023-07-22 13:09:02 +0000

    Status/2023Q2/epoch-netgraph.adoc: Add report
    Approved by:    dbaio (mentor, implicit)
    Pull Request:
 .../report-2023-04-2023-06/epoch-netgraph.adoc     | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/website/content/en/status/report-2023-04-2023-06/epoch-netgraph.adoc b/website/content/en/status/report-2023-04-2023-06/epoch-netgraph.adoc
new file mode 100644
index 0000000000..786d2bc164
--- /dev/null
+++ b/website/content/en/status/report-2023-04-2023-06/epoch-netgraph.adoc
@@ -0,0 +1,32 @@
+=== Making Netgraph Lock-Free
+Links: +
+link:[Wiki Page] URL: link:[] +
+link:[Repo] URL: link:[]
+Contact: Zain Khan <>
+Netgraph helps us implement custom or complex networking functions by letting us arrange kernel objects called nodes in a graph connected using hooks.
+Nodes may perform a well-defined set of actions on incoming packets, and may send the output to another connected node.
+To 'send' a packet to a neighbour can also be seen as calling a function on that neighbouring node.
+Now in a pre-SMP world, a thread (or *the* thread) would always see nodes as idle (not busy), so that their functions can immediately be called.
+Concurrency introduced the possibility of a busy node.
+Moreover, a journey of a packet also needs to take heed of changes in the structure of the graph, for example: the addressed node's path may not remain intact due to no-longer-existing hooks or nodes in between, which may lead to cases such as referring to an object that has been freed.
+To counter such disasters, the existing source code uses a topology read-write mutex which protects data flow from restructuring events (and restructuring events from other restructuring events).
+We want to regain the same smooth flow for data which existed when concurrent cpus were not a thing.
+That is, data should simply never wait every time there is a restructuring event.
+At the same time we also obviously do not want to give the kernel reasons to panic.
+FreeBSD has its own set of concurrency-safe data structures and mechanisms.
+One of these mechanisms is Epoch.
+Epoch-based reclamation involves waiting for existing read-side critical sections to finish before the data structures need to be modified or reclaimed.
+Because the base system is being modified, this is also going to affect the design choices made before, such as queuing on messages, reference counting.
+This project involves a lot of testing.
+For now, some topology protection locks have been removed, and only simple graphs have been tested (with FreeBSD running on a VM).
+The real tests should be run on hardware with at least 4 CPU cores, I will do that when I get my hands on one.
+Sponsor: The Google Summer of Code '23 program