[RFC] batman-adv: ELP - use wifi tx bitrate as fallback throughput

[RFC] batman-adv: ELP - use wifi tx bitrate as fallback throughput

[Marek Lindner]

From: René Treffer <treffer@measite.de>

Some wifi drivers (e.g. ath10k) provide per-station rx/tx values but no
estimated throughput. Setting a better estimate than the default 1 MBit
makes these devices work well with B.A.T.M.A.N. V.

Signed-off-by: René Treffer <treffer@measite.de>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
 net/batman-adv/bat_v_elp.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c
index 2614a9ca..1e852d4b 100644
--- a/net/batman-adv/bat_v_elp.c
+++ b/net/batman-adv/bat_v_elp.c
@@ -107,10 +107,15 @@ static u32 batadv_v_elp_get_throughput(struct batadv_hardif_neigh_node *neigh)
 		}
 		if (ret)
 			goto default_throughput;
-		if (!(sinfo.filled & BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT)))
-			goto default_throughput;
 
-		return sinfo.expected_throughput / 100;
+		if (sinfo.filled & BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT))
+			return sinfo.expected_throughput / 100;
+
+		/* try to estimate en expected throughput based on reported tx rates */
+		if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE))
+			return cfg80211_calculate_bitrate(&sinfo.txrate) / 3;
+
+		goto default_throughput;
 	}
 
 	/* if not a wifi interface, check if this device provides data via
-- 
2.20.1

Re: [RFC] batman-adv: ELP - use wifi tx bitrate as fallback throughput

[Linus Lüssing]

On Sun, Aug 11, 2019 at 09:07:05PM +0800, Marek Lindner wrote:
> From: René Treffer <treffer@measite.de>
> 
> Some wifi drivers (e.g. ath10k) provide per-station rx/tx values but no
> estimated throughput. Setting a better estimate than the default 1 MBit
> makes these devices work well with B.A.T.M.A.N. V.
> 
> Signed-off-by: René Treffer <treffer@measite.de>
> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
> ---

In general, I like this approach. It's simple and roughly matches
our conservative assumptions we used for broadcast packets, too.
That is 3x transmissions per packet.

Lukonin's approach sounds more accurate in theory. But should
probably have a bit more testing and reviewable test results due to
it's slightly higher complexity.

Regards, Linus