Adding upstream version 10.1.upstream/10.1upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 20 insertions, 30 deletions

diff --git a/doc/developer/northbound/operational-data-rpcs-and-notifications.rst b/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
index 5cb70ca..07f92c2 100644
--- a/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
+++ b/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
@@ -10,10 +10,10 @@ Operational data
 ~~~~~~~~~~~~~~~~
 
 Writing API-agnostic code for YANG-modeled operational data is
-challenging. ConfD and Sysrepo, for instance, have completely different
-APIs to fetch operational data. So how can we write API-agnostic
-callbacks that can be used by both the ConfD and Sysrepo plugins, and
-any other northbound client that might be written in the future?
+challenging. Sysrepo, for instance, has completely different API to
+fetch operational data. So how can we write API-agnostic callbacks
+that can be used by both the Sysrepo plugin, and any other northbound
+client that might be written in the future?
 
 As an additional requirement, the callbacks must be designed in a way
 that makes in-place XPath filtering possible. As an example, a
@@ -94,27 +94,18 @@ in the northbound architecture:
             */
            void *(*lookup_entry)(struct yang_list_keys *keys);
 
-These callbacks were designed to provide maximum flexibility, and borrow
-a lot of ideas from the ConfD API. Each callback does one and only one
-task, they are indivisible primitives that can be combined in several
-different ways to iterate over operational data. The extra flexibility
-certainly has a performance cost, but it’s the price to pay if we want
-to expose FRR operational data using several different management
-interfaces (e.g. NETCONF via either ConfD or Sysrepo+Netopeer2). In the
+These callbacks were designed to provide maximum flexibility. Each
+callback does one and only one task, they are indivisible primitives
+that can be combined in several different ways to iterate over operational
+data. The extra flexibility certainly has a performance cost, but it’s the
+price to pay if we want to expose FRR operational data using several
+different management interfaces (e.g. Sysrepo+Netopeer2). In the
 future it might be possible to introduce optional callbacks that do
 things like returning multiple objects at once. They would provide
 enhanced performance when iterating over large lists, but their use
 would be limited by the northbound plugins that can be integrated with
 them.
 
-   NOTE: using the northbound callbacks as a base, the ConfD plugin can
-   provide up to 100 objects between each round trip between FRR and the
-   *confd* daemon. Preliminary tests showed FRR taking ~7 seconds
-   (asynchronously, without blocking the main pthread) to return a RIP
-   table containing 100k routes to a NETCONF client connected to *confd*
-   (JSON was used as the encoding format). Work needs to be done to find
-   the bottlenecks and optimize this operation.
-
 The [[Plugins - Writing Your Own]] page explains how the northbound
 plugins can fetch operational data using the aforementioned northbound
 callbacks, and how in-place XPath filtering can be implemented.
@@ -351,10 +342,10 @@ are being iterated over. If that is not done, the list entry returned by
 this callback can become a dangling pointer when used in another
 callback.
 
-Currently the ConfD and Sysrepo plugins run only in the main pthread.
-The plan in the short-term is to introduce a separate pthread only for
-handling operational data, and use the main pthread only for handling
-configuration changes, RPCs and notifications.
+Currently the Sysrepo plugin runs only in the main pthread. The plan in the
+short-term is to introduce a separate pthread only for handling operational
+data, and use the main pthread only for handling configuration changes,
+RPCs and notifications.
 
 RPCs and Actions
 ~~~~~~~~~~~~~~~~
@@ -396,8 +387,8 @@ some EXEC-level commands using YANG so that their functionality is
 exposed to other management interfaces other than the CLI. As an
 example, if the ``clear bgp`` command is modeled using a YANG RPC, and a
 corresponding ``rpc`` callback is written, then it should be possible to
-clear BGP neighbors using NETCONF and RESTCONF with that RPC (the ConfD
-and Sysrepo plugins have full support for YANG RPCs and actions).
+clear BGP neighbors using NETCONF and RESTCONF with that RPC (the Sysrepo
+plugin has full support for YANG RPCs and actions).
 
 Here’s an example of a very simple RPC modeled using YANG:
 
@@ -568,8 +559,7 @@ Now sending the *authentication-failure* YANG notification should be as
 simple as calling the above function and provide the appropriate
 interface name. The notification will be processed by all northbound
 plugins that subscribed a callback to the ``nb_notification_send`` hook.
-The ConfD and Sysrepo plugins, for instance, use this hook to relay the
-notifications to the *confd*/*sysrepod* daemons, which can generate
-NETCONF notifications to subscribed clients. When no northbound plugin
-is loaded, ``nb_notification_send()`` doesn’t do anything and the
-notifications are ignored.
+The Sysrepo plugin, for instance, uses this hook to relay the notifications
+to the *sysrepod* daemon, which can generate NETCONF notifications to subscribed
+clients. When no northbound plugin is loaded, ``nb_notification_send()`` doesn’t
+do anything and the notifications are ignored.