Re: [ath9k-devel] [PATCHv3 1/3] mac80211: move mesh sync beacon handler into neighbour_update
Am 26.02.2013 22:31, schrieb Thomas Pedersen:
Hi Marco,
On Mon, Feb 25, 2013 at 8:00 AM, Marco Porschma...@cozybit.com 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 Porschma...@cozybit.com
---
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
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 n...@openwrt.org mailto:n...@openwrt.org 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
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
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 http://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?
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 gree...@candelatech.com 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?
On 27 February 2013 10:45, Ben Greear gree...@candelatech.com 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?
On 02/27/2013 05:06 PM, Adrian Chadd wrote: On 27 February 2013 10:45, Ben Greear gree...@candelatech.com 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 gree...@candelatech.com 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?
On 27 February 2013 18:52, Ben Greear gree...@candelatech.com 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
