zebra: Refactor kernel_rtm to be a bit smarter about how it handles options

[mirror_frr.git] / bgpd / IMPLEMENTATION.txt

diff --git a/bgpd/IMPLEMENTATION.txt b/bgpd/IMPLEMENTATION.txt
index d0b270b4564549b03d4143b161455ea18563bd70..5822dbba82f575b31ecc0f3dd00ce75d881c33f1 100644 (file)
--- a/bgpd/IMPLEMENTATION.txt
+++ b/bgpd/IMPLEMENTATION.txt
@@ -1,4 +1,4 @@
-$Id: IMPLEMENTATION.txt,v 1.1 2005/02/10 16:38:09 gdt Exp $
+$Id: IMPLEMENTATION.txt,v 1.2 2005/02/15 17:10:03 gdt Exp $
 
 This file contains notes about the internals of the BGP
 implementation.  The initial impetus is understanding the memory usage
@@ -104,8 +104,8 @@ bgp_route.[hc]:
       looking for data in hash table, and putting there if missing, refcnt
       using pointer to existing data
     many validity checks
-    get new struct bgp_info (10 words/40 bytes)
-    call bgp_info_add with rn and bgp_info
+    get new struct bgp_path_info
+    call bgp_path_info_add with rn and bgp_path_info
     call bgp_process
 
 bgp_routemap.c
@@ -131,7 +131,6 @@ bgpd.h
   struct peer_group
   struct bgp_notify: (in-core representation of wire format?)
   struct bgp_nexthop: (v4 and v6 addresses, *ifp)
-  struct bgp_rd: router distinguisher: 8 octects
   struct bgp_filter: distribute, prefix, aslist, route_maps
   struct peer: neighbor structure (very rich/complex)
   struct bgp_nlri: reference to wire format
@@ -150,10 +149,18 @@ bgpd.c
 Question: How much memory does quagga's bgpd use as a function of
 state received from peers?
 
-It seems that a struct bgp_info is kept for each prefix, and this has
-its own struct attr.  aspath, etc. are 'interned' and shared.
-So, it seems that 144 bytes are used per received prefix, plus storage
-for all unique aspaths received.
+It seems that a struct bgp_path_info is kept for each prefix.  The "struct
+attr *" is interned, and variables within that are interned.  So, 40
+bytes are kept per received prefix, plus interned shared values.  This
+could be 36 if 'int suppress' where changed to a u_char and moved to
+be with the other u_chars.  Without MPLS, this could be 32 bytes.
+Note that 8 bytes of this is linked list overhead, meaning that 24
+bytes are the raw per-prefix storage requirements.
+
+Also, a struct bgp_damp_info is apparently maintained per route; this
+is fairly large (about 44 bytes).
+
+[TODO: the role of struct bgp_node.]
 
 * TIME COMPLEXITY