On Wed, May 29, 2013 at 04:48:17PM +0200, Antonio Quartulli wrote:
On Wed, May 29, 2013 at 04:32:21PM +0200, Simon Wunderlich wrote:
On Wed, May 29, 2013 at 12:20:48AM +0200, Antonio Quartulli wrote:
[...]
gw_divisor = BATADV_TQ_LOCAL_WINDOW_SIZE * BATADV_TQ_LOCAL_WINDOW_SIZE; gw_divisor *= 64; @@ -137,18 +137,19 @@ batadv_gw_get_best_gw_node(struct batadv_priv *bat_priv) if (!atomic_inc_not_zero(&gw_node->refcount)) goto next;
tq_avg = router->bat_iv.tq_avg;
metric = bao->bat_metric_get(router);switch (atomic_read(&bat_priv->gw_sel_class)) { case 1: /* fast connection */
tmp_gw_factor = tq_avg * tq_avg;
tmp_gw_factor = metric * metric;Hmm, that is rather strange ... I think fiddling with the metric directly this way is weird when abstracting. For example: 1.) Assuming we don't know how the metric looks like, we can't just multiplicate them. A logarithmic scaled metric or even arbritrary metric would look different compared to the linear metrics as we use now. 2.) This might overflow because metric is u32 and tmp_gw_factor is too. It should work for batman IV where the metric is <256, but might not for BATMAN V.
I think this "bandwidth magic" should be abstracted as well somehow, if we want to keep on using it that way.
I totally agree. Thanks for your feedback, but I don't really know how I could abstract this behaviour. This is totally GW related, but hardcoded around the metric semantic. here we would need a routing API that should be implemented by the GW component....mhhh..suggestions? :D
After discussing with Marek on IRC, we agreed that it is probably better to leave this part of the code untouched.
It has to be rearranged when implementing the new GW logic discussed at WBMv6 and therefore does not really need to be made protocol agnostic now.
Cheers,