<div>first thanks for your long (and informative) mail,.. *G</div><div><br></div><div>it`s somehow a bit my fault, as probably there was no "urgent" reason for it</div><br><div class="gmail_quote">On Thu, Jan 13, 2011 at 7:26 PM, Nick Kossifidis <span dir="ltr"><<a href="mailto:mickflemm@gmail.com">mickflemm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2011/1/13 Markus Kittenberger <<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>>:<br>
<div><div class="h5">><br> 
</div></div>Haven't looked ath9k much, on ath5k</blockquote><div> </div><div>hmm this QoS thread was never really related to a "specific" driver,..<br></div><div><br></div><div>it was just a discussion about does QoS work on wireless interfaces without defining/using qdisc that need static bandwidth </div>
<div><br></div><div>infact our starting QoS usecase was just if it works to priorize olsrd packets with some tc rules,.. (without having to shape the interface to an static (or periodically adjusted) bandwidth,..) (as imho if not doing so this can reduce the stability of an olsrd mesh,..)</div>
<div><br></div><div>and while saverio "nearly" insisted that it`s not possible (or useless), i insisted that it works fine,.. *g</div><div><br></div><div>cause e.g. old freifunkfriemware uses simple prio qdiscs to do so (together with some tc filters) with legacy broadcom drivers,<br>
and i defintely verified some years ago that this setup is definetely effective (= it e.g. allows the top priorized traffic to get all available bandwidth if it "needs" it)</div><div><br></div><div>as i already some knew that same methods don`t do well on atheros,.. (but never found the time to dig deeper,..)<br>
i did some tests on a atheros based device i had lying around (infact a ubiquiti nanostation), and started to understand why saverio came to his opinion *G<br>(as it`s really absolutely useless to do any layer 3 packet reordering (with iprouet/tc) on this devices,..)<br>
</div><div><br></div><div>this was the point when I somehow started to "blame" internal queuing of (at this point) unfortunately "undefined" wireless drivers of atheros hardware,..<br></div><div>and i didn't mention that i was infact blaming madwifi, which is afaik still the only real choice for atheros WISOC devices,..</div>
<div><br></div><div>and i think mitar asked you about your input regarding QoS and atheros drivers,..<br>and so we came somehow to ath9k,... (and started to comment it`s source code, (infact probably without a real reason to do so *G))<br>
</div><div><br></div><div>i hope this clearified how we got here *G</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">we do ACK reporting + we stop<br>

queues on mac80211 until hw finishes + free the skbs (as ath9k does in<br>
your quote). As I told you I've rarely seen driver running out of tx<br>
buffers on some reports on highly congested environments with<br>
multi-bss setups etc, never on any of my tests, I believe we handle<br>
this correctly.</blockquote><div> </div><div>if i find time next week, i will definetly run my QoS test-scripts against ath5k and ath9k aswell<br><br></div><div>and i`m quite optimistic that it will work,.. (and if not i`ll let u know *G)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The only way for tx to fail on ath5k/ath9k is a) hw<br>
reports we didn't get an ACK -through the tx status descriptor- and<br>
the frame transmition failed, b) We didn't have enough buffers and ran<br>
out of memory so driver has to stop the queues until hw is done with<br>
current queued frames/buffers c) If frame was a beacon and we couldn't<br>
transmit it on time we reset the card.<br></blockquote><div> </div><div>i guess this means dropping all currently queued packets? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Anyway dropping is normal, both layer 2 and layer 3 are by design<br>
best-effort, packet loss is part of the game, upper layers such as TCP<br>
etc will handle lost packets so there is no problem with dropping<br>
them. QoS in 802.11 and general has to do with the<br>
probability/priority of a frame/packet to go out compared to normal<br>
traffic. On 802.11e this is related to channel access and frame sizes<br>
etc (contention window), that means that a frame that goes eg. on the<br>
"voip" queue will be processed faster by the hardware (will "override"<br>
frames with lower priority on chip's scheduler) so any frame with<br>
lower priority will have more chances of being dropped (because it'll<br>
belong in a queue that is "emptied" more slowly and has more chances<br>
of getting filled up). We don't violate QoS by dropping frames since<br>
our drop probability goes together with transmition probability. Also<br>
we have tested layer 2 QoS with multiple hw queues and it works as<br>
expected, on city-wide setups + on testbeds with high<br>
traffic/bandwidth utilization scenarios.<br>
<br>
Iproute2/tc etc are higher layer tools, they operate at the IP layer<br>
and have nothing to do with how we handle frames on layer 2, there are<br>
some schedulers that "know" about hw queues but even if they don't<br>
mac80211 puts packets on the needed queues automatically</blockquote><div>hmm this depends on what layer3 was doing,..</div><div>if he tried to priorize packets (e.g. with reordering) of lower DSCP classes aginst higher ones (,without mangling their ip header), he stands alone *G <br>
<br></div><div>ofcourse this is nothing to be surprised of, but ethernet or wifi drivers having only one (small) fifo queue, would work fine with this,.. *G</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
, eg. based on<br>
DSCP, it doesn't matter anyway, even if we only had one queue layer 3<br>
QoS would still work. L3 QoS does reordering, fragmentation stuff,<br>
packet dropping/queuing and various other techniques.<br></blockquote><div> </div><div>hmm as i put before layer 3 reordering might get useless fast, if layer 2 is reordering aswell,.. <br>or (differently) classifying traffic into queues with different drop probability,..</div>
<div><br></div><div>regards Markus</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote></div>