Sorry, I read my emails in a LIFO manner - typically that works well with last email in thread covering all the previous, but occasionally something is left over.
On Sat, 2005-23-07 at 18:14 +0200, Thomas Graf wrote: > > i.e you map the time slots to weights and priorities on the rings to the > > s/ware queue priorities. Hopefully Thomas can get that qdisc done. > > This might work for simple ring setups but I'm not sure if we can > guarantee to keep the rings filled in order to avoid gaps on the > wire. > You may be right actually for a TDM like interface where: if you dont use your slot you loose it; but someone needs to try it out. > As I take it, your approach would try to avoid having a feedback > system for the drivers to report to the qdisc which band -> ring > are to be disabled for the moment. > I am not against reporting back (NETDEV_TX_CONTINUE or NETDEV_TX_GIVE_ME_THE_SAME_Q_AGAIN for example); what worries me is that the stopping of the queue being complex. As i said, I may be worrying too much and i will be proved wrong. > What I'd propose is to have something like netif_queue_stop() but > taking a prio argument so the qdisc knows about the status of > the rings. The drawback of this idea is that if the band -> ring > mapping is not 1:1 it gets a little more complex and all the It has to be 1:1 as set by the admin. If they fsck, its their problem. Whats the worst that could happen if you have less qdiscs and only one ring gets used? In countries where they allow guns, people are not stopped from shooting some important appendages off their bodies ;-> > The simplest case is if the hardware does strict prio and does > the queueing itself based on skb->priority or similiar. We don't > need to change anything in this case except for adding the > interface to transfer the classification result to the driver. > > WRR shouldn't be a problem, although the concept is more vulnerable > to reodering if the classification doesn't work properly. > I am chewing in the background, but i cant see how reordering will happen even if we got the most stoopid admin on earth setting things up. > Now on to the 802.11e case: > > a) We need to move the queues to the hardware in order to allow > the driver to report the queue lengths to the HC. > b) The queue lengths are also required to calculate the per TC > class contention window and I think asking the qdisc for this > information is not the way to go. > c) The TC classes of the hardware can been seen as independant > stations, so they have own backoff counters. The only > speciality is that collision detection can be done before the > "wire". > -> This stuff is really dependant on the driver and probably > requires some changes. > It sounds very complex. Again implementation would tell. > Do we have any hardware which expects filling the rings in a > RR fashion? I am not sure i followed what you are saying above. cheers, jamal - 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
