[v2,04/26] batman-adv: iv_ogm, divide and round for ring buffer avg

Message ID 1419594103-10928-5-git-send-email-mpa@pengutronix.de (mailing list archive)
State Rejected, archived
Headers

Commit Message

Markus Pargmann Dec. 26, 2014, 11:41 a.m. UTC
  Instead of the normal division which looses precision, use a division
with rounding.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
 bat_iv_ogm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

Marek Lindner Jan. 11, 2015, 12:32 p.m. UTC | #1
On Friday 26 December 2014 12:41:21 Markus Pargmann wrote:
> Instead of the normal division which looses precision, use a division
> with rounding.
> 
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
>  bat_iv_ogm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bat_iv_ogm.c b/bat_iv_ogm.c
> index 1458ecfa66b8..10eada270015 100644
> --- a/bat_iv_ogm.c
> +++ b/bat_iv_ogm.c
> @@ -82,7 +82,7 @@ static uint8_t batadv_ring_buffer_avg(const uint8_t
> lq_recv[]) if (count == 0)
>                 return 0;
>  
> -       return (uint8_t)(sum / count);
> +       return (uint8_t)DIV_ROUND_CLOSEST(sum, count);
>  }

Is DIV_ROUND_CLOSEST available in 2.6.29 ? I could not find a conclusive hint 
whether or not we need compat code for the out-of-tree module ?

Cheers,
Marek
  
Sven Eckelmann Jan. 11, 2015, 12:42 p.m. UTC | #2
On Sunday 11 January 2015 20:32:49 Marek Lindner wrote:
> Is DIV_ROUND_CLOSEST available in 2.6.29 ? I could not find a conclusive
> hint whether or not we need compat code for the out-of-tree module ?

It was introduced in 2.6.29 in v2.6.28-6240-g9fe0608. So you would only need 
compat code in marek/compat_old_kernel

Kind regards,
	Sven
  
Simon Wunderlich Jan. 12, 2015, 3:56 p.m. UTC | #3
On Friday 26 December 2014 12:41:21 Markus Pargmann wrote:
> Instead of the normal division which looses precision, use a division
> with rounding.
> 
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>

(sorry for the duplicate, sent the reply for the first patch version, so I'm 
replying another time on v2 ...)

Why do we need to have more precise rounding here? In doubt, we should rather 
always round down to avoid any spurious routing loops - the loop free property 
depends on monotonicity after all, and therefore its better to always round 
down.

I'm not convinced that this change is safe in that regard, if you think it is 
please explain further.

> ---
>  bat_iv_ogm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bat_iv_ogm.c b/bat_iv_ogm.c
> index 1458ecfa66b8..10eada270015 100644
> --- a/bat_iv_ogm.c
> +++ b/bat_iv_ogm.c
> @@ -82,7 +82,7 @@ static uint8_t batadv_ring_buffer_avg(const uint8_t
> lq_recv[]) if (count == 0)
>  		return 0;
> 
> -	return (uint8_t)(sum / count);
> +	return (uint8_t)DIV_ROUND_CLOSEST(sum, count);
>  }
> 
>  /**
  

Patch

diff --git a/bat_iv_ogm.c b/bat_iv_ogm.c
index 1458ecfa66b8..10eada270015 100644
--- a/bat_iv_ogm.c
+++ b/bat_iv_ogm.c
@@ -82,7 +82,7 @@  static uint8_t batadv_ring_buffer_avg(const uint8_t lq_recv[])
 	if (count == 0)
 		return 0;
 
-	return (uint8_t)(sum / count);
+	return (uint8_t)DIV_ROUND_CLOSEST(sum, count);
 }
 
 /**