b.a.t.m.a.n.lists.open-mesh.org archive mirror
 help / color / mirror / Atom feed

From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Baligh Gasmi <gasmibal@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"open list:MAC80211" <linux-wireless@vger.kernel.org>,
	"open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [RFC PATCH v3 1/1] mac80211: use AQL airtime for expected throughput.
Date: Tue, 31 May 2022 14:54:12 +0200	[thread overview]
Message-ID: <YpYP9NBD+Wmzup+s@sellars> (raw)
In-Reply-To: <20220531100922.491344-1-gasmibal@gmail.com>

On Tue, May 31, 2022 at 12:09:22PM +0200, Baligh Gasmi wrote:
> Since the integration of AQL, packet TX airtime estimation is
> calculated and counted to be used for the dequeue limit.
> 
> Use this estimated airtime to compute expected throughput for
> each station.
> 
> It will be a generic mac80211 implementation. If the driver has
> get_expected_throughput implementation, it will be used instead.
> 
> Useful for L2 routing protocols, like B.A.T.M.A.N.
> 
> Signed-off-by: Baligh Gasmi <gasmibal@gmail.com>

Hi Baligh,

Thanks for your work, this indeed sounds very relevant for
batman-adv. Do you have some test results on how this compares to
real throughput? And maybe how it compares to other methods we
already have in the kernel, like expected throughput via
minstrel_ht rate control or the estimates performed in 802.11s
HWMP [0]?

Is there a certain minimum amount of traffic you'd suggest to have
enough samples to get a meaningful result?

I'm also wondering if we are starting to accumulate too many
places to provide wifi expected throughput calculations. Do you
see a chance that this generic mac80211 implementation could be made
good enough to be used as the sole source for both batman-adv and
802.11s HWMP, for instance? Or do you see some pros and cons
between the different methods?

Regards, Linus


[0]: https://elixir.bootlin.com/linux/v5.18/source/net/mac80211/mesh_hwmp.c#L295

next      parent reply	other threads:[~2022-05-31 12:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220531100922.491344-1-gasmibal@gmail.com>
2022-05-31 12:54 ` Linus Lüssing [this message]
2022-05-31 14:26   ` [RFC PATCH v3 1/1] mac80211: use AQL airtime for expected throughput Baligh GASMI

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=YpYP9NBD+Wmzup+s@sellars \
    --to=linus.luessing@c0d3.blue \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gasmibal@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).