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.
\o/
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. regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: Van Roy's Law: An unbreakable toy is useful for breaking other toys. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
