public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <ordex@autistici.org>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [RFC 08/10] batman-adv: adapt the gateway feature to use the new API functions
Date: Thu, 30 May 2013 13:29:20 +0200	[thread overview]
Message-ID: <20130530112920.GB2475@ritirata.org> (raw)
In-Reply-To: <20130529144817.GS3333@ritirata.org>

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

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,



-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-05-30 11:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 22:20 [B.A.T.M.A.N.] [RFC 00/10] Improving the routing protocol abstraction Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 01/10] batman-adv: make struct batadv_neigh_node algorithm agnostic Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 02/10] batman-adv: make struct batadv_orig_node " Antonio Quartulli
2013-05-29 14:09   ` Simon Wunderlich
2013-05-29 14:12     ` Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 03/10] batman-adv: add bat_orig_print function API Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 04/10] batman-adv: add bat_get_metric API function Antonio Quartulli
2013-05-29 14:17   ` Simon Wunderlich
2013-05-29 14:29     ` Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 04/10] batman-adv: add bat_metric_get " Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 05/10] batman-adv: add bat_metric_is_similar " Antonio Quartulli
2013-05-29 14:16   ` Simon Wunderlich
2013-05-29 14:28     ` Antonio Quartulli
2013-05-29 14:55       ` Simon Wunderlich
2013-05-29 14:57         ` Antonio Quartulli
2013-06-26  8:59           ` Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 06/10] batman-adv: add bat_metric_compare " Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 07/10] batman-adv: adapt bonding to use the new API functions Antonio Quartulli
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 08/10] batman-adv: adapt the gateway feature " Antonio Quartulli
2013-05-29 14:32   ` Simon Wunderlich
2013-05-29 14:48     ` Antonio Quartulli
2013-05-30 11:29       ` Antonio Quartulli [this message]
2013-05-28 22:20 ` [B.A.T.M.A.N.] [RFC 09/10] batman-adv: adapt the neighbor purging routine " Antonio Quartulli
2013-05-28 22:23 ` [B.A.T.M.A.N.] [RFC 00/10] Improving the routing protocol abstraction Antonio Quartulli
2013-05-28 23:19 ` [B.A.T.M.A.N.] [RFC 10/10] batman-adv: provide orig_node routing API Antonio Quartulli
2013-05-29  6:20 ` [B.A.T.M.A.N.] [RFC 00/10] Improving the routing protocol abstraction Martin Hundebøll
2013-05-29  7:08   ` Antonio Quartulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130530112920.GB2475@ritirata.org \
    --to=ordex@autistici.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox