All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.