Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: "Mohan\, Nitinder" <nitinder.mohan@helsinki.fi>
Cc: "make-wifi-fast\@lists.bufferbloat.net"
	<make-wifi-fast@lists.bufferbloat.net>,
	"bloat-devel\@lists.bufferbloat.net"
	<bloat-devel@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Get hardware queue length for wireless interface in linux kernel
Date: Mon, 15 May 2017 19:55:04 +0200	[thread overview]
Message-ID: <87r2zq3szr.fsf@alrua-x1> (raw)
In-Reply-To: <AM3PR07MB0661458D2FB64F0EDB32B5DA80E10@AM3PR07MB0661.eurprd07.prod.outlook.com> (Nitinder Mohan's message of "Mon, 15 May 2017 15:40:41 +0000")

"Mohan, Nitinder" <nitinder.mohan@helsinki.fi> writes:

> Hi,
>
> I am a Ph.D. student working on a bufferbloat resistant scheduler for
> Multi-Path TCP. I was unsure of which list my question would be more
> suitable in so I am sending this in both make-wifi-fast and bloat-dev
> list.

Sounds interesting! What, exactly, is such a scheduler going to be
doing? :)

> While implementing the scheduler in linux kernel, I was unable to get
> the current number of bytes in hardware queue for wlan interface. As
> currently, linux does not employ BQL for wifi devices, I could not get
> this value from dql->num_queued defined in dynamic_queue_limits.h. I
> also tried to get queue length from Queueing discipline structure i.e.
> qdisc->qstats.qlen defined in sch_generic.h yet it still gives me a
> zero value (I am getting zero values for other parameters in qstat as
> well so I am sure it is not because the queue length never becomes
> more than 0).
>
> If you have any idea for getting queue length for wireless interfaces,
> please do reply. Any help would be highly appreciated.

There's no general interface to get the queue length for WiFi
interfaces. If you're using a driver that is using the mac80211
intermediate queues (i.e., ath9k, ath10k or mt76), there are
fq->backlock and fq->memory_usage which live inside the struct fq in
struct ieee80211_local. However, these are private state vars inside
mac80211, so not immediately accessible from other parts of the kernel.
You could add an access function to mac80211, though.

Other drivers will have their own queueing implementations, that you
probably can't get at. Some devices will even have most of their
queueing in firmware.

-Toke

  reply	other threads:[~2017-05-15 17:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 15:40 Mohan, Nitinder
2017-05-15 17:55 ` Toke Høiland-Jørgensen [this message]
2017-05-16  9:33   ` Mohan, Nitinder
2017-05-16 10:17     ` Toke Høiland-Jørgensen
2017-05-16 10:45       ` Toke Høiland-Jørgensen

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

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=87r2zq3szr.fsf@alrua-x1 \
    --to=toke@toke.dk \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=nitinder.mohan@helsinki.fi \
    /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