Rajkumar Manoharan writes:
> On 2018-10-26 07:16, Toke Høiland-Jørgensen wrote:
>> Rajkumar Manoharan writes:
>>
>>> From: Toke Høiland-Jørgensen
> [...]
>>> u8 max_nan_de_entries;
>>> u8 tx_sk_pacing_shift;
>>> + u32 airtime_weight;
>>> };
>>
>> This doesn't make sense. Airtime we
On 2018-10-28 08:48, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan writes:
Yes. I do understand the user can change airtime at anytime but It
must be noted that different airtime weight will result in different
throughput. IMHO the defaults should not impact current benchmark.
Otherwise it
When processing HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND,
if the length of a msdu is larger than the tailroom
of the rx skb, skb_over_panic issue will happen when
calling skb_put.
In monitor mode, amsdu will be handled in this path,
and msdu_len of the first msdu_desc is the length of
the entire amsdu,
When processing HTT_T2H_MSG_TYPE_RX_IN_ORD_PADDR_IND,
if the length of a msdu is larger than the tailroom
of the rx skb, skb_over_panic issue will happen when
calling skb_put.
In monitor mode, amsdu will be handled in this path,
and msdu_len of the first msdu_desc is the length of
the entire amsdu,
