All of
 help / color / mirror / Atom feed
From: Johannes Berg <>
To: "Toke Høiland-Jørgensen" <>,
	"Jens Axboe" <>,
	"Emmanuel Grumbach" <>,
	"Luca Coelho" <>
Cc: "" <>,
	Networking <>
Subject: Re: iwlwifi warnings in 5.5-rc1
Date: Thu, 12 Dec 2019 12:00:31 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 2019-12-12 at 11:55 +0100, Toke Høiland-Jørgensen wrote:
> > 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 was thinking about a scheme where we re-defined the value in the cb to
> be a "time per byte" value, that we could just multiply by the packet
> length; that would make it trivial to do partial reporting. Not sure
> it's quite workable in practice, though; it would be hard to avoid
> rounding errors, and there's also the additional headers when splitting
> a packet, so the lengths don't necessarily add up.

Yeah, that won't really work. We could only estimate the # of pieces and
split up the value across them.

> > 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.
> Hmm, yeah, was wondering how that works, actually. I assumed you send
> the whole thing to the hardware as one superpacket? But if so how do you
> get the completion events back? Or are you splitting it in the driver
> just before you send it to the hardware?

If we get say a 64k superpacket, we'll split it first into SKBs of max
A-MSDU size, and then rejigger the pieces inside each A-MSDU thing using
the DMA engine so we get A-MSDUs of MTU-sized packets out at the end.
The hardware is dumb here, it only takes care of TCP checksum.

> > 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).
> Right, I see. Well I guess now that we're turning this on one driver at
> a time, we can ensure that the driver provides sufficiently accurate
> rate information as part of that.


> BTW, since we're discussing this in the context of iwlwifi: do you have
> any data as to how much benefit AQL would be for that? I.e., do the
> Intel devices tend to buffer a lot of data in hardware/firmware?

Hardware we have queues up to ~240 frames or so, otherwise no real
buffering. Per station/TID.

> > 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.
> Yup, this makes sense, and would be easy to integrate with Minstrel as
> well, I think. We already have ieee80211_sta_set_expected_throughput(),
> so maybe expanding that? It just provides a single number now, but we
> could change it to set the full rate info instead?

Right, was thinking around that area too. Not sure about the details
really though.


  reply	other threads:[~2019-12-12 11:00 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
2019-12-12 10:55               ` Toke Høiland-Jørgensen
2019-12-12 11:00                 ` Johannes Berg [this message]
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

Reply instructions:

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.