[quagga-dev 14654] Re: bgp nexthop information

Paul Jakma 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.

\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	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
Van Roy's Law:
 	An unbreakable toy is useful for breaking other toys.




More information about the Quagga-dev mailing list