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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
