[Olsr-dev] olsrd-0.5.3-rc1 feedback

[Sven-Ola Tuecke]

Hello again,

changing that olsrd-hops-to-kernel-metrics in the routing code works well 
for me. The linux kernel automatically completes with the correct metric 
value if this value is ommited while removing a route. Checked with "ip 
monitor". Yes I understand the "doing fake metrics saves a lot of 
route-add/route-del" thing as well. If we add a config parameter, it may 
make sense to have it three-fold, e.g

0 = use dummy metric=1 for hostroutes, metric=2 for via routes
1 = use real metric but do not constantly update kernel routes (== my patch)
2 = use real metric and update kernel routes to reflect olsrd calculations

// Sven-Ola

----- Original Message ----- 
From: "Hannes Gredler" <(spam-protected)>
To: <(spam-protected)>
Sent: Thursday, October 04, 2007 12:14 PM
Subject: Re: [Olsr-dev] olsrd-0.5.3-rc1 feedback


>
>
> Sven-Ola Tuecke wrote:
>> * As discussed, I re-add the metric value on the routes.
>>   From my perspective it's simply convenient, because I can
>>   look on the routing output and estimate at a glance if a
>>   particular route is long or short. It's not really important,
>>   if that's only an estimation IMO. Reason to re-add metric with
>>   131-olsrd-policy-metric.patch for the Freifunk olsrd.
>
> hi sven-ola,
>
> hmm sorry ... that is not the right place to get the metric back in.
>
> what you need to do IMO is to extend the rt_nexthop datastructure
> with a metric field and then extend olsr_nh_change() for
> proper change detection.
>
> what will happen in 131-olsrd-policy-metric.patch is that only the
> first route addition will have the correct metric setting -
> even worse - after a bit of route change in the network you will
> not be able to proper delete old routes cause the metric
> has been lost ...
>
> since you seem to dislike the flat metric scheme and i still think
> is useful, can we bargain such that we can hide the metric stuff
> under #ifdef OLSR_FLAT_METRICS ... then you can enable that
> for freifunk ...
>
> /hannes
>