From: Johannes Berg <johannes@sipsolutions.net> To: "Toke Høiland-Jørgensen" <toke@redhat.com>, "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:07:20 +0200 [thread overview] Message-ID: <e2c54294fa5ac7b48e6099b47385a5f4df0859ce.camel@sipsolutions.net> (raw) In-Reply-To: <87d0eudufu.fsf@toke.dk> On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote: > 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 can't reject due to how this works, but if the idr_alloc() fails then we'll just not give a status back to userspace later. > > > 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 :) OK. There are two places that call idr_alloc() with a hardcoded limit of 0x10000, you'll have to fix those to have the right limit according to the bits you leave for the ACK id. johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net> To: "Toke Høiland-Jørgensen" <toke@redhat.com>, "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:07:20 +0200 [thread overview] Message-ID: <e2c54294fa5ac7b48e6099b47385a5f4df0859ce.camel@sipsolutions.net> (raw) In-Reply-To: <87d0eudufu.fsf@toke.dk> On Fri, 2019-10-18 at 16:01 +0200, Toke Høiland-Jørgensen wrote: > 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 can't reject due to how this works, but if the idr_alloc() fails then we'll just not give a status back to userspace later. > > > 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 :) OK. There are two places that call idr_alloc() with a hardcoded limit of 0x10000, you'll have to fix those to have the right limit according to the bits you leave for the ACK id. johannes _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2019-10-18 14:07 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 2019-10-18 14:01 ` Toke Høiland-Jørgensen 2019-10-18 14:07 ` Johannes Berg [this message] 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=e2c54294fa5ac7b48e6099b47385a5f4df0859ce.camel@sipsolutions.net \ --to=johannes@sipsolutions.net \ --cc=ath10k@lists.infradead.org \ --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 \ --cc=toke@redhat.com \ /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.