From: "Toke Høiland-Jørgensen" <toke@redhat.com> To: Johannes Berg <johannes@sipsolutions.net>, Kan Yan <kyan@google.com> Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, ath10k@lists.infradead.org, John Crispin <john@phrozen.org>, Lorenzo Bianconi <lorenzo@kernel.org>, Felix Fietkau <nbd@nbd.name>, Rajkumar Manoharan <rmanohar@codeaurora.org>, Kevin Hayes <kevinhayes@google.com> Subject: Re: [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est Date: Fri, 18 Oct 2019 16:01:09 +0200 [thread overview] Message-ID: <87d0eudufu.fsf@toke.dk> (raw) In-Reply-To: <9fc60b546b54b40357264d67536733251cf39ebe.camel@sipsolutions.net> Johannes Berg <johannes@sipsolutions.net> writes: > On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote: > >> Well, let's try to do the actual math... A full-size (1538 bytes) packet >> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's >> certainly still less that 4096 us, so 12 bits is plenty. > > What about A-MSDUs? But I guess maximum continous transmissions are at > most 4ms anyway, so a single packet should never be longer. Ah yeah, those could be a bit bigger, but yeah, 4ms should at least be enough. >> That leaves >> four bits for the ACK status ID if we just split the u16; if we only >> ever have "a handful", that should be enough, no? > > It's how many are in flight at a time, 16 doesn't seem likely to happen, > but I don't really know what applications are doing with it now. > Probably only wpa_s for the EAPOL TX status. Right. Well in that case, let's try it. As long as we fail in a reasonable way, we can just see if we run into anything that breaks? I guess in this case that means rejecting requests from userspace if we run out of IDs rather than silently wrapping and returning wrong data :) >> We could also split 5/11. That would support up to 32 ACK IDs, and we >> can just truncate the airtime at 2048 us, which is not a big deal I'd >> say. > > We can also play with the units of the airtime, e.g. making that a > multiple of 2 or 4 us? Seems unlikely to matter much? Sure, that's a good point! Increments of 4us means we can fit 4ms is 10 bits, leaving plenty of space for ACK IDs (hopefully). I'll rework the series to use that instead :) -Toke
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@redhat.com> To: Johannes Berg <johannes@sipsolutions.net>, Kan Yan <kyan@google.com> Cc: Rajkumar Manoharan <rmanohar@codeaurora.org>, Kevin Hayes <kevinhayes@google.com>, make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, John Crispin <john@phrozen.org>, Lorenzo Bianconi <lorenzo@kernel.org>, Felix Fietkau <nbd@nbd.name> Subject: Re: [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est Date: Fri, 18 Oct 2019 16:01:09 +0200 [thread overview] Message-ID: <87d0eudufu.fsf@toke.dk> (raw) In-Reply-To: <9fc60b546b54b40357264d67536733251cf39ebe.camel@sipsolutions.net> Johannes Berg <johannes@sipsolutions.net> writes: > On Fri, 2019-10-18 at 15:31 +0200, Toke Høiland-Jørgensen wrote: > >> Well, let's try to do the actual math... A full-size (1538 bytes) packet >> takes ~2050 microseconds to transmit at 6 Mbps. Adding in overhead, it's >> certainly still less that 4096 us, so 12 bits is plenty. > > What about A-MSDUs? But I guess maximum continous transmissions are at > most 4ms anyway, so a single packet should never be longer. Ah yeah, those could be a bit bigger, but yeah, 4ms should at least be enough. >> That leaves >> four bits for the ACK status ID if we just split the u16; if we only >> ever have "a handful", that should be enough, no? > > It's how many are in flight at a time, 16 doesn't seem likely to happen, > but I don't really know what applications are doing with it now. > Probably only wpa_s for the EAPOL TX status. Right. Well in that case, let's try it. As long as we fail in a reasonable way, we can just see if we run into anything that breaks? I guess in this case that means rejecting requests from userspace if we run out of IDs rather than silently wrapping and returning wrong data :) >> We could also split 5/11. That would support up to 32 ACK IDs, and we >> can just truncate the airtime at 2048 us, which is not a big deal I'd >> say. > > We can also play with the units of the airtime, e.g. making that a > multiple of 2 or 4 us? Seems unlikely to matter much? Sure, that's a good point! Increments of 4us means we can fit 4ms is 10 bits, leaving plenty of space for ACK IDs (hopefully). I'll rework the series to use that instead :) -Toke _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2019-10-18 14:01 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-15 17:18 [PATCH v2 0/4] Add Airtime Queue Limits (AQL) to mac80211 Toke Høiland-Jørgensen 2019-10-15 17:18 ` Toke Høiland-Jørgensen 2019-10-15 17:18 ` [PATCH v2 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est Toke Høiland-Jørgensen 2019-10-15 17:18 ` Toke Høiland-Jørgensen 2019-10-18 0:50 ` Kan Yan 2019-10-18 0:50 ` Kan Yan 2019-10-18 10:15 ` Toke Høiland-Jørgensen 2019-10-18 10:15 ` Toke Høiland-Jørgensen 2019-10-18 12:21 ` Johannes Berg 2019-10-18 12:21 ` Johannes Berg 2019-10-18 13:31 ` Toke Høiland-Jørgensen 2019-10-18 13:31 ` Toke Høiland-Jørgensen 2019-10-18 13:48 ` Johannes Berg 2019-10-18 13:48 ` Johannes Berg 2019-10-18 14:01 ` Toke Høiland-Jørgensen [this message] 2019-10-18 14:01 ` Toke Høiland-Jørgensen 2019-10-18 14:07 ` Johannes Berg 2019-10-18 14:07 ` Johannes Berg 2019-10-18 14:22 ` Toke Høiland-Jørgensen 2019-10-18 14:22 ` Toke Høiland-Jørgensen 2019-10-18 14:14 ` Johannes Berg 2019-10-18 14:14 ` Johannes Berg 2019-10-18 14:30 ` Toke Høiland-Jørgensen 2019-10-18 14:30 ` Toke Høiland-Jørgensen 2019-10-18 12:35 ` Johannes Berg 2019-10-18 12:35 ` Johannes Berg 2019-10-18 13:01 ` Ben Greear 2019-10-18 13:01 ` Ben Greear 2019-10-15 17:18 ` [PATCH v2 2/4] mac80211: Import airtime calculation code from mt76 Toke Høiland-Jørgensen 2019-10-15 17:18 ` Toke Høiland-Jørgensen 2019-10-15 17:19 ` [PATCH v2 3/4] mac80211: Implement Airtime-based Queue Limit (AQL) Toke Høiland-Jørgensen 2019-10-15 17:19 ` Toke Høiland-Jørgensen 2019-10-15 17:19 ` [PATCH v2 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue Toke Høiland-Jørgensen 2019-10-15 17:19 ` Toke Høiland-Jørgensen 2019-10-17 0:33 ` Kan Yan 2019-10-17 0:33 ` Kan Yan 2019-10-17 9:44 ` Toke Høiland-Jørgensen 2019-10-17 9:44 ` Toke Høiland-Jørgensen 2019-10-17 9:57 ` [Make-wifi-fast] " Sebastian Moeller 2019-10-17 9:57 ` Sebastian Moeller 2019-10-17 10:24 ` Toke Høiland-Jørgensen 2019-10-17 10:24 ` Toke Høiland-Jørgensen 2019-10-17 10:25 ` Sebastian Moeller 2019-10-17 10:25 ` Sebastian Moeller 2019-10-18 1:11 ` Kan Yan 2019-10-18 1:11 ` Kan Yan 2019-10-18 14:15 ` Johannes Berg 2019-10-18 14:15 ` Johannes Berg
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87d0eudufu.fsf@toke.dk \ --to=toke@redhat.com \ --cc=ath10k@lists.infradead.org \ --cc=johannes@sipsolutions.net \ --cc=john@phrozen.org \ --cc=kevinhayes@google.com \ --cc=kyan@google.com \ --cc=linux-wireless@vger.kernel.org \ --cc=lorenzo@kernel.org \ --cc=make-wifi-fast@lists.bufferbloat.net \ --cc=nbd@nbd.name \ --cc=rmanohar@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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.