All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Rostislav Lisovy <lisovy@gmail.com>
Cc: linux-wireless@vger.kernel.org, burak.simsek@volkswagen.de,
	s.sander@nordsys.de, sojkam1@fel.cvut.cz,
	jan-niklas.meier@volkswagen.de, emmanuel.thierry@yogoko.fr,
	thierry.ernst@yogoko.fr, oyunaash@gmail.com,
	laszlo.virag@commsignia.com
Subject: Re: 802.11p rate control
Date: Wed, 10 Sep 2014 10:50:03 +0200	[thread overview]
Message-ID: <1410339003.2761.2.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1410193824.10388.24.camel@umadbro> (sfid-20140908_183026_729762_39C348F0)

On Mon, 2014-09-08 at 18:30 +0200, Rostislav Lisovy wrote:

> The possible (first implementation) solution might be either to
> implement some "dummy" rate control algorithm that will set a fixed
> datarate only once (during "ocb join" command) or to use the Minstrel
> while limiting the allowed datarate to be the lowest one; i.e.
>     mand_rates = ieee80211_mandatory_rates(sband, scan_width);
>     sta->sta.supp_rates[band] =
>         find_first_bit(&mand_rates, sizeof(u32));

That's pretty much already done anyway since you'd restrict the
supported rates to the ones that are, well, supported :)

So I don't think you need to do anything here except set up the station
correctly.


> If I am not mistaken, it is not possible to live without an in-kernel
> rate_control algorithm?
> One interesting idea I got from one colleague is to implement the
> algorithm logic in the user-space -- kernel would contain just a thin
> shell controlled from the user-space (via netlink?). This is probably
> not as insane as it may sound since the purpose of the rate-control
> algorithm for 802.11p (at least for ITS-G5) is not to "maximize the
> immediate throughput" but more like "shared medium congestion control",
> which may require much slower frequency of a control loop.

I'm not really convinced this is feasible, but in any case - are you
even communicating long enough with a single peer to make rate control
feasible?


Anyway - it seems to me that you're getting ahead of yourself. Shouldn't
you actually have a functioning datapath before worrying about rate
control? And for that you'll need station handling in mac80211, etc.

johannes


  parent reply	other threads:[~2014-09-10  8:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 16:30 802.11p rate control Rostislav Lisovy
2014-09-08 16:56 ` Felix Fietkau
2014-09-10  8:50 ` Johannes Berg [this message]
2014-09-10  9:19   ` Emmanuel Thierry

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=1410339003.2761.2.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=burak.simsek@volkswagen.de \
    --cc=emmanuel.thierry@yogoko.fr \
    --cc=jan-niklas.meier@volkswagen.de \
    --cc=laszlo.virag@commsignia.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lisovy@gmail.com \
    --cc=oyunaash@gmail.com \
    --cc=s.sander@nordsys.de \
    --cc=sojkam1@fel.cvut.cz \
    --cc=thierry.ernst@yogoko.fr \
    /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.