<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lwn.git/net/mac80211/util.c, branch doc/4.8-fixes</title>
<subtitle>Linux kernel documentation tree maintained by Jonathan Corbet</subtitle>
<id>http://mirrors.hust.edu.cn/git/lwn.git/atom?h=doc%2F4.8-fixes</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/lwn.git/atom?h=doc%2F4.8-fixes'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/'/>
<updated>2016-06-09T09:34:08+00:00</updated>
<entry>
<title>mac80211: implement fair queueing per txq</title>
<updated>2016-06-09T09:34:08+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2016-05-19T08:37:49+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=fa962b92120bb70693a4db545f89067eb3373294'/>
<id>urn:sha1:fa962b92120bb70693a4db545f89067eb3373294</id>
<content type='text'>
mac80211's software queues were designed to work
very closely with device tx queues. They are
required to make use of 802.11 packet aggregation
easily and efficiently.

Due to the way 802.11 aggregation is designed it
only makes sense to keep fair queuing as close to
hardware as possible to reduce induced latency and
inertia and provide the best flow responsiveness.

This change doesn't translate directly to
immediate and significant gains. End result
depends on driver's induced latency. Best results
can be achieved if driver keeps its own tx
queue/fifo fill level to a minimum.

Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: skip netdev queue control with software queuing</title>
<updated>2016-06-09T09:31:27+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2016-05-19T08:37:48+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=80a83cfc434b1e3afe38974570b460db4898bec6'/>
<id>urn:sha1:80a83cfc434b1e3afe38974570b460db4898bec6</id>
<content type='text'>
Qdiscs are designed with no regard to 802.11
aggregation requirements and hand out
packet-by-packet with no guarantee they are
destined to the same tid. This does more bad than
good no matter how fairly a given qdisc may behave
on an ethernet interface.

Software queuing used per-AC netdev subqueue
congestion control whenever a global AC limit was
hit. This meant in practice a single station or
tid queue could starve others rather easily. This
could resonate with qdiscs in a bad way or could
just end up with poor aggregation performance.
Increasing the AC limit would increase induced
latency which is also bad.

Disabling qdiscs by default and performing
taildrop instead of netdev subqueue congestion
control on the other hand makes it possible for
tid queues to fill up "in the meantime" while
preventing stations starving each other.

This increases aggregation opportunities and
should allow software queuing based drivers
achieve better performance by utilizing airtime
more efficiently with big aggregates.

Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: remove enum ieee80211_band</title>
<updated>2016-04-12T13:56:15+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2016-04-12T13:56:15+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=57fbcce37be7c1d2622b56587c10ade00e96afa3'/>
<id>urn:sha1:57fbcce37be7c1d2622b56587c10ade00e96afa3</id>
<content type='text'>
This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: allow not sending MIC up from driver for HW crypto</title>
<updated>2016-04-05T08:48:56+00:00</updated>
<author>
<name>Sara Sharon</name>
<email>sara.sharon@intel.com</email>
</author>
<published>2016-02-24T09:49:45+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=f980ebc058c2fa2a552e495db1de0b330082ab70'/>
<id>urn:sha1:f980ebc058c2fa2a552e495db1de0b330082ab70</id>
<content type='text'>
When HW crypto is used, there's no need for the CCMP/GCMP MIC to
be available to mac80211, and the hardware might have removed it
already after checking. The MIC is also useless to have when the
frame is already decrypted, so allow indicating that it's not
present.

Since we are running out of bits in mac80211_rx_flags, make
the flags field a u64.

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
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>Merge tag 'mac80211-next-for-davem-2016-02-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next</title>
<updated>2016-03-01T22:03:27+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2016-03-01T22:02:30+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=d67703fcede6696667218d29f86b4ee6ae618de6'/>
<id>urn:sha1:d67703fcede6696667218d29f86b4ee6ae618de6</id>
<content type='text'>
Johannes Berg says:

====================
Here's another round of updates for -next:
 * big A-MSDU RX performance improvement (avoid linearize of paged RX)
 * rfkill changes: cleanups, documentation, platform properties
 * basic PBSS support in cfg80211
 * MU-MIMO action frame processing support
 * BlockAck reordering &amp; duplicate detection offload support
 * various cleanups &amp; little fixes
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mac80211: move MU_MIMO_OWNER flag to ieee80211_vif</title>
<updated>2016-02-24T08:04:40+00:00</updated>
<author>
<name>Sara Sharon</name>
<email>sara.sharon@intel.com</email>
</author>
<published>2016-02-16T10:48:18+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=b5a33d52595f0cb153f09bf45a5dcd66a7418dbb'/>
<id>urn:sha1:b5a33d52595f0cb153f09bf45a5dcd66a7418dbb</id>
<content type='text'>
Drivers may need to track which vif is using VHT MU-MIMO.
Move the flag indicationg the ownership of MU_MIMO to
ieee80211_vif.

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
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: Interoperability workaround for 80+80 and 160 MHz channels</title>
<updated>2016-02-24T08:04:32+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2016-02-01T09:40:55+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=23665aaf9170ae6328cc4f68250c529a628af2ab'/>
<id>urn:sha1:23665aaf9170ae6328cc4f68250c529a628af2ab</id>
<content type='text'>
Number of deployed 80 MHz capable VHT stations that do not support 80+80
and 160 MHz bandwidths seem to misbehave when trying to connect to an AP
that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation
element. To avoid such issues with deployed devices, modify the design
based on recently accepted IEEE 802.11 standard changes (*).

This allows poorly implemented VHT 80 MHz stations to connect with the
AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support
the new workaround mechanism to allow full bandwidth to be used.
However, there are more or less no impacted station with 80+80/160
capability deployed.

The rebased version of this patch is based on the updated version from
Johannes Berg to take the HT/VHT chandef refactoring into account.

(*) Changes in
https://mentor.ieee.org/802.11/dcn/15/11-15-1530-04-000m-vht160-operation-signaling-through-non-zero-ccfs1.docx
were accepted during the IEEE 802.11 January 2016 meeting.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: expose txq queue depth and size to drivers</title>
<updated>2016-02-24T08:04:30+00:00</updated>
<author>
<name>Michal Kazior</name>
<email>michal.kazior@tieto.com</email>
</author>
<published>2016-01-27T14:26:12+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=f2ac7e301ae6397669ff3f79e691942a9b5d2f39'/>
<id>urn:sha1:f2ac7e301ae6397669ff3f79e691942a9b5d2f39</id>
<content type='text'>
This will allow drivers to make more educated
decisions whether to defer transmission or not.

Relying on wake_tx_queue() call count implicitly
was not possible because it could be called
without queued frame count actually changing on
software tx aggregation start/stop code paths.

It was also not possible to know how long
byte-wise queue was without dequeueing.

Signed-off-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: add RX_FLAG_MACTIME_PLCP_START</title>
<updated>2016-02-24T08:04:27+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2016-01-25T13:46:34+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=f4a0f0c5264e72d9279fbf9cf48a061526e8f788'/>
<id>urn:sha1:f4a0f0c5264e72d9279fbf9cf48a061526e8f788</id>
<content type='text'>
The timestamp given by iwlwifi is at the beginning of the
frame over the air, at (or during) the SYNC field. Allow
such timestamps to be given to mac80211, at least (for now)
for frames with non-HT/VHT preambles.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: refactor HT/VHT to chandef code</title>
<updated>2016-02-24T08:04:21+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-12-18T14:08:34+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=8ac3c70419176b0fbc4aeae30de661f690b2e3ae'/>
<id>urn:sha1:8ac3c70419176b0fbc4aeae30de661f690b2e3ae</id>
<content type='text'>
The station MLME and IBSS/mesh ones use entirely different
code for interpreting HT and VHT operation elements. Change
the code that interprets them a bit - it now modifies an
existing chandef - and use it also in the MLME code.

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