On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
> However, there's a nice juicy 'u16 ack_frame_id' at the start of
> ieee80211_tx_info. Could we potentially use that? We could use the top
> bit as a disambiguation flag; I think we're fine with 15 bits for the TX
> time itself (a
> -Original Message-
> From: ath10k On Behalf Of Wen Gong
> Sent: Monday, October 14, 2019 7:49 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org
> Subject: [EXT] [PATCH v6 0/3] ath10k: improve throughout of TX of sdio
V7 have sent
v7: change a few code style to meet ath10k-check script
v6: remove module parameters disable_tx_comp and alt_data
this is 3 patches of the 7 patches from ath10k: improve throughout of tcp/udp
TX/RX of sdio
v5: change ath10k_htc_setup_tx_req to add check bundle_tx
to forbidden init 2 times
v4:
For sdio chip, it is high latency bus, all the TX packet's content will
be tranferred from HOST memory to firmware memory via sdio bus, then it
need much more memory in firmware than low latency bus chip, for low
latency chip, such as PCI-E, it only need to transfer the TX descriptor
via PCI-E bus
The default credit size is 1792 bytes, but the IP mtu is 1500 bytes,
then it has about 290 bytes's waste for each data packet on sdio
transfer path for TX bundle, it will reduce the transmission utilization
ratio for data packet.
This patch enable the small credit size in firmware, firmware will
The transmission utilization ratio for sdio bus for small packet is
slow, because the space and time cost for sdio bus is same for large
length packet and small length packet. So the speed of data for large
length packet is higher than small length.
Test result of different length of data:
data
Guenter Roeck writes:
> On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote:
>> Guenter Roeck writes:
>>
>> > Hi,
>> >
>> > On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
>> >> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
>> >> are initialized to point to the
On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
> Right. Well in that case, let's try it. As long as we fail in a
> reasonable way, we can just see if we run into anything that breaks? I
> guess in this case that means rejecting requests from userspace if we
> run out of IDs
Johannes Berg writes:
> On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
>
>> Right. Well in that case, let's try it. As long as we fail in a
>> reasonable way, we can just see if we run into anything that breaks? I
>> guess in this case that means rejecting requests from
On 10/18/2019 05:35 AM, Johannes Berg wrote:
On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
Kan Yan writes:
The "tx_time_est" field, shared by control and status, is not able to
survive until the skb returns to the mac80211 layer in some
architectures. The same space is
Johannes Berg writes:
> On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote:
>
>> Well, let's try to do the actual math... A full-size (1538 bytes) packet
>> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's
>> certainly still less that 4096 us, so 12 bits is
On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
> Kan Yan writes:
>
> > The "tx_time_est" field, shared by control and status, is not able to
> > survive until the skb returns to the mac80211 layer in some
> > architectures. The same space is defined as driver_data and some
> >
Kan Yan writes:
> The "tx_time_est" field, shared by control and status, is not able to
> survive until the skb returns to the mac80211 layer in some
> architectures. The same space is defined as driver_data and some
> wireless drivers use it for other purposes, as the cb in the sk_buff
> is
On 10/18/19 12:58 AM, Kalle Valo wrote:
Guenter Roeck writes:
On Sun, Sep 01, 2019 at 11:06:05AM +0300, Kalle Valo wrote:
Guenter Roeck writes:
Hi,
On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
are initialized to point
From: Hui Peng
The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
are initialized to point to the containing `ath10k_usb` object
according to endpoint descriptors read from the device side, as shown
below in `ath10k_usb_setup_pipe_resources`:
for (i = 0; i <
On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
>
> > We can also play with the units of the airtime, e.g. making that a
> > multiple of 2 or 4 us? Seems unlikely to matter much?
>
> Sure, that's a good point! Increments of 4us means we can fit 4ms is 10
> bits, leaving plenty
On Thu, 2019-10-17 at 18:11 -0700, Kan Yan wrote:
> I don't think it is hard to take care of extra header size for frames
> with VLAN tags
VLAN tags are payload as far as wifi is concerned, so no need to take
that into account ...
johannes
___
Johannes Berg writes:
> On Fri, 2019-10-18 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
>
>> However, there's a nice juicy 'u16 ack_frame_id' at the start of
>> ieee80211_tx_info. Could we potentially use that? We could use the top
>> bit as a disambiguation flag; I think we're fine with 15
On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote:
> Well, let's try to do the actual math... A full-size (1538 bytes) packet
> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's
> certainly still less that 4096 us, so 12 bits is plenty.
What about A-MSDUs?
Johannes Berg writes:
> On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote:
>>
>> > We can also play with the units of the airtime, e.g. making that a
>> > multiple of 2 or 4 us? Seems unlikely to matter much?
>>
>> Sure, that's a good point! Increments of 4us means we can fit 4ms
From: Kan Yan
In order for the Fq_CoDel integrated in mac80211 layer operates effectively
to control excessive queueing latency, the CoDel algorithm requires an
accurate measure of how long the packets stays in the queue, aka sojourn
time. The sojourn time measured at mac80211 layer doesn't
From: Toke Høiland-Jørgensen
Felix recently added code to calculate airtime of packets to the mt76
driver. Import this into mac80211 so we can use it for airtime queue limit
calculations later.
The airtime.c file is copied verbatim from the mt76 driver, and adjusted to
use mac80211 data
From: Toke Høiland-Jørgensen
To implement airtime queue limiting, we need to keep a running account of
the estimated airtime of all skbs queued into the device. Do to this
correctly, we need to store the airtime estimate into the skb so we can
decrease the outstanding balance when the skb is
This series is a first attempt at porting the Airtime Queue Limits concept from
the out-of-tree ath10k implementation[0] to mac80211. This version takes Kan's
patch to do the throttling in mac80211, and replaces the driver API with the
mechanism from the previous version of my series, which
From: Toke Høiland-Jørgensen
The previous commit added the ability to throttle stations when they queue
too much airtime in the hardware. This commit enables the functionality by
calculating the expected airtime usage of each packet that is dequeued from
the TXQs in mac80211, and accounting that
From: Abhishek Ambure
[ Upstream commit 7ba31e6e0cdc0cc2e60e1fcbf467f3c95aea948e ]
Hostapd uses CCMP, GCMP & GCMP-256 as 'wpa_pairwise' option to run WPA3.
In WCN3990 firmware cipher suite numbers 9 to 11 are for CCMP,
GCMP & GCMP-256.
To enable CCMP, GCMP & GCMP-256 cipher suites in WCN3990
> + if (local->airtime_flags & AIRTIME_USE_AQL) {
> + airtime = ieee80211_calc_expected_tx_airtime(hw, vif,
> txq->sta,
> +skb->len);
> + if (airtime) {
> + /* We only have 10 bits
27 matches
Mail list logo
