proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-28 14:21:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: update & clarify language in process arch doc

Browse Source 
There was a historical blurb at the top of the process architecture
document that in several instances caused some confusion regarding
whether or not FRR supports multithreading. Remove this paragraph and
replace it with a summary of the page contents.

Signed-off-by: Quentin Young <qlyoung@nvidia.com>
This commit is contained in:
Quentin Young 2021-11-12 14:45:36 -05:00
parent d9a03ad330
commit ad2af6ed1c
1 changed files with 26 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/developer/process-architecture.rst
View File

@ -3,34 +3,38 @@
Process Architecture
====================
FRR inherited its overall design architecture from Quagga. The chosen model for
Quagga is that of a suite of independent daemons that do IPC via Unix domain
sockets. Within each daemon, the architecture follows the event-driven model.
FRR has inherited this model as well. As FRR is deployed at larger scales and
gains ever more features, each adding to the overall processing workload, we
are approaching the saturation point for a single thread per daemon. In light
of this, there are ongoing efforts to introduce multithreading to various
components of FRR. This document aims to describe the current design choices
and overall model for integrating the event-driven and multithreaded
architectures into a cohesive whole.
FRR is a suite of daemons that serve different functions. This document
describes internal architecture of daemons, focusing their general design
patterns, and especially how threads are used in the daemons that use them.
Overview
--------
The fundamental pattern used in FRR daemons is an `event loop
<https://en.wikipedia.org/wiki/Event_loop>`_. Some daemons use `kernel threads
<https://en.wikipedia.org/wiki/Thread_(computing)#Kernel_threads>`_. In these
daemons, each kernel thread runs its own event loop. The event loop
implementation is constructed to be thread safe and to allow threads other than
its owning thread to schedule events on it. The rest of this document describes
these two designs in detail.
Terminology
-----------
Because this document describes the architecture for true kernel threads as
well as the event system, a digression on terminology is in order here.
Because this document describes the architecture for kernel threads as well as
the event system, a digression on terminology is in order here.
Historically Quagga's event system was viewed as an implementation of userspace
Historically Quagga's loop system was viewed as an implementation of userspace
threading. Because of this design choice, the names for various datastructures
within the event system are variations on the term "thread". The primary
context datastructure in this system is called a "threadmaster". What would
today be called an 'event' or 'task' in systems such as libevent are called
"threads" and the datastructure for them is ``struct thread``. To add to the
confusion, these "threads" have various types, one of which is "event". To
hopefully avoid some of this confusion, this document refers to these "threads"
as a 'task' except where the datastructures are explicitly named. When they are
explicitly named, they will be formatted ``like this`` to differentiate from
the conceptual names. When speaking of kernel threads, the term used will be
"pthread" since FRR's kernel threading implementation is POSIX threads.
datastructure that holds the state of an event loop in this system is called a
"threadmaster". Events scheduled on the event loop - what would today be called
an 'event' or 'task' in systems such as libevent - are called "threads" and the
datastructure for them is ``struct thread``. To add to the confusion, these
"threads" have various types, one of which is "event". To hopefully avoid some
of this confusion, this document refers to these "threads" as a 'task' except
where the datastructures are explicitly named. When they are explicitly named,
they will be formatted ``like this`` to differentiate from the conceptual
names. When speaking of kernel threads, the term used will be "pthread" since
FRR's kernel threading implementation uses the POSIX threads API.
.. This should be broken into its document under :ref:`libfrr`
.. _event-architecture: