Re: [ath9k-devel] [PATCHv3 1/3] mac80211: move mesh sync beacon handler into neighbour_update

[Marco Porsch]

Am 26.02.2013 22:31, schrieb Thomas Pedersen:
> Hi Marco,
>
> On Mon, Feb 25, 2013 at 8:00 AM, Marco Porsch  wrote:
>> Move the beacon handler into mesh_neighbour_update where the STA
>> pointer is already available. This avoids additional overhead
>> and simplifies the handler.
>> The repositioning will also benefit mesh PS which uses T_r and
>> the updated T_offset value.
>>
>> Check frame type before calling the handler. Rename it to better
>> reflect its purpose.
>>
>> Signed-off-by: Marco Porsch
>> ---
>>
>> v3:
>>  check frame type before rx_bcn handler (Johannes)
>>
>>   net/mac80211/ieee80211_i.h |9 -
>>   net/mac80211/mesh.c|7 +--
>>   net/mac80211/mesh.h|4 +++-
>>   net/mac80211/mesh_plink.c  |   38 ---
>>   net/mac80211/mesh_sync.c   |   47 
>> +---
>>   5 files changed, 48 insertions(+), 57 deletions(-)
>>
>> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
>> index 388580a..631760f 100644
>> --- a/net/mac80211/ieee80211_i.h
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -529,11 +529,10 @@ struct ieee80211_if_ibss {
>>*/
>>   struct ieee802_11_elems;
>>   struct ieee80211_mesh_sync_ops {
>> -   void (*rx_bcn_presp)(struct ieee80211_sub_if_data *sdata,
>> -u16 stype,
>> -struct ieee80211_mgmt *mgmt,
>> -struct ieee802_11_elems *elems,
>> -struct ieee80211_rx_status *rx_status);
>> +   void (*rx_bcn)(struct sta_info *sta,
>> +  struct ieee80211_mgmt *mgmt,
>> +  struct ieee802_11_elems *elems,
>> +  u64 t_r);
>
> Why not continue to sync against probe responses?
> mesh_neighbour_update() gets these as well.

Because there was a comment about the standard mentioning only beacon 
frames. Fooled me here =/
Now I see that the standard explicitly mentions probe responses as well.
Is the sync code currently ready to handle probe responses? I am not 
perfectly sure about the sta->t_offset_setpoint stuff.

--Marco
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

Thanks Felix, I think I wasn't clear in asking my question.
Sorry about that, is it possible you can answer one below ?
On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau  wrote:

> On 2013-02-26 7:51 PM, abhinav narain wrote:
> > Thanks for the response, Felix !
> > I have some questions to ask :
> >
> > (1) So I should interpret the ath_tx_status descriptor as :
> > 14 retransmissions occurred while transmission of 1542*4 bytes.
> > Its not 14*4 retransmissions.
> Aggregates are formed by the driver before being passed to the hardware.
> The hardware makes no attempt to split them up and deal with individual
> subframes separately - this is the driver's job (in the software retry
> stage).
>
> (1) The one thing I wanted to clarify was the size of ampdu : is
it 1542*4  ?
As the timestamp of 4 frames are the same or or the sum of bytes of 4
frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu >1500
bytes (4K or 8K)
Is it because frames are split up ( before ath_tx_complete_buf()) on their
way back to mac80211.

(2) Another scenerio that intrigued me was the following :
[timestamp,retx count,rate,seq no. , framesize ]
[315065076,0, 65.0, [], *710*, 1542]
[315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
[315065599,,0, 65.0,[], *712*, 1542]
If these two (710,711) were sent at the same time : are they ampdu ? I
guess not !
But there are two different values of rates in ath_rx_status descriptor,
which I can't reconcile with.

Please throw some light on the above two cases.

Thanks,
Abhinav

> (2) I was timestamping the frame in ath_tx_txqaddbuf() and in
> > ath_tx_complete buf()
> > to get the (queuing + contention) delay. Can I somehow get just the
> > contention
> > delay in ath9k ?
> No.
>
> > (3) I am assuming struct ath_tx_buf keeps track of only one frame(skb).
> > Is that true ? or am I missing any detail ?
> It's for one buffer. Multiple buffers can be linked to form one frame
> (though the driver only uses one buffer per frame at the moment, and
> multiple frames can be linked to form an aggregate.
>
> > (4) Were the different parts of the frames tried at 3 different rates or
> > was the whole frame of 1542*4 bytes tried with different rates ?
> > I should check IEEE80211_TX_CTL_AMPDU for knowing tx aggregation ?
> See above (1)
>
> - Felix
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 9:58 AM, abhinav narain wrote:
> 
> Thanks Felix, I think I wasn't clear in asking my question.
> Sorry about that, is it possible you can answer one below ?
> On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau  > wrote:
> 
> On 2013-02-26 7:51 PM, abhinav narain wrote:
> > Thanks for the response, Felix !
> > I have some questions to ask :
> >
> > (1) So I should interpret the ath_tx_status descriptor as :
> > 14 retransmissions occurred while transmission of 1542*4 bytes.
> > Its not 14*4 retransmissions.
> Aggregates are formed by the driver before being passed to the hardware.
> The hardware makes no attempt to split them up and deal with individual
> subframes separately - this is the driver's job (in the software retry
> stage).
> 
> (1) The one thing I wanted to clarify was the size of ampdu : is
> it 1542*4  ?
> As the timestamp of 4 frames are the same or or the sum of bytes of 4
> frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
>>1500 bytes (4K or 8K) 
> Is it because frames are split up ( before ath_tx_complete_buf()) on
> their way back to mac80211.
Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
is simply a bunch of MPDUs sent together with one PHY header, separated
by delimiters.

> (2) Another scenerio that intrigued me was the following : 
> [timestamp,retx count,rate,seq no. , framesize ]
> [315065076,0, 65.0, [], *710*, 1542]
> [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> [315065599,,0, 65.0,[], *712*, 1542]
> If these two (710,711) were sent at the same time : are they ampdu ? I
> guess not !
> But there are two different values of rates in ath_rx_status descriptor,
> which I can't reconcile with.
> 
> Please throw some light on the above two cases.
There's code in current ath9k that passes the A-MPDU rx status to
mac80211 for inclusion in radiotap. I suggest you rely on hardware
information instead of guesswork.

- Felix

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

>
>
> > As the timestamp of 4 frames are the same or or the sum of bytes of 4
> > frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
> >>1500 bytes (4K or 8K)
> > Is it because frames are split up ( before ath_tx_complete_buf()) on
> > their way back to mac80211.
> Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
> is simply a bunch of MPDUs sent together with one PHY header, separated
> by delimiters.
>
I know the above basics :-)
I was asking in the specific case I have shown in the email,
how to interpret the ath_tx_status entries in this case.
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*

Is the ampdu size=1542 ? consisting of 4 frames with seq.no. 706-709 ? or
size=1542*4.


> > (2) Another scenerio that intrigued me was the following :
> > [timestamp,retx count,rate,seq no. , framesize ]
> > [315065076,0, 65.0, [], *710*, 1542]
> > [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> > [315065599,,0, 65.0,[], *712*, 1542]
> > If these two (710,711) were sent at the same time : are they ampdu ? I
> > guess not !
> > But there are two different values of rates in ath_rx_status descriptor,
> > which I can't reconcile with.
> >
> > Please throw some light on the above two cases.
> There's code in current ath9k that passes the A-MPDU rx status to
>

I am talking here about *tx* status in ath9k/xmit.c.
Please notice that I am finding difficulty In the xmit path.

In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
can look for aggregation.

mac80211 for inclusion in radiotap. I suggest you rely on hardware
> information instead of guesswork.

I am still confused what the hardware feedback is in ath_*tx*_status in
xmit.c


>



> - Felix
>
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 4:26 PM, abhinav narain wrote:
> 
> > As the timestamp of 4 frames are the same or or the sum of bytes of 4
> > frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
> >>1500 bytes (4K or 8K)
> > Is it because frames are split up ( before ath_tx_complete_buf()) on
> > their way back to mac80211.
> Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
> is simply a bunch of MPDUs sent together with one PHY header, separated
> by delimiters.
> 
> I know the above basics :-)
> I was asking in the specific case I have shown in the email,
> how to interpret the ath_tx_status entries in this case.  
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
> 
> Is the ampdu size=1542 ? consisting of 4 frames with seq.no
> . 706-709 ? or size=1542*4.
I'd say, probably. I have no clue where/how you're dumping the data. The
code has enough hints that show how A-MPDU status is processed (take a
look at minstrel_ht to see how it's effectively interpreted).

> > (2) Another scenerio that intrigued me was the following :
> > [timestamp,retx count,rate,seq no. , framesize ]
> > [315065076,0, 65.0, [], *710*, 1542]
> > [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> > [315065599,,0, 65.0,[], *712*, 1542]
> > If these two (710,711) were sent at the same time : are they ampdu ? I
> > guess not !
> > But there are two different values of rates in ath_rx_status
> descriptor,
> > which I can't reconcile with.
> >
> > Please throw some light on the above two cases.
> There's code in current ath9k that passes the A-MPDU rx status to
> 
> 
> I am talking here about *tx* status in ath9k/xmit.c.
> Please notice that I am finding difficulty In the xmit path.
Ah, ok, so ath_rx_status was a typo.

> In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
> can look for aggregation.
> 
> mac80211 for inclusion in radiotap. I suggest you rely on hardware
> information instead of guesswork.
> 
> I am still confused what the hardware feedback is in ath_*tx*_status in
> xmit.c
I already pointed out to you that the tx status is reported for an
entire aggregate, not individual subframes. If you take a look at the
part where it reports the status to mac80211 and look at minstrel_ht to
see how it's interpreted, you should be able to figure it out - I'm not
going to do that work for you.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Support for QCA9890 chipset?

[Ben Greear]

Looks like -ac hardware is starting to hit the market

Will these use the ath9k driver, or is there some other
driver for these NICs?

http://unex.com.tw/product/dnxa-90

Thanks,
Ben

-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Support for QCA9890 chipset?

[Adrian Chadd]

On 27 February 2013 10:45, Ben Greear  wrote:
> Looks like -ac hardware is starting to hit the market
>
> Will these use the ath9k driver, or is there some other
> driver for these NICs?
>
> http://unex.com.tw/product/dnxa-90

*cough* there's a new driver in progress. It wont' be ath9k - the
architecture involves an offload CPU (much like how ath6k NICs work.)

Thanks,


Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Support for QCA9890 chipset?

[Ben Greear]

On 02/27/2013 05:06 PM, Adrian Chadd wrote:
> On 27 February 2013 10:45, Ben Greear  wrote:
>> Looks like -ac hardware is starting to hit the market
>>
>> Will these use the ath9k driver, or is there some other
>> driver for these NICs?
>>
>> http://unex.com.tw/product/dnxa-90
>
> *cough* there's a new driver in progress. It wont' be ath9k - the
> architecture involves an offload CPU (much like how ath6k NICs work.)

Any idea when at least a beta will be released?

Will it support multiple stations and/or APs like ath9k/ath5k does?

Thanks,
Ben


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Support for QCA9890 chipset?

[Adrian Chadd]

On 27 February 2013 18:52, Ben Greear  wrote:

> Any idea when at least a beta will be released?

Nope.

> Will it support multiple stations and/or APs like ath9k/ath5k does?

I believe multi-AP, but as the device runs firmware we'll be a slave
to whatever said firmware supports. But yes, multi-AP will certainly
work.

Multi-STA - no idea.



Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel