On Monday, March 05, 2012 04:01:17 PM Mohammed Shafi Shajakhan wrote: > ping pong ! > On Thursday 01 March 2012 07:16 PM, Mohammed Shafi Shajakhan wrote: > > On Thursday 01 March 2012 05:12 PM, Mohammed Shafi Shajakhan wrote: > >> On Thursday 01 March 2012 11:09 AM, Mohammed Shafi Shajakhan wrote: > >>> Hi Christian, > >>> > >>> On Monday 27 February 2012 09:40 PM, Christian Lamparter wrote: > >>>> With the new tx status API: "mac80211: implement wifi TX status" > >>>> All skb originating from mac80211 needs to be given back to mac80211. > >>>> > >>>> Signed-off-by: Christian Lamparter<chunkeey@xxxxxxxxxxxxxx> > >>>> --- > >>>> It's high time we change all calls in the tx-path from > >>>> dev_kfree_skb into ieee80211_free_txskb. > >>>> > >>>> The call in ath9k_tx is straightforward, but the one in > >>>> ath_tx_setup_buffer gives me headaches. I'm not sure if > >>>> we even need to check bf->bf_state.bfs_paprd at this > >>>> stage since ath_tx_start_dma sets bf->bf_state.bfs_paprd > >>>> "after" calling ath_tx_setup_buffer?! > >>> > >>> yes, i think its a problem, we cannot exactly say its the skb from > >>> mac80211 (or) its our PAPRD skb. though with the current code(as the > >>> PAPRD) is disabled the skb would be always from mac80211. let us see if > >>> we have some good solution. > >> > >> > >> got some idea, need to make sure this works perfectly, paprd frames are > >> not aggregated, so we can look only at the non-aggregated path. > >> > >> lets ignore aggregated path: > >> > >> *ath_tx_form_aggr > >> *ath_tx_send_ampdu > >> > >> > >> non-aggregated path : > >> > >> *ath_tx_start_dma > >> *ath_send_normal > >> > >> -> 'ath_tx_setup_buffer' called from 'ath_tx_start_dma' can have a > >> 'is_paprd' check based on 'txctl->paprd' which holds which chain we are > >> sending PAPRD frame. > >> > >> -> 'ath_send_normal' called from > >> -ath_tx_start_dma ( then 'bf' should be valid and we would not have > >> called 'ath_tx_setup_buffer' > >> -ath_tx_flush_tid ( which is an aggregation path) ignore it. > >> > >> > >> attached rough patch for ath9k, need to be compiled and tested. i will > >> also analyze if this can be done in a better way or any flaws in it > >> > > > > compilation fails with previous patch, forgot to declare the field in > > the declaration, attached patch passes compilation. > > > > > > would you like me to test this patch, ? Sure, I would like someone with a AR9300+ to test the patch. Currently, I'm stuck with a puny AR9287 [in a router]. So, I can't run tests all day :(. > i can just ran a bidirectional traffic test parallel y enabling > PAPRD,with this proposed patch. Actually, the changes are all within ath9k's tx error paths. So, I'm afraid just continuous traffic testing won't do, unless of course you can churn out all sorts of tx (dma) errors at the same time. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
