ath5k : Where does the actual CSMA take place?

ath5k : Where does the actual CSMA take place?

[Yiannis Yiakoumis]

Hi,

I am reading the code and trying to understand what forces the packet
out of the card, or to be more clear, what runs CSMA/CA and when
detects a tx opportunity pushes the packet down to the phy. I can
track the packet all the way until it gets to start_tx_dma(), but I am
not clear what is the actual call that sends it out, and how this
relates with QCU (I am on a 5212). I suspect that it's within the
tasklet_schedule but wasn't able to find the details.
Also, does QCU get involved on a packet-per-packet basis, or does it
just set the initial values to the device's registers?

Any help is much appreciated..

Thanks,
-- 
Yiannis .

Re: ath5k : Where does the actual CSMA take place?

[Adrian Chadd]

Hi,

The way it works is pretty straightforward (from the surface.)

* The radio signals whether the air is free or busy;
* The QCU handles the frame queuing;
* The DCU handles arbitrating between different TX queues, based on
whether the NIC is currently RXing or whether the air is busy;
* There's a bunch of timers in each DCU to implement
contention/backoff (see AR_D_* registers in the FreeBSD/madwifi HAL, I
don't know what they're called for ath5k.)
* The DCU then gates the QCU and kicks off DMA.

So the hardware is what decides when to trigger the TX DMA. In fact,
for later NICs, they may start DMAing the frame _just before_ the
IFS/backoff counters reach 0, just in case it wins the opportunity to
talk over the air.

You just setup everything to allow the NIC to begin TX DMA when it's
ready to send things. :-)

HTH,


Adrian


On 14 February 2012 12:06, Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
> Hi,
>
> I am reading the code and trying to understand what forces the packet
> out of the card, or to be more clear, what runs CSMA/CA and when
> detects a tx opportunity pushes the packet down to the phy. I can
> track the packet all the way until it gets to start_tx_dma(), but I am
> not clear what is the actual call that sends it out, and how this
> relates with QCU (I am on a 5212). I suspect that it's within the
> tasklet_schedule but wasn't able to find the details.
> Also, does QCU get involved on a packet-per-packet basis, or does it
> just set the initial values to the device's registers?
>
> Any help is much appreciated..
>
> Thanks,
> --
> Yiannis .
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath5k : Where does the actual CSMA take place?

[Yiannis Yiakoumis]

Hi Adrian,

Thanks for the explanation. I am a bit confused though. You are saying
that the DMA starts when there is a txop, is this correct?
So, does DMA take place on a per packet basis? If so, what does start_tx_dma do?

To trace things, I am sending a 10-packet train through a raw socket.
All packets go to the tx queue (length reaches 11) and then I start
receiving TX interrupts. Does each DMA request gets completed before
the next come, or tx_dma just posts the requests and these are
processed later?

When all 10 packets have been through tx_dma I start getting
interrupts. The first is a TXEOL and the rest TXDESC.
My understanding is that the time between the tx_dma and the TXDESC of
a packet, captures both DMA and wireless transmission - could somebody
comment on that?

Thanks,
Yiannis

On Tue, Feb 14, 2012 at 9:46 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> The way it works is pretty straightforward (from the surface.)
>
> * The radio signals whether the air is free or busy;
> * The QCU handles the frame queuing;
> * The DCU handles arbitrating between different TX queues, based on
> whether the NIC is currently RXing or whether the air is busy;
> * There's a bunch of timers in each DCU to implement
> contention/backoff (see AR_D_* registers in the FreeBSD/madwifi HAL, I
> don't know what they're called for ath5k.)
> * The DCU then gates the QCU and kicks off DMA.
>
> So the hardware is what decides when to trigger the TX DMA. In fact,
> for later NICs, they may start DMAing the frame _just before_ the
> IFS/backoff counters reach 0, just in case it wins the opportunity to
> talk over the air.
>
> You just setup everything to allow the NIC to begin TX DMA when it's
> ready to send things. :-)
>
> HTH,
>
>
> Adrian
>
>
> On 14 February 2012 12:06, Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
>> Hi,
>>
>> I am reading the code and trying to understand what forces the packet
>> out of the card, or to be more clear, what runs CSMA/CA and when
>> detects a tx opportunity pushes the packet down to the phy. I can
>> track the packet all the way until it gets to start_tx_dma(), but I am
>> not clear what is the actual call that sends it out, and how this
>> relates with QCU (I am on a 5212). I suspect that it's within the
>> tasklet_schedule but wasn't able to find the details.
>> Also, does QCU get involved on a packet-per-packet basis, or does it
>> just set the initial values to the device's registers?
>>
>> Any help is much appreciated..
>>
>> Thanks,
>> --
>> Yiannis .
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Yiannis .

Re: ath5k : Where does the actual CSMA take place?

[Adrian Chadd]

On 19 February 2012 14:31, Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
> Hi Adrian,
>
> Thanks for the explanation. I am a bit confused though. You are saying
> that the DMA starts when there is a txop, is this correct?

I'll have to do some digging. I recall reading about this at some
stage but I can't for the life of me remember the details.

The first couple of bits of each DCU D_MISC register controls when the
DCU starts arbitration for the PCU. The PCU is what does the DMA.
That _may_ begin the process of doing frame DMA early? As I said, I'd
hav eto check.

> So, does DMA take place on a per packet basis? If so, what does start_tx_dma do?

The driver just tickles the hardware to say "start DMA when you're
ready." It just enables the DMA to occur at some point in the future.
May reasons may stop the DMA from occuring at exactly the time you
flip on the QCU TxE bit - for example, you may flip on the TX DMA when
the unit is currently RX'ing, so there's no way the frame will go out
immediately. Or it's a beacon queue, and although you flip on TxE, the
QCU won't allow the frame to go out until the relevant beacon interval
DMA timer fires. The QCU has a variety of frame scheduling policies -
ASAP, CBR, DBA-gated (ie, the beacon gating), TIM gated, beacon-sent
gated.

So no, tickling "start DMA" doesn't necessarily start DMA.

> To trace things, I am sending a 10-packet train through a raw socket.
> All packets go to the tx queue (length reaches 11) and then I start
> receiving TX interrupts. Does each DMA request gets completed before
> the next come, or tx_dma just posts the requests and these are
> processed later?

I can't really say. I'd guess it's a mix - ie, the hardware is likely
free to fill the TX FIFO as it needs to. It may decide to DMA the next
frame whilst the current frame is going out. I'm not sure of all the
hairy MAC DMA details just yet.

> When all 10 packets have been through tx_dma I start getting
> interrupts. The first is a TXEOL and the rest TXDESC.

That's because the MAC can be told to fire off certain kinds of
interrupts, based on:

* the contents of the AR_ISR and AR_ISR_S* registers - you can request
that you be notified of TXDESC, TXEOL, TXURN, etc.
* the contents of the per-descriptor "interrupt me!" bit.

> My understanding is that the time between the tx_dma and the TXDESC of
> a packet, captures both DMA and wireless transmission - could somebody
> comment on that?

It won't be _greater_ than that (unless it failed - ie, it didn't go
out at all.) But, it is likely less than that.

Poking the MAC and saying "DMA me!" is not as accurate a starting
point as you'd like it to be. You don't AFAIK get notified by the
hardware when the DMA _occurs_, only that it's completed the transfer,
and you are provided a TSF snapshot in the TX completion part of the
TX descriptor. I can't recall whether it's the TSF value at the head
or the end of the (successful) packet transmission. But that value is
there.

Why don't you ask the list for help about what it is you're exactly
trying to achieve? :-)



Adrian