[quagga-dev 14654] Re: bgp nexthop information
paul at jakma.org
Tue Feb 2 13:24:15 GMT 2016
On Tue, 2 Feb 2016, Donald Sharp wrote:
>> I don't know why VPNv4 doesn't re-use the same in_addr as for v6. Looks
>> like maybe it could?
> I believe so too.
Easy one then :)
> @@ -115,7 +109,7 @@ struct attr
> u_int32_t flag;
> /* Apart from in6_addr, the remaining static attributes */
> - struct in_addr nexthop;
> + union g_addr nexthop;
> In my refactored code I'm testing right now, the V4 data structure
> grows from 4 bytes to 16 per route, so 12 bytes increase.
I undercounted my other figures. Should be 33 / 49 bytes for Quagga
32/64 I think. So moving v6 into (struct attr) is a 36 or 24% increase.
> While If you have a V6 or VPNV4 address we loose 12 bytes per route
I'm not so concerned about savings in attr_extra. They ought to
relatively insignificant relative to increases in the main (struct attr)
for anyone with a full v4 table.
> mp_nexthop_local_in is never used. That can just be removed from the data
> structure, imo.
> I'm not sure I care about what other people are saying, if they are
> just complaining.
The struct attrs are a significant user of memory. So, anything there
that is used less is ungood.
> Let's make the code structure right and fix
> performance issues and this becomes a non-talking point from my
> perspective. There is something to be said about cleanliness of code
> as well and I think we can all agree that how nexthop's are stored is
> a bit non-intuitive.
If we're concerned about this and want to move stuff back into (struct
attr), then I think should become much more dynamic according to what is
actually set. (Cause, just 1 thing being set from the attr_extra drags
that whole thing in and that's worse again).
It's just, I'm not sure the time is right.
Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
Van Roy's Law:
An unbreakable toy is useful for breaking other toys.
More information about the Quagga-dev