<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/net/mac80211/tx.c, branch dev-4.17</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-05-07T18:35:15+00:00</updated>
<entry>
<title>mac80211: use timeout from the AddBA response instead of the request</title>
<updated>2018-05-07T18:35:15+00:00</updated>
<author>
<name>Sara Sharon</name>
<email>sara.sharon@intel.com</email>
</author>
<published>2018-04-20T10:49:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=914eac248d876f9c00cd1792ffec3d182c863f13'/>
<id>urn:sha1:914eac248d876f9c00cd1792ffec3d182c863f13</id>
<content type='text'>
2016 spec, section 10.24.2 specifies that the block ack
timeout in the ADD BA request is advisory.

That means we should check the value in the response and
act upon it (same as buffer size).

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Add support for tx_control_port</title>
<updated>2018-03-29T12:01:27+00:00</updated>
<author>
<name>Denis Kenzior</name>
<email>denkenz@gmail.com</email>
</author>
<published>2018-03-26T17:52:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=911806491425d79107cadddbde11b42bbdfe38c8'/>
<id>urn:sha1:911806491425d79107cadddbde11b42bbdfe38c8</id>
<content type='text'>
Signed-off-by: Denis Kenzior &lt;denkenz@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2018-03-06T06:20:46+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2018-03-06T05:53:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0f3e9c97eb5a97972b0c0076a5cc01bb142f8e70'/>
<id>urn:sha1:0f3e9c97eb5a97972b0c0076a5cc01bb142f8e70</id>
<content type='text'>
All of the conflicts were cases of overlapping changes.

In net/core/devlink.c, we have to make care that the
resouce size_params have become a struct member rather
than a pointer to such an object.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mac80211: Adjust TSQ pacing shift</title>
<updated>2018-02-23T11:08:56+00:00</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
<email>toke@toke.dk</email>
</author>
<published>2018-02-02T15:11:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=36148c2bbfbe50c50206b6f61d072203c80161e0'/>
<id>urn:sha1:36148c2bbfbe50c50206b6f61d072203c80161e0</id>
<content type='text'>
Since we now have the convenient helper to do so, actually adjust the
TSQ pacing shift for packets going out over a WiFi interface. This
significantly improves throughput for locally-originated TCP
connections. The default pacing shift of 10 corresponds to ~1ms of
queued packet data. Adjusting this to a shift of 8 (i.e. ~4ms) improves
1-hop throughput for ath9k by a factor of 3, whereas increasing it more
has diminishing returns.

Achieved throughput for different values of sk_pacing_shift (average of
5 iterations of 10-sec netperf runs to a host on the other side of the
WiFi hop):

sk_pacing_shift 10:  43.21 Mbps (pre-patch)
sk_pacing_shift  9:  78.17 Mbps
sk_pacing_shift  8: 123.94 Mbps
sk_pacing_shift  7: 128.31 Mbps

Latency for competing flows increases from ~3 ms to ~10 ms with this
change. This is about the same magnitude of queueing latency induced by
flows that are not originated on the WiFi device itself (and so are not
limited by TSQ).

Signed-off-by: Toke Høiland-Jørgensen &lt;toke@toke.dk&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: add get TID helper</title>
<updated>2018-02-22T20:13:03+00:00</updated>
<author>
<name>Sara Sharon</name>
<email>sara.sharon@intel.com</email>
</author>
<published>2018-02-19T12:48:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a1f2ba04cc92414b6b933289365eab878b0b2bf4'/>
<id>urn:sha1:a1f2ba04cc92414b6b933289365eab878b0b2bf4</id>
<content type='text'>
Extracting the TID from the QOS header is common enough
to justify helper.

Signed-off-by: Sara Sharon &lt;sara.sharon@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: remove redundant initialization to pointer 'hdr'</title>
<updated>2018-02-19T12:17:23+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2018-02-02T16:31:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=11b05ba34d89808ca99180d2656438a319670c56'/>
<id>urn:sha1:11b05ba34d89808ca99180d2656438a319670c56</id>
<content type='text'>
The pointer hrd is being initialized with a value that is never read
and re-assigned a little later, hence the initialization is redundant
and can be removed.

Cleans up clang warning:
net/mac80211/tx.c:1924:24: warning: Value stored to 'hdr' during its
initialization is never read

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "mac80211: Add TXQ scheduling API"</title>
<updated>2017-12-19T09:12:48+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2017-12-19T09:11:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e7881bd5942df7df2fc450fd2aaa753fc4c4e125'/>
<id>urn:sha1:e7881bd5942df7df2fc450fd2aaa753fc4c4e125</id>
<content type='text'>
This reverts commit e937b8da5a591f141fe41aa48a2e898df9888c95.

Turns out that a new driver (mt76) is coming in through
Kalle's tree, and will conflict with this. It also has some
conflicting requirements, so we'll revisit this later.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "mac80211: Add airtime account and scheduling to TXQs"</title>
<updated>2017-12-19T09:12:26+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2017-12-19T09:10:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0973dd45ecefd746569d414406f5733062fe2817'/>
<id>urn:sha1:0973dd45ecefd746569d414406f5733062fe2817</id>
<content type='text'>
This reverts commit b0d52ad821843a6c5badebd80feef9f871904fa6.

We need to revert the TXQ scheduling API due to conflicts
with a new driver, and this depends on that API.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Add airtime account and scheduling to TXQs</title>
<updated>2017-12-11T11:40:24+00:00</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
<email>toke@toke.dk</email>
</author>
<published>2017-10-31T11:27:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b0d52ad821843a6c5badebd80feef9f871904fa6'/>
<id>urn:sha1:b0d52ad821843a6c5badebd80feef9f871904fa6</id>
<content type='text'>
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new hardware flag, AIRTIME_ACCOUNTING, is added that
drivers can set if they support reporting airtime usage of
transmissions. When this flag is set, mac80211 will expect the actual
airtime usage to be reported in the tx_time and rx_time fields of the
respective status structs.

When airtime information is present, mac80211 will schedule TXQs
(through ieee80211_next_txq()) in a way that enforces airtime fairness
between active stations. This scheduling works the same way as the ath9k
in-driver airtime fairness scheduling.

Signed-off-by: Toke Høiland-Jørgensen &lt;toke@toke.dk&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Add TXQ scheduling API</title>
<updated>2017-12-11T11:37:51+00:00</updated>
<author>
<name>Toke Høiland-Jørgensen</name>
<email>toke@toke.dk</email>
</author>
<published>2017-10-31T11:27:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e937b8da5a591f141fe41aa48a2e898df9888c95'/>
<id>urn:sha1:e937b8da5a591f141fe41aa48a2e898df9888c95</id>
<content type='text'>
This adds an API to mac80211 to handle scheduling of TXQs and changes the
interface between driver and mac80211 for TXQ handling as follows:

- The wake_tx_queue callback interface no longer includes the TXQ. Instead,
  the driver is expected to retrieve that from ieee80211_next_txq()

- Two new mac80211 functions are added: ieee80211_next_txq() and
  ieee80211_schedule_txq(). The former returns the next TXQ that should be
  scheduled, and is how the driver gets a queue to pull packets from. The
  latter is called internally by mac80211 to start scheduling a queue, and
  the driver is supposed to call it to re-schedule the TXQ after it is
  finished pulling packets from it (unless the queue emptied).

The ath9k and ath10k drivers are changed to use the new API.

Signed-off-by: Toke Høiland-Jørgensen &lt;toke@toke.dk&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
