From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 51E693B2A4; Tue, 16 May 2017 06:17:38 -0400 (EDT) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1494929854; bh=yw42s3LJy/e8CRKsZb5Jz+5euxoWfkz8pIypugvgu3I=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=E6vCzRKjy06G3uXPUbZVvvwmAo4Wd5lFEfWXCQXz/touB+fB6DrY+5PhdxvKXkG3U HyENrr3EI25NjDb/u70a9xI2b3et3XRoTqsuzffZFYrg6KLDlrD6lMddCk2j4cNJfz g9WO+qmPhEiai45zLJWEZemCXkQ6y9jzeTZanNiM2tv0HozFlLBbUfPfBG9k8fHoYJ nXS5QeQbEQf8TIPnFTGEenS14Ba4y2K3z47HNNTVlXu/FyeiI0h+lmtbwuzvAUq7fF c6n+CPP9JC85xud52aHc3wKRowux1q96jrJ1WNEtLQPPrC5shWYj5O/ywoWq6rd5Gc D+B3LXJejQSsg== To: "Mohan\, Nitinder" Cc: "make-wifi-fast\@lists.bufferbloat.net" , "bloat-devel\@lists.bufferbloat.net" Subject: Re: [Make-wifi-fast] Get hardware queue length for wireless interface in linux kernel References: <87r2zq3szr.fsf@alrua-x1> Date: Tue, 16 May 2017 12:17:32 +0200 In-Reply-To: (Nitinder Mohan's message of "Tue, 16 May 2017 09:33:13 +0000") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878tlxhzr7.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 10:17:38 -0000 "Mohan, Nitinder" writes: > Hi Toke, > > Thank you for your quick reply. > > "Mohan, Nitinder" 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? :) >> > The MPTCP scheduler takes into account lower layer buffer levels and > schedules traffic over the interface to avoid HW bufferbloat. Right. So how does this differ from using a low-prio CC (like LEDBAT) on each of the MPTCP subflows? (If that makes sense; my knowledge of MPTCP is somewhat limited). >>> 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. > > I am using ath9k drivers so fq->backlog would work well for me. I was > giving the mac80211 structure a look but cant seem to figure out an > access point to it (say from netdevice.h). Do you have an idea of how > to retrieve a struct in mac80211 that could point me to struct fq? Yeah, that's what I meant with it being a private variable. What you can do is add an accessor function somewhere in mac80211, which would take a struct net_device and return the queue backlog. Something like u32 mac80211_get_backlog(struct net_device *dev) { struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr); return local->fq->backlog; } > Thank you for your help. You're welcome :) -Toke