Re: cfg80211 API changes

Re: cfg80211 API changes

[Tomas Winkler]

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

Re: cfg80211 API changes

[Johannes Berg]

[-- 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 --]

Re: cfg80211 API changes

[Tomas Winkler]

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
>

Re: cfg80211 API changes

[Kalle Valo]

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

Re: cfg80211 API changes

[Sam Leffler]

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

Re: cfg80211 API changes

[Kalle Valo]

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

Re: cfg80211 API changes

[Tomas Winkler]

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
>