* Re: cfg80211 API changes [not found] <1ba2fa240802030539h132c7365g1bc1c20b1c560c0@mail.gmail.com> @ 2008-02-03 13:55 ` Tomas Winkler 2008-02-03 14:37 ` Johannes Berg 0 siblings, 1 reply; 7+ messages in thread From: Tomas Winkler @ 2008-02-03 13:55 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless, Ron Rindjunsky Johannes How did you planed to get transmission rate back to scaling algorithm through tx_status? I'm finding it a bit cumbersome,. now when tx_rate is pointer and doesn't resides in the ieee80211_tx_control I've seen in your patch you've just ripped this code off but our rate scale algorithms doesn't work without it actually the code that read this value in rate scale algorithm is there but it actually looking into empty space... - tx_status->control.tx_rate = - iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags); I'm just asking if you had something in mind or it's just something you forgot. struct ieee80211_tx_control { struct ieee80211_vif *vif; struct ieee80211_rate *tx_rate; ---here } Thanks Tomas ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-03 13:55 ` cfg80211 API changes Tomas Winkler @ 2008-02-03 14:37 ` Johannes Berg 2008-02-03 14:51 ` Tomas Winkler 0 siblings, 1 reply; 7+ messages in thread From: Johannes Berg @ 2008-02-03 14:37 UTC (permalink / raw) To: Tomas Winkler; +Cc: linux-wireless, Ron Rindjunsky [-- Attachment #1: Type: text/plain, Size: 748 bytes --] > I'm finding it a bit cumbersome,. now when tx_rate is pointer and > doesn't resides in the ieee80211_tx_control > I've seen in your patch you've just ripped this code off but our rate > scale algorithms doesn't work without it actually the code that read > this value in rate scale algorithm is there but it actually looking > into empty space... > > - tx_status->control.tx_rate = > - iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags); > > I'm just asking if you had something in mind or it's just something you forgot. TBH, that confused me completely since the rate scale algorithm tells the hardware what rate to use so why does the hw need to assign a different rate in the tx status? johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-03 14:37 ` Johannes Berg @ 2008-02-03 14:51 ` Tomas Winkler 2008-02-04 5:52 ` Kalle Valo 0 siblings, 1 reply; 7+ messages in thread From: Tomas Winkler @ 2008-02-03 14:51 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless, Ron Rindjunsky On Feb 3, 2008 4:37 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > > > I'm finding it a bit cumbersome,. now when tx_rate is pointer and > > doesn't resides in the ieee80211_tx_control > > I've seen in your patch you've just ripped this code off but our rate > > scale algorithms doesn't work without it actually the code that read > > this value in rate scale algorithm is there but it actually looking > > into empty space... > > > > - tx_status->control.tx_rate = > > - iwl4965_hw_get_rate_n_flags(tx_resp->rate_n_flags); > > > > I'm just asking if you had something in mind or it's just something you forgot. > > TBH, that confused me completely since the rate scale algorithm tells > the hardware what rate to use so why does the hw need to assign a > different rate in the tx status? I see. Rate scale algorithm only tels FW from what rate to start transmission. FW is responsible to do downscaling. Which is quite reasonable as retransmission is real time process. Instead of retransmitting on the same rate FW downscales. T X response provides to the rate scaling algorithm the successful rate. There is a little difference between 4956 and 3945 how the rate scale table is given to FW, but this is off the topic. Thanks Tomas > johannes > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-03 14:51 ` Tomas Winkler @ 2008-02-04 5:52 ` Kalle Valo 2008-02-04 17:19 ` Sam Leffler 0 siblings, 1 reply; 7+ messages in thread From: Kalle Valo @ 2008-02-04 5:52 UTC (permalink / raw) To: Tomas Winkler; +Cc: Johannes Berg, linux-wireless, Ron Rindjunsky Tomas Winkler <tomasw@gmail.com> writes: >> TBH, that confused me completely since the rate scale algorithm tells >> the hardware what rate to use so why does the hw need to assign a >> different rate in the tx status? > > I see. Rate scale algorithm only tels FW from what rate to start > transmission. FW is responsible to do downscaling. Which is quite > reasonable as retransmission is real time process. Instead of > retransmitting on the same rate FW downscales. T X response provides > to the rate scaling algorithm the successful rate. I just want to point out this is an important feature when the bus is very slow, for example SPI bus in embedded devices. Retransfering frames through SPI for every rate restransmit would make such a device extremely slow. -- Kalle Valo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-04 5:52 ` Kalle Valo @ 2008-02-04 17:19 ` Sam Leffler 2008-02-04 18:20 ` Kalle Valo 0 siblings, 1 reply; 7+ messages in thread From: Sam Leffler @ 2008-02-04 17:19 UTC (permalink / raw) To: Kalle Valo; +Cc: Tomas Winkler, Johannes Berg, linux-wireless, Ron Rindjunsky Kalle Valo wrote: > Tomas Winkler <tomasw@gmail.com> writes: > > >>> TBH, that confused me completely since the rate scale algorithm tells >>> the hardware what rate to use so why does the hw need to assign a >>> different rate in the tx status? >>> >> I see. Rate scale algorithm only tels FW from what rate to start >> transmission. FW is responsible to do downscaling. Which is quite >> reasonable as retransmission is real time process. Instead of >> retransmitting on the same rate FW downscales. T X response provides >> to the rate scaling algorithm the successful rate. >> > > I just want to point out this is an important feature when the bus is > very slow, for example SPI bus in embedded devices. Retransfering > frames through SPI for every rate restransmit would make such a device > extremely slow. > I don't know of a part that does repeated DMA to implement retransmit; do you have an example? Regardless, the original issue is independent; good devices support multi-rate retransmit so the final tx rate may not be the same as the rate specified for the initial series. Whether this is done in fw or hw doesn't matter. Sam ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-04 17:19 ` Sam Leffler @ 2008-02-04 18:20 ` Kalle Valo 2008-02-04 20:01 ` Tomas Winkler 0 siblings, 1 reply; 7+ messages in thread From: Kalle Valo @ 2008-02-04 18:20 UTC (permalink / raw) To: Sam Leffler; +Cc: Tomas Winkler, Johannes Berg, linux-wireless, Ron Rindjunsky Sam Leffler <sam@errno.com> writes: >>> I see. Rate scale algorithm only tels FW from what rate to start >>> transmission. FW is responsible to do downscaling. Which is quite >>> reasonable as retransmission is real time process. Instead of >>> retransmitting on the same rate FW downscales. T X response provides >>> to the rate scaling algorithm the successful rate. >> >> I just want to point out this is an important feature when the bus is >> very slow, for example SPI bus in embedded devices. Retransfering >> frames through SPI for every rate restransmit would make such a device >> extremely slow. > > I don't know of a part that does repeated DMA to implement retransmit; > do you have an example? Asking me? No, I have never heard of such a device. -- Kalle Valo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cfg80211 API changes 2008-02-04 18:20 ` Kalle Valo @ 2008-02-04 20:01 ` Tomas Winkler 0 siblings, 0 replies; 7+ messages in thread From: Tomas Winkler @ 2008-02-04 20:01 UTC (permalink / raw) To: Kalle Valo; +Cc: Sam Leffler, Johannes Berg, linux-wireless, Ron Rindjunsky On Feb 4, 2008 8:20 PM, Kalle Valo <kalle.valo@nokia.com> wrote: > Sam Leffler <sam@errno.com> writes: > > >>> I see. Rate scale algorithm only tels FW from what rate to start > >>> transmission. FW is responsible to do downscaling. Which is quite > >>> reasonable as retransmission is real time process. Instead of > >>> retransmitting on the same rate FW downscales. T X response provides > >>> to the rate scaling algorithm the successful rate. > >> > >> I just want to point out this is an important feature when the bus is > >> very slow, for example SPI bus in embedded devices. Retransfering > >> frames through SPI for every rate restransmit would make such a device > >> extremely slow. > > > > I don't know of a part that does repeated DMA to implement retransmit; > > do you have an example? > > Asking me? No, I have never heard of such a device. > Actually what is probably happening with some devices, I'm not sure though, they retries in FW/HW but do not downscale. Tomas > Kalle Valo > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-02-04 20:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1ba2fa240802030539h132c7365g1bc1c20b1c560c0@mail.gmail.com>
2008-02-03 13:55 ` cfg80211 API changes Tomas Winkler
2008-02-03 14:37 ` Johannes Berg
2008-02-03 14:51 ` Tomas Winkler
2008-02-04 5:52 ` Kalle Valo
2008-02-04 17:19 ` Sam Leffler
2008-02-04 18:20 ` Kalle Valo
2008-02-04 20:01 ` Tomas Winkler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).