Paul - I think we are in a somewhat broad agreement about the path going forward and the plan for a time frame. My requirement that I haven't explicitly stated is that I want the internal code path surrounding nexthop's to be cleaned up such that I shouldn't need to look in 3 different places for the nexthop information, based upon the afi/safi I am currently working with. It was a bit of a surprise when I went looking for it this weekend, doing some other work, and I had to stop and examine the code closely to understand where the nexthop information is stored based upon the address family I am looking at.
donald On Tue, Feb 2, 2016 at 8:24 AM, Paul Jakma <[email protected]> wrote: > 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
