proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-29 21:01:42 +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 Process Architecture
==================== ====================
FRR inherited its overall design architecture from Quagga. The chosen model for FRR is a suite of daemons that serve different functions. This document
Quagga is that of a suite of independent daemons that do IPC via Unix domain describes internal architecture of daemons, focusing their general design
sockets. Within each daemon, the architecture follows the event-driven model. patterns, and especially how threads are used in the daemons that use them.
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 Overview
are approaching the saturation point for a single thread per daemon. In light --------
of this, there are ongoing efforts to introduce multithreading to various The fundamental pattern used in FRR daemons is an `event loop
components of FRR. This document aims to describe the current design choices <https://en.wikipedia.org/wiki/Event_loop>`_. Some daemons use `kernel threads
and overall model for integrating the event-driven and multithreaded <https://en.wikipedia.org/wiki/Thread_(computing)#Kernel_threads>`_. In these
architectures into a cohesive whole. 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 Terminology
----------- -----------
Because this document describes the architecture for true kernel threads as Because this document describes the architecture for kernel threads as well as
well as the event system, a digression on terminology is in order here. 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 threading. Because of this design choice, the names for various datastructures
within the event system are variations on the term "thread". The primary within the event system are variations on the term "thread". The primary
context datastructure in this system is called a "threadmaster". What would datastructure that holds the state of an event loop in this system is called a
today be called an 'event' or 'task' in systems such as libevent are called "threadmaster". Events scheduled on the event loop - what would today be called
"threads" and the datastructure for them is ``struct thread``. To add to the an 'event' or 'task' in systems such as libevent - are called "threads" and the
confusion, these "threads" have various types, one of which is "event". To datastructure for them is ``struct thread``. To add to the confusion, these
hopefully avoid some of this confusion, this document refers to these "threads" "threads" have various types, one of which is "event". To hopefully avoid some
as a 'task' except where the datastructures are explicitly named. When they are of this confusion, this document refers to these "threads" as a 'task' except
explicitly named, they will be formatted ``like this`` to differentiate from where the datastructures are explicitly named. When they are explicitly named,
the conceptual names. When speaking of kernel threads, the term used will be they will be formatted ``like this`` to differentiate from the conceptual
"pthread" since FRR's kernel threading implementation is POSIX threads. 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` .. This should be broken into its document under :ref:`libfrr`
.. _event-architecture: .. _event-architecture: