| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backoff code assumed that yang operations always completed quickly.
It checked for > 100 YANG modeled commands happening in under 1 second
to enable batching. If 100 yang modeled commands always take longer than
1 second batching is never enabled. This is the exact opposite of what
we want to happen since batching speeds the operations up.
Here are the results for libyang2 code without and with batching.
| action | 1K rts | 2K rts | 1K rts | 2K rts | 20k rts |
| | nobatch | nobatch | batch | batch | batch |
| Add IPv4 | .881 | 1.28 | .703 | 1.04 | 8.16 |
| Add Same IPv4 | 28.7 | 113 | .590 | .860 | 6.09 |
| Rem 1/2 IPv4 | .376 | .442 | .379 | .435 | 1.44 |
| Add Same IPv4 | 28.7 | 113 | .576 | .841 | 6.02 |
| Rem All IPv4 | 17.4 | 71.8 | .559 | .813 | 5.57 |
(IPv6 numbers are basically the same as iPv4, a couple percent slower)
Clearly we need this. Please note the growth (1K to 2K) w/o batching is
non-linear and 100 times slower than batched.
Notes on code: The use of the new `nb_cli_apply_changes_clear_pending`
is to commit any pending changes (including the current one). This is
done when the code would not correctly handle a single diff that
included the current changes with possible following changes. For
example, a "no" command followed by a new value to replace it would be
merged into a change, and the code would not deal well with that. A good
example of this is BGP neighbor peer-group changing. The other use is
after entering a router level (e.g., "router bgp") where the follow-on
command handlers expect that router object to now exists. The code
eventually needs to be cleaned up to not fail in these cases, but that
is for future NB cleanup.
Signed-off-by: Christian Hopps <chopps@labn.net>
|
| |
|
|
|
|
|
| |
mallinfo() is deprecated as of glibc 2.33 and emits a warning if used.
Support mallinfo2() if available.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
|
| |
|
|
|
|
|
|
|
| |
There exists a world where some people have put `end` in their
configuration. Then vtysh will command search for it and find
it and then bad things happen.
Ticket: CM-32665
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
| |
|
|
|
|
|
|
| |
start_config and end_config are already used as function names in DEFUN,
so the current naming is a little bit confusing. Let's use different
names for arguments.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
| |
|
|
| |
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
| |
|
|
|
|
|
| |
When reading a file in for configuration, send start and end indicators
to interested parties.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include memory types that were ever allocated when doing
a `show memory`.
Before, we were only including memory that existed currently
in the system, so we lost memory that was alloc'd/dealloc'd.
With this patch, we check max number rather than current number.
Ex) dataplane context objects
Old:
==============================================================================
Type : Current# Size Total Max# MaxBytes
--- qmem zebra ---
Type : Current# Size Total Max# MaxBytes
Zebra Interface Information : 48 360 17280 48 17280
Router Advertisement Prefix : 3 48 168 3 168
Route Entry : 128 80 11264 128 11264
RIB destination : 64 88 5632 64 5632
Zebra DPlane Provider : 1 232 232 1 232
Nexthop Group Entry : 78 80 6928 114 10032
Nexthop Group Connected : 78 40 3168 114 4560
Zebra Name Space : 13 variable 1000 13 1000
RIB table info : 12 16 288 12 288
ZEBRA VRF : 3 4744 14232 3 14232
New:
==============================================================================
Type : Current# Size Total Max# MaxBytes
--- qmem zebra ---
Type : Current# Size Total Max# MaxBytes
Zebra Interface Information : 48 360 17280 48 17280
Router Advertisement Prefix : 3 48 168 3 168
Route Entry : 128 80 11264 128 11264
RIB destination : 64 88 5632 64 5632
Zebra DPlane Ctx : 0 2424 0 87 210888
Zebra DPlane Provider : 1 232 232 1 232
Nexthop Group Entry : 78 80 6928 114 10032
Nexthop Group Connected : 78 40 3168 114 4560
Zebra Name Space : 13 variable 1000 13 1000
RIB table info : 12 16 288 12 288
ZEBRA VRF : 3 4744 14232 3 14232
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
|
| |
|
|
|
|
|
| |
Since we've been writing out "frr version" and "frr defaults" for about
a year and a half now, we can now actually use them to manage defaults.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
|
And memory_init() to lib_cmd_init().
Signed-off-by: David Lamparter <equinox@diac24.net>
|
