2012-07-24 01:18:00

by Chun-Yeow Yeoh

[permalink] [raw]
Subject: [PATCH v3] mac80211: add extra checking for RC init upon receiving mesh beacon

Rate control statistic is flushed whenever the mesh beacon
is received. This may not optimizes the performance of rate
control algorithm. This patch ensures that we return early
from mesh_peer_init if the plink_state is ESTAB. Thus, avoid
calling the rate_control_rate_init again for established mesh
STA.

Signed-off-by: Chun-Yeow Yeoh <[email protected]>
---
v2: simplify the logic checking (Thomas Pedersen)
v3: updating the sta last rx activity (Thomas Pedersen)

net/mac80211/mesh_plink.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 4256859..4f5740e 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -360,6 +360,12 @@ static struct sta_info *mesh_peer_init(struct ieee80211_sub_if_data *sdata,
}

spin_lock_bh(&sta->lock);
+ if (sta->plink_state == NL80211_PLINK_ESTAB) {
+ sta->last_rx = jiffies;
+ spin_unlock_bh(&sta->lock);
+ return sta;
+ }
+
sta->last_rx = jiffies;
sta->sta.supp_rates[band] = rates;
if (elems->ht_cap_elem &&
--
1.7.0.4



2012-07-24 03:40:36

by Chun-Yeow Yeoh

[permalink] [raw]
Subject: Re: [PATCH v3] mac80211: add extra checking for RC init upon receiving mesh beacon

Hi, Thomas

>> sta->last_rx = jiffies;
>
> You should avoid duplicating this assignment.

I think that we should also update the sta->last_rx if the
sta->plink_state is not NL80211_PLINK_ESTAB, am I right?

Please advice. Thanks

Regards,
Chun-Yeow

2012-07-24 03:11:54

by Thomas Pedersen

[permalink] [raw]
Subject: Re: [PATCH v3] mac80211: add extra checking for RC init upon receiving mesh beacon

Chun-Yeow,

On Mon, Jul 23, 2012 at 6:15 PM, Chun-Yeow Yeoh <[email protected]> wrote:
> Rate control statistic is flushed whenever the mesh beacon
> is received. This may not optimizes the performance of rate
> control algorithm. This patch ensures that we return early
> from mesh_peer_init if the plink_state is ESTAB. Thus, avoid
> calling the rate_control_rate_init again for established mesh
> STA.
>
> Signed-off-by: Chun-Yeow Yeoh <[email protected]>
> ---
> v2: simplify the logic checking (Thomas Pedersen)
> v3: updating the sta last rx activity (Thomas Pedersen)
>
> net/mac80211/mesh_plink.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
> index 4256859..4f5740e 100644
> --- a/net/mac80211/mesh_plink.c
> +++ b/net/mac80211/mesh_plink.c
> @@ -360,6 +360,12 @@ static struct sta_info *mesh_peer_init(struct ieee80211_sub_if_data *sdata,
> }
>
> spin_lock_bh(&sta->lock);
> + if (sta->plink_state == NL80211_PLINK_ESTAB) {
> + sta->last_rx = jiffies;
> + spin_unlock_bh(&sta->lock);
> + return sta;
> + }
> +
> sta->last_rx = jiffies;

You should avoid duplicating this assignment.

Thomas

2012-07-24 03:45:19

by Julian Calaby

[permalink] [raw]
Subject: Re: [PATCH v3] mac80211: add extra checking for RC init upon receiving mesh beacon

Hi Chun-Yeow,

On Tue, Jul 24, 2012 at 1:40 PM, Yeoh Chun-Yeow <[email protected]> wrote:
> Hi, Thomas
>
>>> sta->last_rx = jiffies;
>>
>> You should avoid duplicating this assignment.
>
> I think that we should also update the sta->last_rx if the
> sta->plink_state is not NL80211_PLINK_ESTAB, am I right?

The point Thomas is making is that this assignment happens both when
the if statement's condition is true and when it's false.

So you could remove it from the if statement and move the one that's
after the if statement above the if statement and the code would be
functionally equivalent and cleaner.

Thanks,

--
Julian Calaby

Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

2012-07-24 03:47:43

by Chun-Yeow Yeoh

[permalink] [raw]
Subject: Re: [PATCH v3] mac80211: add extra checking for RC init upon receiving mesh beacon

Hi, Julian

> So you could remove it from the if statement and move the one that's
> after the if statement above the if statement and the code would be
> functionally equivalent and cleaner.

Noted. Thanks

Regards,
Chun-Yeow