<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/mac80211/agg-tx.c, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-06-10T14:05:36+00:00</updated>
<entry>
<title>mac80211: convert HW flags to unsigned long bitmap</title>
<updated>2015-06-10T14:05:36+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-06-02T19:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=30686bf7f5b3c30831761e188a6e3cb33580fa48'/>
<id>urn:sha1:30686bf7f5b3c30831761e188a6e3cb33580fa48</id>
<content type='text'>
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: add an intermediate software queue implementation</title>
<updated>2015-04-01T18:44:34+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2015-03-27T20:30:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ba8c3d6f16a1f9305c23ac1d2fd3992508c5ac03'/>
<id>urn:sha1:ba8c3d6f16a1f9305c23ac1d2fd3992508c5ac03</id>
<content type='text'>
This allows drivers to request per-vif and per-sta-tid queues from which
they can pull frames. This makes it easier to keep the hardware queues
short, and to improve fairness between clients and vifs.

The task of scheduling packet transmission is left up to the driver -
queueing is controlled by mac80211. Drivers can only dequeue packets by
calling ieee80211_tx_dequeue. This makes it possible to add active queue
management later without changing drivers using this code.

This can also be used as a starting point to implement A-MSDU
aggregation in a way that does not add artificially induced latency.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
[resolved minor context conflict, minor changes, endian annotations]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: reject aggregation sessions with non-HT peers</title>
<updated>2015-03-30T08:33:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-03-09T10:13:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8f9c77fc1e8d4dfc1e7dc631d193162c75feef2e'/>
<id>urn:sha1:8f9c77fc1e8d4dfc1e7dc631d193162c75feef2e</id>
<content type='text'>
If a peer or some local agent (rate control, ...) decides to start
an aggregation session but doesn't support HT (which also implies
QoS), reject it.

This is mostly a corner case as such peers normally won't try to
use block-ack sessions and rate control wouldn't start them, but
technically QoS stations could request it according to the spec.

However, since drivers don't really support such non-HT sessions
it's better to reject them.

Also, while at it, move the tracing for TX sessions earlier so it
captures the error cases as well.

Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: agg-tx: avoid sending DelBA with sta-&gt;lock held</title>
<updated>2015-03-30T07:46:52+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-03-12T18:28:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2c158887f1185e04b3763ae346da9f71fcbc4429'/>
<id>urn:sha1:2c158887f1185e04b3763ae346da9f71fcbc4429</id>
<content type='text'>
The rate control locking caused a potential deadlock here due to the
locks being acquired in different orders, so that change cannot yet
be applied. However, there's no fundamental reason for this code to
hold the sta-&gt;lock while transmitting frames.

Clearly it's better not to hold the lock for longer periods of time,
which can happen here since we call all the way down to the driver.
Change the code a bit to not hold it while doing that.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: synchronously reserve TID per station</title>
<updated>2014-11-19T17:45:36+00:00</updated>
<author>
<name>Liad Kaufman</name>
<email>liad.kaufman@intel.com</email>
</author>
<published>2014-11-19T11:47:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b6da911b3cf1d342f2f7123c9eb6463d299bca4e'/>
<id>urn:sha1:b6da911b3cf1d342f2f7123c9eb6463d299bca4e</id>
<content type='text'>
In TDLS (e.g., TDLS off-channel) there is a requirement for
some drivers to supply an unused TID between the AP and the
device to the FW, to allow sending PTI requests and to allow
the FW to aggregate on a specific TID for better throughput.

To ensure that the allocated TID is indeed unused, this patch
introduces an API for blocking the driver from TXing on that
TID.

Signed-off-by: Liad Kaufman &lt;liad.kaufman@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: add WMM admission control support</title>
<updated>2014-10-22T08:42:09+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-10-07T07:38:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=02219b3abca59fca81711bfe7ee78df7abad97ce'/>
<id>urn:sha1:02219b3abca59fca81711bfe7ee78df7abad97ce</id>
<content type='text'>
Use the currently existing APIs between mac80211 and the low
level driver to implement WMM admission control.

The low level driver needs to report the media time used by
each transmitted packet in ieee80211_tx_status. Based on that
information, mac80211 will modify the QoS parameters of the
admission controlled Access Category when the limit is
reached. Once the original QoS parameters can be restored,
mac80211 will do so.

One issue with this approach is that management frames will
also erroneously be downgraded, but the upside is that the
implementation is simple. In the future, it can be extended
to driver- or device-based implementations that are better.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: introduce refcount for queue_stop_reasons</title>
<updated>2014-06-23T12:22:25+00:00</updated>
<author>
<name>Luciano Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2014-06-13T13:30:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=cca07b00a56d6ddd339e457dfd1a229222b9acf5'/>
<id>urn:sha1:cca07b00a56d6ddd339e457dfd1a229222b9acf5</id>
<content type='text'>
Sometimes different vifs may be stopping the queues for the same
reason (e.g. when several interfaces are performing a channel switch).
Instead of using a bitmask for the reasons, use an integer that holds
a refcount instead.  In order to keep it backwards compatible,
introduce a boolean in some functions that tell us whether the queue
stopping should be refcounted or not.  For now, use not refcounted for
all calls to keep it functionally the same as before.

Signed-off-by: Luciano Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: send {ADD,DEL}BA on AC_VO like other mgmt frames, as per spec</title>
<updated>2014-02-04T20:48:28+00:00</updated>
<author>
<name>Karl Beldan</name>
<email>karl.beldan@rivierawaves.com</email>
</author>
<published>2014-01-23T19:06:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c6e133277bcf05597ad32f2699b928b284138d59'/>
<id>urn:sha1:c6e133277bcf05597ad32f2699b928b284138d59</id>
<content type='text'>
ATM, {ADD,DEL}BA and BAR frames are sent on the AC matching the TID of
the BA parameters. In the discussion [1] about this patch, Johannes
recalled that it fixed some races with the DELBA and indeed this
behavior was introduced in [2].
While [2] is right for the BARs, the part queueing the {ADD,DEL}BAs on
their BA params TID AC violates the spec and is more a workaround for
some drivers. Helmut expressed some concerns wrt such drivers, in
particular DELBAs in rt2x00.

ATM, DELBAs are sent after a driver has called (hence "purposely")
ieee80211_start_tx_ba_cb_irqsafe and Johannes and Emmanuel gave some
details wrt intentions behind the split of the IEEE80211_AMPDU_TX_STOP_*
given to the driver ampdu_action supposed to call this function, which
could prove handy to people trying to do the right thing in faulty
drivers (if their fw/hw don't get in their way).

[1] http://mid.gmane.org/1390391564-18481-1-git-send-email-karl.beldan@gmail.com
[2] Commit: cf6bb79ad828 ("mac80211: Use appropriate TID for sending BAR, ADDBA and DELBA frames")

Signed-off-by: Karl Beldan &lt;karl.beldan@rivierawaves.com&gt;
Cc: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Cc: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix aggregation state with current drivers</title>
<updated>2013-01-24T14:43:51+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-01-18T22:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=8147dc7f54f0f2e13c3b65fd9628994ad576610b'/>
<id>urn:sha1:8147dc7f54f0f2e13c3b65fd9628994ad576610b</id>
<content type='text'>
For drivers that don't actually flush their queues when
aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH
or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done,
like iwlwifi or iwlegacy, mac80211 can then transmit on
a TID that the driver still considers busy. This happens
in the following way:

 - IEEE80211_AMPDU_TX_STOP_FLUSH requested
 - driver marks TID as emptying
 - mac80211 removes tid_tx data, this can copy packets
   to the TX pending queues and also let new packets
   through to the driver
 - driver gets unexpected TX as it wasn't completely
   converted to the new API

In iwlwifi, this lead to the following warning:

WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0
Tx while agg.state = 4
Modules linked in: [...]
Pid: 0, comm: kworker/0:0 Tainted: G        W   3.1.0 #1
Call Trace:
 [&lt;c1046e42&gt;] warn_slowpath_common+0x72/0xa0
 [&lt;c1046f13&gt;] warn_slowpath_fmt+0x33/0x40
 [&lt;fddffa17&gt;] iwlagn_tx_skb+0xc47/0xce0 [iwldvm]
 [&lt;fddfcaa3&gt;] iwlagn_mac_tx+0x23/0x40 [iwldvm]
 [&lt;fd8c98b6&gt;] __ieee80211_tx+0xf6/0x3c0 [mac80211]
 [&lt;fd8cbe00&gt;] ieee80211_tx+0xd0/0x100 [mac80211]
 [&lt;fd8cc176&gt;] ieee80211_xmit+0x96/0xe0 [mac80211]
 [&lt;fd8cc578&gt;] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211]
 [&lt;c1445207&gt;] dev_hard_start_xmit+0x337/0x6d0
 [&lt;c145eee9&gt;] sch_direct_xmit+0xa9/0x210
 [&lt;c14462c0&gt;] dev_queue_xmit+0x1b0/0x8e0

Fortunately, solving this problem is easy as the station
is being destroyed, so such transmit packets can only
happen due to races. Instead of trying to close the race
just let the race not reach the drivers by making two
changes:
 1) remove the explicit aggregation session teardown in
    the managed mode code, the same thing will be done
    when the station is removed, in __sta_info_destroy.
 2) When aggregation stop with AGG_STOP_DESTROY_STA is
    requested, leave the tid_tx data around as stopped.
    It will be cleared and freed in cleanup_single_sta
    later, but until then any racy packets will be put
    onto the tid_tx pending queue instead of transmitted
    which is fine since the station is being removed.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: improve aggregation debug messages</title>
<updated>2013-01-18T20:55:15+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-01-16T09:39:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0a214d3f7e5041685ebff054628a4354bedd78c3'/>
<id>urn:sha1:0a214d3f7e5041685ebff054628a4354bedd78c3</id>
<content type='text'>
A lot of the aggregation messages don't indicate the
station so they're hard to understand if there are
multiple sessions in progress. Make that easier by
adding the MAC address to most messages. Also add
the TID if it wasn't already there.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
