[PATCH v2] fq: fix fq_tin tx bytes overflow

[PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

Currently, we are using u32 for tx_bytes in fq_tin.
If the throughput stays more than 1.2Gbps, tx_bytes
statistics overflow in about 1 min.

In order to allow us to trace the tx_bytes statistics
for longer time in high throughput, change its type
from u32 to u64.

Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
---
 include/net/fq.h              | 2 +-
 net/mac80211/debugfs_netdev.c | 2 +-
 net/mac80211/debugfs_sta.c    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/fq.h b/include/net/fq.h
index ac944a6..70f8b12 100644
--- a/include/net/fq.h
+++ b/include/net/fq.h
@@ -53,7 +53,7 @@ struct fq_tin {
 	u32 overlimit;
 	u32 collisions;
 	u32 flows;
-	u32 tx_bytes;
+	u64 tx_bytes;
 	u32 tx_packets;
 };
 
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index cff0fb3..8d66f41 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -499,7 +499,7 @@ static ssize_t ieee80211_if_fmt_aqm(
 	len = scnprintf(buf,
 			buflen,
 			"ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets\n"
-			"%u %u %u %u %u %u %u %u %u %u\n",
+			"%u %u %u %u %u %u %u %u %llu %u\n",
 			txqi->txq.ac,
 			txqi->tin.backlog_bytes,
 			txqi->tin.backlog_packets,
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 3aa618d..e54a6d6 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -168,7 +168,7 @@ static ssize_t sta_aqm_read(struct file *file, char __user *userbuf,
 			continue;
 		txqi = to_txq_info(sta->sta.txq[i]);
 		p += scnprintf(p, bufsz+buf-p,
-			       "%d %d %u %u %u %u %u %u %u %u %u 0x%lx(%s%s%s)\n",
+			       "%d %d %u %u %u %u %u %u %u %llu %u 0x%lx(%s%s%s)\n",
 			       txqi->txq.tid,
 			       txqi->txq.ac,
 			       txqi->tin.backlog_bytes,
-- 
1.9.1

[PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

Currently, we are using u32 for tx_bytes in fq_tin.
If the throughput stays more than 1.2Gbps, tx_bytes
statistics overflow in about 1 min.

In order to allow us to trace the tx_bytes statistics
for longer time in high throughput, change its type
from u32 to u64.

Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
---
 include/net/fq.h              | 2 +-
 net/mac80211/debugfs_netdev.c | 2 +-
 net/mac80211/debugfs_sta.c    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/fq.h b/include/net/fq.h
index ac944a6..70f8b12 100644
--- a/include/net/fq.h
+++ b/include/net/fq.h
@@ -53,7 +53,7 @@ struct fq_tin {
 	u32 overlimit;
 	u32 collisions;
 	u32 flows;
-	u32 tx_bytes;
+	u64 tx_bytes;
 	u32 tx_packets;
 };
 
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index cff0fb3..8d66f41 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -499,7 +499,7 @@ static ssize_t ieee80211_if_fmt_aqm(
 	len = scnprintf(buf,
 			buflen,
 			"ac backlog-bytes backlog-packets new-flows drops marks overlimit collisions tx-bytes tx-packets\n"
-			"%u %u %u %u %u %u %u %u %u %u\n",
+			"%u %u %u %u %u %u %u %u %llu %u\n",
 			txqi->txq.ac,
 			txqi->tin.backlog_bytes,
 			txqi->tin.backlog_packets,
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 3aa618d..e54a6d6 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -168,7 +168,7 @@ static ssize_t sta_aqm_read(struct file *file, char __user *userbuf,
 			continue;
 		txqi = to_txq_info(sta->sta.txq[i]);
 		p += scnprintf(p, bufsz+buf-p,
-			       "%d %d %u %u %u %u %u %u %u %u %u 0x%lx(%s%s%s)\n",
+			       "%d %d %u %u %u %u %u %u %u %llu %u 0x%lx(%s%s%s)\n",
 			       txqi->txq.tid,
 			       txqi->txq.ac,
 			       txqi->tin.backlog_bytes,
-- 
1.9.1


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Johannes Berg]

On Wed, 2019-03-13 at 11:08 +0800, Yibo Zhao wrote:
> Currently, we are using u32 for tx_bytes in fq_tin.
> If the throughput stays more than 1.2Gbps, tx_bytes
> statistics overflow in about 1 min.
> 
> In order to allow us to trace the tx_bytes statistics
> for longer time in high throughput, change its type
> from u32 to u64.

Hmm. 64-bit values are kinda expensive on 32-bit architectures. How
badly do you need this? I mean ... worst case you just have to capture
every 30 seconds or so if you're doing really high throughput with HE or
something?

johannes

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Johannes Berg]

On Wed, 2019-03-13 at 11:08 +0800, Yibo Zhao wrote:
> Currently, we are using u32 for tx_bytes in fq_tin.
> If the throughput stays more than 1.2Gbps, tx_bytes
> statistics overflow in about 1 min.
> 
> In order to allow us to trace the tx_bytes statistics
> for longer time in high throughput, change its type
> from u32 to u64.

Hmm. 64-bit values are kinda expensive on 32-bit architectures. How
badly do you need this? I mean ... worst case you just have to capture
every 30 seconds or so if you're doing really high throughput with HE or
something?

johannes


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

On 2019-03-15 17:38, Johannes Berg wrote:
> On Wed, 2019-03-13 at 11:08 +0800, Yibo Zhao wrote:
>> Currently, we are using u32 for tx_bytes in fq_tin.
>> If the throughput stays more than 1.2Gbps, tx_bytes
>> statistics overflow in about 1 min.
>> 
>> In order to allow us to trace the tx_bytes statistics
>> for longer time in high throughput, change its type
>> from u32 to u64.
> 
> Hmm. 64-bit values are kinda expensive on 32-bit architectures. How
> badly do you need this? I mean ... worst case you just have to capture
> every 30 seconds or so if you're doing really high throughput with HE 
> or
> something?
> 
> johannes

Hi Johannes,

I understand your concern. Yes, I am using high end AP for throughput 
test. I'd say 1.2 Gbps is not the worst case since we can achieve max 
1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is 
the minimum requirement. And I think, with more and more high end 
products(even higher throughput) on the ways to the market, it is highly 
possible that 30s is not a safe time before overflow.

-- 
Yibo

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

On 2019-03-15 17:38, Johannes Berg wrote:
> On Wed, 2019-03-13 at 11:08 +0800, Yibo Zhao wrote:
>> Currently, we are using u32 for tx_bytes in fq_tin.
>> If the throughput stays more than 1.2Gbps, tx_bytes
>> statistics overflow in about 1 min.
>> 
>> In order to allow us to trace the tx_bytes statistics
>> for longer time in high throughput, change its type
>> from u32 to u64.
> 
> Hmm. 64-bit values are kinda expensive on 32-bit architectures. How
> badly do you need this? I mean ... worst case you just have to capture
> every 30 seconds or so if you're doing really high throughput with HE 
> or
> something?
> 
> johannes

Hi Johannes,

I understand your concern. Yes, I am using high end AP for throughput 
test. I'd say 1.2 Gbps is not the worst case since we can achieve max 
1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is 
the minimum requirement. And I think, with more and more high end 
products(even higher throughput) on the ways to the market, it is highly 
possible that 30s is not a safe time before overflow.

-- 
Yibo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Johannes Berg]

On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
> 
> I understand your concern. Yes, I am using high end AP for throughput 
> test. I'd say 1.2 Gbps is not the worst case since we can achieve max 
> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is 
> the minimum requirement. And I think, with more and more high end 
> products(even higher throughput) on the ways to the market, it is highly 
> possible that 30s is not a safe time before overflow.

Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
rate.

But still, the only place we expose this is debugfs, so I'm not really
sure we want to spend that.

Note that I'm generally pushing back on statistics right now - I really
want to put some trace points or eBPF hooks in places that people can
use to keep their favourite statistics, instead of trying to cover each
and every use case in the stack itself.

johannes

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Johannes Berg]

On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
> 
> I understand your concern. Yes, I am using high end AP for throughput 
> test. I'd say 1.2 Gbps is not the worst case since we can achieve max 
> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min is 
> the minimum requirement. And I think, with more and more high end 
> products(even higher throughput) on the ways to the market, it is highly 
> possible that 30s is not a safe time before overflow.

Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
rate.

But still, the only place we expose this is debugfs, so I'm not really
sure we want to spend that.

Note that I'm generally pushing back on statistics right now - I really
want to put some trace points or eBPF hooks in places that people can
use to keep their favourite statistics, instead of trying to cover each
and every use case in the stack itself.

johannes


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

On 2019-04-09 04:01, Johannes Berg wrote:
> On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
>> 
>> I understand your concern. Yes, I am using high end AP for throughput
>> test. I'd say 1.2 Gbps is not the worst case since we can achieve max
>> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min 
>> is
>> the minimum requirement. And I think, with more and more high end
>> products(even higher throughput) on the ways to the market, it is 
>> highly
>> possible that 30s is not a safe time before overflow.
> 
> Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
> not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
> rate.
> 
> But still, the only place we expose this is debugfs, so I'm not really
> sure we want to spend that.
> 
> Note that I'm generally pushing back on statistics right now - I really
> want to put some trace points or eBPF hooks in places that people can
> use to keep their favourite statistics, instead of trying to cover each
> and every use case in the stack itself.

Cool, great!looking forward to that change. :-)
> 
> johannes

-- 
Yibo

Re: [PATCH v2] fq: fix fq_tin tx bytes overflow

[Yibo Zhao]

On 2019-04-09 04:01, Johannes Berg wrote:
> On Mon, 2019-03-18 at 12:59 +0800, Yibo Zhao wrote:
>> 
>> I understand your concern. Yes, I am using high end AP for throughput
>> test. I'd say 1.2 Gbps is not the worst case since we can achieve max
>> 1.4Gbps according to our test. AFAIK, for most throughput cases, 1min 
>> is
>> the minimum requirement. And I think, with more and more high end
>> products(even higher throughput) on the ways to the market, it is 
>> highly
>> possible that 30s is not a safe time before overflow.
> 
> Well, 2 Gbps (goodput) would make it overflow every 16 seconds, so I'm
> not sure where you take the 1 minute from :-) Maybe from 1.2Gbps PHY
> rate.
> 
> But still, the only place we expose this is debugfs, so I'm not really
> sure we want to spend that.
> 
> Note that I'm generally pushing back on statistics right now - I really
> want to put some trace points or eBPF hooks in places that people can
> use to keep their favourite statistics, instead of trying to cover each
> and every use case in the stack itself.

Cool, great!looking forward to that change. :-)
> 
> johannes

-- 
Yibo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k