DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 973F02081C
Message-ID: <5BE0CA46.7080705@candelatech.com>
Date:   Mon, 05 Nov 2018 14:55:02 -0800
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To:     Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
        Johannes Berg <johannes@sipsolutions.net>,
        Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
CC:     Jouni Malinen <j@w1.fi>
Subject: Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls
References: <20181105143027.17570-1-sergey.matyukevich.os@quantenna.com> <34042c1e8020bfb49ab97c9160ab50df044846af.camel@sipsolutions.net> <a65739ee-ab89-cf4d-af1b-f86fcc783bac@candelatech.com> <97d75b4c-3dc6-d863-c08b-bcc31da635b1@quantenna.com>
In-Reply-To: <97d75b4c-3dc6-d863-c08b-bcc31da635b1@quantenna.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 11/05/2018 02:49 PM, Igor Mitsyanko wrote:
> On 11/05/2018 12:45 PM, Ben Greear wrote:
>>>
>>> I see you don't implement it this way in the driver, but wouldn't it
>>> make more sense to have this as a per-STA (RA) setting? That's really
>>> the granularity it can be done on, I think?
>>>
>>> Arguably even per-RA/TID, though that seems a little excessive?
>>
>> I like the idea of providing this API per peer/tid.  And, just allow
>> peer == -1, tid == -1 or similar to mean 'all' so that you can still set
>> the entire device
>> to one particular setting w/out having to iterate through all peers if you
>> don't want to iterate...
>
> Maye I'm wrong, but isn't the setting we're discussing are for the
> device itself, not for its peers? I mean, disabling AMSDU, AMPDU implies
> we need to update capabilities advertised in our information elements,
> which are common for all devices, and it affects both Tx and Rx.
>
> And per-node/per-TID aggregation settings are a separate configuration
> option related to rate adaptation on Tx path only..

You can advertise your maximum capabilities, but just because you advertise
that you can do large AMPDU chains doesn't mean you are required to send
them.

So, to advertise stuff, it is per vdev (not per radio), but once you associate
a peer, you might decide to configure it so that you always send no more than 5
frames in an AMPDU chain, for instance.

And, you might decide that BE gets up to 32 AMPDU chain, but VI should be limitted to 16
to decrease latency just a bit.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com