On Wed, Nov 19, 2014 at 12:14 AM, Felix Fietkau wrote:
>
> +static void ieee80211_drv_tx(struct ieee80211_local *local,
> +struct ieee80211_vif *vif,
> +struct ieee80211_sta *pubsta,
> +struct sk_buff *skb)
> +{
>
On 2014-12-16 00:25, Bartosz Szczepanek wrote:
> As for drv_wake_tx_queue and ieee80211_tx_dequeue - is it really
> necessary? There are ieee80211_tx_status and ieee80211_free_txskb
> already, which can be used to decide from mac80211 level when to
> dequeue packet. It could be used even in case of
As for drv_wake_tx_queue and ieee80211_tx_dequeue - is it really
necessary? There are ieee80211_tx_status and ieee80211_free_txskb
already, which can be used to decide from mac80211 level when to
dequeue packet. It could be used even in case of drivers that are not
aware of new mechanism at all. We
On Fri, 2014-12-12 at 15:28 +0100, Felix Fietkau wrote:
> > Management (and maybe control) frames can have different priorities as
> > well, this is only used for something with TDLS now I think though.
> With my implementation, those would go through the normal tx codepath,
> bypassing the softwa
On 2014-12-12 15:01, Johannes Berg wrote:
> On Fri, 2014-12-12 at 14:40 +0100, Felix Fietkau wrote:
>
>> > Then
>> > again what even sets vif->txq? Shouldn't those be per-AC? Do you really
>> > want to mix 'normal' and txq-TX?
>> Are we even using multiple ACs for packets that don't belong to a
>>
On Fri, 2014-12-12 at 14:40 +0100, Felix Fietkau wrote:
> > Then
> > again what even sets vif->txq? Shouldn't those be per-AC? Do you really
> > want to mix 'normal' and txq-TX?
> Are we even using multiple ACs for packets that don't belong to a
> particular sta? I thought normal mcast data frames
On 2014-12-12 14:21, Johannes Berg wrote:
> On Wed, 2014-11-19 at 00:14 +0100, Felix Fietkau wrote:
>
>> +struct txq_info *txq;
>> +atomic_t txq_len[IEEE80211_NUM_ACS];
>
> I think you should consider renaming the latter to txqs_len or so - it
> doesn't just cover one txq as is be implied
On Wed, 2014-11-19 at 00:14 +0100, Felix Fietkau wrote:
> + struct txq_info *txq;
> + atomic_t txq_len[IEEE80211_NUM_ACS];
I think you should consider renaming the latter to txqs_len or so - it
doesn't just cover one txq as is be implied by the name now. Otherwise
the skb_queue_head also
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 m
