-$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
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
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
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