From: Johannes Berg <firstname.lastname@example.org>
To: "Toke Høiland-Jørgensen" <email@example.com>,
"Jens Axboe" <firstname.lastname@example.org>,
"Emmanuel Grumbach" <email@example.com>,
"Luca Coelho" <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>,
Subject: Re: iwlwifi warnings in 5.5-rc1
Date: Wed, 11 Dec 2019 22:17:30 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On Wed, 2019-12-11 at 15:02 +0100, Toke Høiland-Jørgensen wrote:
> > 2) GSO/TSO like what we have - it's not really clear how to handle it.
> > The airtime estimate will shoot *way* up (64kB frame) once that frame
> > enters, and then ... should it "trickle back down" as the generated
> > parts are transmitted? But then the driver needs to split up the
> > airtime estimate? Or should it just go back down entirely? On the
> > first frame? That might overshoot. On the last frame? Opposite
> > problem ...
> Well, ideally it would be divided out over the component packets; but
> yeah, who is going to do that?
I'm not even sure we *can* do this easily - do we know up-front how many
packets this will expand to? We should know, but it might not be so easy
given the abstraction layers. We could guess and if it's wrong just set
it to 0 on any remaining ones.
> I think reporting it on the first packet
> would be the safest if we had to choose.
> Also, ideally we would want the
> GSO/TSO mechanism to lower the size of the superpackets at lower rates
> (does it?). At higher rates this matters less...
Well TCP does limit (pacing shift) the amount of outstanding data, so if
it's _really_ slow I guess it will also limit the size of the
It's really just an artifact of our software implementation that we
report the SKBs back as used with partial content. Maybe we shouldn't
even do that, since they weren't generated by mac80211 in the first
place, and only report the original skb or something.
> > 3) I'm not quite convinced that all drivers report the TX rate
> > completely correctly in the status, some don't even use this path
> > but the ieee80211_tx_status_ext() which doesn't update the rate.
> > 4) Probably most importantly, this is completely broken with HE because
> > there's currently no way to report HE rates in the TX status at all!
> > I just worked around that in our driver for 'iw' reporting purposes
> > by implementing the rate reporting in the sta_statistics callback,
> > but that data won't be used by the airtime estimates.
> Hmm, yeah, both of those are good points. I guess I just kinda assumed
> that the drivers were already doing the right thing there... :)
I'm not really sure I want to rely on this - this was never really
needed *functionally*, just from a *statistics* point of view (e.g. "iw
link" or such).
> > Now, (1) probably doesn't matter, the estimates don't need to be that
> > accurate. (2) I'm not sure how to solve; (3) and (4) could both be
> > solved by having some mechanism of the rate scaling to tell us what the
> > current rate is whenever it updates, rather than relying on the
> > last_rate. Really we should do that much more, and even phase out
> > last_rate entirely, it's a stupid concept.
> Yes, that last bit would be good!
We already partially have this, we have a 'get best rate' or so callback
in the rate scaling, we'd just have to extend it to the driver ops for
offloaded rate scaling.
Ideally, it'd be a function call from the rate scaling to mac80211 so we
don't have to call a function every time we need the value, but the rate
scaling just calls us whenever it updates. This would even work with
iwlwifi's offloaded algorithm - it notifies the host on all changes.
> > There's an additional wrinkle here - what about HE scheduled mode, where
> > the AP decided when and at what rate you're allowed to send? We don't
> > report that at all, not even as part of rate scaling, since rate scaling
> > only affects *our* decision, not when we send as a response to a trigger
> > frame. This is _still_ relevant for AQL, but there we can only see what
> > the AP used last (**), but we don't track that now nor do we track the
> > proportion of packets that we sent triggered vs. normal medium
> > access...
> Huh, wasn't aware that was a thing in HE; that's cool! And yeah, could
> have interesting interactions with AQL...
next prev parent reply other threads:[~2019-12-11 21:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 20:46 iwlwifi warnings in 5.5-rc1 Jens Axboe
2019-12-11 8:36 ` Johannes Berg
2019-12-11 8:53 ` Toke Høiland-Jørgensen
2019-12-11 10:11 ` Johannes Berg
2019-12-11 10:23 ` Toke Høiland-Jørgensen
2019-12-11 11:51 ` Johannes Berg
2019-12-11 13:42 ` Johannes Berg
2019-12-11 14:04 ` Toke Høiland-Jørgensen
2019-12-11 14:12 ` Johannes Berg
2019-12-11 14:47 ` Toke Høiland-Jørgensen
2019-12-11 21:18 ` Johannes Berg
2019-12-12 10:45 ` Toke Høiland-Jørgensen
2019-12-11 14:02 ` Toke Høiland-Jørgensen
2019-12-11 21:17 ` Johannes Berg [this message]
2019-12-12 10:55 ` Toke Høiland-Jørgensen
2019-12-12 11:00 ` Johannes Berg
2019-12-21 0:55 ` Jens Axboe
2019-12-21 9:17 ` Johannes Berg
2019-12-21 13:45 ` Jens Axboe
2019-12-11 13:45 ` Johannes Berg
2019-12-11 14:09 ` Toke Høiland-Jørgensen
2019-12-11 14:13 ` Johannes Berg
2019-12-11 14:55 ` Toke Høiland-Jørgensen
2019-12-11 21:19 ` Johannes Berg
2019-12-12 10:55 ` Toke Høiland-Jørgensen
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.