Re: [Madwifi-devel] Specific questions on HAL/Atheros MAC behavior in hardware

[David B. <dbe...@ze...>]

Sam Leffler wrote:

> On Aug 18, 2004, at 6:12 PM, David Beberman wrote:
>
>> Hi,
>>
>> Just pulled down the merged WPA version of the driver.
>> As some more specific questions in addition to looking for a 
>> technical spec.:
>>
>> 1: Can anybody describe under what circumstances the receiving 
>> HAL/Atheros
>> chipset will not transmit an ACK for received data? I assume it won't 
>> transmit
>> an ACK to a multicast or broadcast packet. Similarly not for a 
>> beacon, and for
>> management frames. Are there any others?
>
>
> The chip follows 802.11 in acking frames.

I assume that is the 802.11 1999 MAC?

>
>>
>> 2: I'm confused about the SIFS/DIFS/PIFS handling. If the HAL is set 
>> for AP
>> mode does that mean that PIFS is used before transmitting, or only when
>> transmitting a beacon frame? Under what circumstances will the 
>> HAL/chips use a
>> PIFS or SIFS for a queued tx packet descriptor?
>
>
> Again it follows the spec. There are mechanisms for altering the IFS 
> parameters on a per h/w tx-q basis but the existing mechanism 
> (setTxQParameters) has some problems that will be addressed soon as 
> part of wme/wsm work.

In ah.h I can find setTxQueueProps. Assuming you are referring to that. 
Looking forward to those changes.

>
>>
>> 3: Does anybody have an estimate of the delay in processing from the 
>> time a
>> packet is received in the phy to the time a transmit interrupt is 
>> generated?
>
>
> Huh? rx -> tx interrupt? Understand also that there are many different 
> parts and a question like this is likely chip+bus+software dependent.

Yes, I meant receive path interrupt line latency from the hardware to 
the CPU. I'm assuming a PCI bus for my work,
but just wanted to know what the delay in PHY and MAC processing in the 
Atheros chipset was before the
rx interrupt is signalled. Sorry for the confusion and typo.

>
>>
>>
>> 4: The latest driver looks like it honors the beacon cfp duration 
>> field by
>> setting the most recently received value into the HAL. That is, NAV 
>> management
>> appears to be under software control. However there is a comment in 
>> the source
>> that tends to make me believe that NAV management is in the hardware. 
>> Something
>> to the effect that the hardware honors PCF with respect to cfp 
>> duration in
>> station mode.
>
>
> All parts will honor CFP if the hardware is programmed properly. I 
> don't believe the current code does this. The comment refers to the 
> fact that the part will not transmit during CFP but to do this right 
> it needs some parameters programmed into the hardware from the 
> CFParameters element in the received beacon. 

Reading what you wrote, it seems to imply that if the CFParameter 
element is not written back into the hardware through the Hal, then the 
hardware will not honor the cfp period. This is what i'm actually 
looking for by the way. If this is true,
don't fix it.

>
>>
>> Is this under software control and not honored in AP mode?
>> Thinking about possible DoS situations.
>
>
> Is what under software control? In AP operation CFP is specified by 
> the AP so your question doesn't make a lot of sense (unless you''re 
> thinking of overlapping BSS's using CFP in which case you should read 
> the 802.11 spec).

Yes I was thinking about situations like overlapping BSS's and other 
things. I am aware of the paragraphs in the spec. about handling those 
situations essentially using random backoff. If my response about your 
CFParameters comment is correct, then what I'm looking for is already 
addressed.

Thanks for your responses Sam.

>
> Sam
>
>