On 1 February 2017 at 09:33, Pali Rohár wrote:
> On Tuesday 31 January 2017 07:59:18 Tony Lindgren wrote:
>> * Kalle Valo [170130 22:36]:
[...]
>> > * before distro updates linux-firmware create yours own deb/rpm/whatever
>> > package "wl1251-firmware" which installs your flavor of nvs file (or
lowing warning, fix it.
> drivers/net/wireless/ath/ath10k/wmi-tlv.c: In function
> ‘ath10k_wmi_tlv_op_gen_vdev_start’:
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:1647:33: warning: variable ‘noa’
> set but not used [-Wunused-but-set-variable]
>
> Fixes: ca996ec56608 ("ath
On 22 November 2016 at 16:31, Pali Rohár wrote:
> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
>> On 21 November 2016 at 16:51, Pali Rohár wrote:
>> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>> >> Hi! I will open discussion about mac ad
On 21 November 2016 at 16:51, Pali Rohár wrote:
> On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>> Hi! I will open discussion about mac address and calibration data for
>> wl1251 wireless chip again...
>>
>> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
>> are store
: Michal Kazior
---
While preparing a re-spin of fq_codel for
mac80211-next/master I've noticed that it's
current head has the new software A-MSDU
aggregation.
I'm aware I just recently submitted fq.h.
Sorry for the noise!
include/net/fq_impl.h | 30 +++---
On 26 April 2016 at 08:43, Sedat Dilek wrote:
> On 4/26/16, Michal Kazior wrote:
>> On 26 April 2016 at 08:09, Sedat Dilek wrote:
>>> Hi,
>>>
>>> I had a very quick view on net-next.git#master (up to commit
>>> fab7b629a82da1b59620470d13152aff97523
On 26 April 2016 at 08:09, Sedat Dilek wrote:
> Hi,
>
> I had a very quick view on net-next.git#master (up to commit
> fab7b629a82da1b59620470d13152aff975239f6).
>
> Commit in [1] aka "codel: split into multiple files" removed codel.h
> but [2] and [3] have relicts to it.
> Forgot to remove?
code
ed so it
is more flexible and easier to re-use.
Signed-off-by: Michal Kazior
---
This will be used by mac80211.
For more background please see:
https://www.spinics.net/lists/linux-wireless/msg149976.html
include/net/fq.h | 95 ++
include/net/fq_impl.h
This strips out qdisc specific bits from the code
and makes it slightly more reusable. Codel will be
used by wireless/mac80211 in the future.
Signed-off-by: Michal Kazior
---
include/net/codel.h | 64 +---
net/sched/sch_codel.c| 20
https://www.spinics.net/lists/linux-wireless/msg149976.html
Michal Kazior (2):
codel: generalize the implementation
codel: split into multiple files
include/net/codel.h | 217 +--
include/net/codel_impl.h | 255 ++
in
contain function definitions with
logic that was previously in codel.h.
This copies over copyrights and doesn't involve
code changes other than adding a few additional
include directives to net/sched/sch*codel.c.
Signed-off-by: Michal Kazior
---
include/net/codel.h
On 17 April 2016 at 00:49, David Miller wrote:
> From: Michal Kazior
> Date: Thu, 14 Apr 2016 14:46:28 +0200
>
>> There are some use-cases to allow link-local
>> routing for bridging purposes.
>>
>> One of these is allowing transparent 802.11
>> bridging.
ource/Transmitter/Receiver address
distinction with only 3 addresses in frame header.
The default behavior, i.e. link-local traffic
being non-routable, remains. The user has to
explicitly enable the bypass when defining a given
route.
Signed-off-by: Michal Kazior
---
For more background see:
ource/Transmitter/Receiver address
distinction with only 3 addresses in frame header.
The default behavior, i.e. link-local traffic
being non-routable, remains. The user has to
explicitly enable the bypass when defining a given
route.
Signed-off-by: Michal Kazior
---
For more background see:
Hi,
The most commonly used framing/addressing in 802.11 is 3addr. This is
how most Access Points work and Clients follow suit.
However it is impossible to put a 3addr Client interface into a bridge
because it's not possible to properly distinguish RA/TA/DA/SA
addresses.
There is 4addr framing in
On 24 March 2016 at 13:23, Mohammed Shafi Shajakhan
wrote:
> On Thu, Mar 24, 2016 at 08:49:12AM +0100, Michal Kazior wrote:
>> On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
>> wrote:
>> > Hi Michal,
>> >
>> > On Wed, Mar 16, 2016 at 11:17:57AM
On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
wrote:
> Hi Michal,
>
> On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
>> The rate control is offloaded by firmware so it's
>> challanging to provide expected throughput value
>> for given station.
On 21 March 2016 at 18:10, Dave Taht wrote:
> thx.
>
> a lot to digest.
>
> A) quick notes on "flent-gui bursts_11e-2016-03-21T09*.gz"
>
> 1) the new bursts_11e test *should* have stuck stuff in the VI and VO
> queues, and there *should* have been some sort of difference shown on
> the plots with
On 22 March 2016 at 02:35, David Lang wrote:
> On Wed, 16 Mar 2016, Michal Kazior wrote:
>
>> Since 11n aggregation become important to get the
>> best out of txops. However aggregation inherently
>> requires buffering and queuing. Once variable
>> medium cond
on UDP_RR and it stop for
>> a while is "ok".
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Wed, Mar 16, 2016 at 3:26 AM, Michal Kazior
>> wrote:
>&
"ok".
I'm using 2.6 straight out of debian repos so yeah. I guess I'll try
using more recent netperf if I can't figure out the hiccups.
Michał
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/save
TxOP 0 has a special meaning in the standard. For HT/VHT it means the
it is actually limited to 5484us (mixed-mode) or 1us (greenfield).
I suspect the BK/BE latency difference has to do with the fact that
there's bulk traffic going on BE queues (this isn't reflected
explicitly in the plots). T
On 16 March 2016 at 11:17, Michal Kazior wrote:
> Hi,
>
> Most notable changes:
[...]
> * ath10k proof-of-concept that uses the new tx
>scheduling (will post results in separate
>email)
I'm attaching a bunch of tests I've done using flent. They are all
&quo
eless
drivers.
This bases on codel5 and sch_fq_codel.c. It may
not be the Right Thing yet but it should at least
provide a framework for more improvements.
Signed-off-by: Michal Kazior
---
include/net/mac80211.h | 96 ++-
net/mac80211/agg-tx.c | 8 +-
net/mac80211/cfg.c
el-in-mac80211 tx scheduling
purposes now.
This patch uses a very hacky way to get the stats.
This is sufficient for proof-of-concept but must
be cleaned up properly eventually.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/core.h | 5 +++
drivers/net/wireless/ath/ath10k/de
The wake_tx_queue() scheduling for non-pull-push
(or threshold based pull-push) wasn't really smart
nor fair.
Instead use the new mac80211 Tx scheduling helper
which is part of the fq-codel-in-mac80211 proof of
concept.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/c
like peak throughput
(lab conditions et al) yet.
I've uploaded a branch for convenience:
https://github.com/kazikcz/linux/tree/fqmac-rfc-v2
This is based on Kalle's ath tree.
Michal Kazior (3):
mac80211: implement fq_codel for software queuing
ath10k: report per-station t
On 10 March 2016 at 19:57, Dave Taht wrote:
>>> regular fq_codel uses 1024 and there has not been much reason to
>>> change it. In the case of an AP which has more limited memory, 256 or
>>> 1024 would be a good setting, per station. I'd stick to 1024 for now.
>>
>> Do note that the 4096 is shared
On 8 March 2016 at 14:14, Bob Copeland wrote:
> On Tue, Mar 08, 2016 at 08:12:21AM +0100, Michal Kazior wrote:
>> However other drivers (e.g. ath10k) have offloaded rate control on
>> device. There's currently no way of doing this calculation. I was
>> thinking of dr
On 8 March 2016 at 00:06, Dave Taht wrote:
> Dear Michal:
>
> Going through this patchset... (while watching it compile)
>
>
> + if (!local->hw.txq_cparams.target)
> + local->hw.txq_cparams.target = MS2TIME(5);
>
> MS2TIME(20) for now and/or add something saner to this than !*b
On 7 March 2016 at 19:28, Dave Taht wrote:
> On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun wrote:
>> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
[...]
>>> the underlying code needs to be striving successfully for per-station
>>> airtime fairness for this to work at all, and the driver/car
h will need a different set of knobs).
>
> ...
>
> Is this "per station" or per station, per 802.11e queue?
What do you have in mind by "this"?
Michał
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https
On 4 March 2016 at 03:48, Tim Shepard wrote:
[...]
> (I am interested in knowing what other mac80211 drivers have been
> modified to use the mac80211 intermediate software queues. I know
> Michal mentioned he has patches for ath10k that are not yet released,
> and I know Felix is finishing up
On 1 March 2016 at 15:02, Johannes Berg wrote:
> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>>
>> +typedef u64 codel_time_t;
>
> Do we really need this? And if yes, does it have to be in the public
> header file? Why a typedef anyway?
Hmm.. I don't thi
On 26 February 2016 at 17:48, Felix Fietkau wrote:
[...]
>> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>> index af584f7cdd63..f42f898cb8b5 100644
>> --- a/net/mac80211/tx.c
>> +++ b/net/mac80211/tx.c
>> + [...]
>> +static void ieee80211_txq_enqueue(struct ieee80211_local *local,
>> +
ing results.
- make software queueing default internally in
mac80211. This could help other drivers to get
at least some benefit from mac80211 smarter
queueing.
Signed-off-by: Michal Kazior
---
include/net/mac80211.h | 36 -
net/mac80211/agg-tx.c | 8 +-
ne
On 5 February 2016 at 17:47, Dave Taht wrote:
>> A bursted txop can be as big as 5-10ms. If you consider you want to
>> queue 5-10ms worth of data for *each* station at any given time you
>> obviously introduce a lot of lag. If you have 10 stations you might
>> end up with service period at 10*10m
On 4 February 2016 at 22:14, Ben Greear wrote:
> On 02/04/2016 12:56 PM, Grumbach, Emmanuel wrote:
>> On 02/04/2016 10:46 PM, Ben Greear wrote:
>>> On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote:
As many (all?) WiFi devices, Intel WiFi devices have
transmit queues which have 256 tr
q_codel qdisc even up to 20MB per
virtual interface.
Signed-off-by: Michal Kazior
---
Note: It is recommended to have the following
patch applied in order to avoid conflicts:
https://patchwork.kernel.org/patch/8134481/
I'm re-sending this with netdev in Cc as per
Johannes' suggestion.
On 22 May 2015 at 14:27, Kalle Valo wrote:
> Michal Kazior writes:
>> On 21 May 2015 at 15:39, Kalle Valo wrote:
[...]
>>> + static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
>>> +const struct cfg8
On 21 May 2015 at 15:39, Kalle Valo wrote:
> Hi Dave,
>
> here's a wireless-drivers pull request for 4.2. This time please pay
> extra attention to this pull as there are two problems:
>
> First of all as you can see the diffstat from git-pull-request in the
> end is just weird. I was long and har
41 matches
Mail list logo
