On Wednesday 23 August 2006 23:12, Simon Barber wrote: > We already do have intelligent qdiscs - via TC. Anyone using htb for > rate pacing, will achieve better control (less jitter) if the DMA queue > latency is kept down. > > One very important issue for 802.11 is the software rate control. At a > certain point in time the rate control algorithm may determine it's time > to start transmitting frames at a much lower rate - now all the frames > already in the DMA queue will be transmitted at the old higher rate - > and hence will suffer a lower probability of being received correctly. > If the number of frames in the DMA queue can be kept down then the rate > change happens faster. Obviously the limiting factor is keeping the DMA > queue full enough that the hardware is not starved in the worst case of > softirq latency. This is a time based limit.
Yes, that makes sense. What about the following: We don't remove the ieee80211_stop/wake_queue() mechanism, as it's simply used to protect the hard bounds of the ring. I think determining the ring latency might be possible without changing the API or even changing the low level driver. We have the ieee80211_tx_status() callback. We must simply assume any packet that's gone through hw->tx() but not yet got back through ieee80211_tx_status() is on the device queue. And I think that's a valid assumption. So accounting can be done before calling hw->tx() and in ieee80211_tx_status(). At ieee80211_tx_status() time we have all needed information. The frame length (skb), the transmission rate from the tx_control array in the status report. We have that information in hw->tx(), too, of course. So we can calculate the time (latency) the current ring state has in O(1) time. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
