* Re: Fwd: in-driver QoS [not found] <200406072217.31924.vkondra@mail.ru> @ 2004-06-07 19:38 ` Jeff Garzik 2004-06-07 20:28 ` Vladimir Kondratiev 0 siblings, 1 reply; 3+ messages in thread From: Jeff Garzik @ 2004-06-07 19:38 UTC (permalink / raw) To: Vladimir Kondratiev; +Cc: James Ketrenos, Netdev Vladimir Kondratiev wrote: > skb->priority help determining Tx queue, but fundamental problem is with > single Tx queue from network stack. Any smart queuing/scheduling etc. made by > driver, will render useless while network stack provides single Tx queue. The packet schedulers already have multiple queues, why isn't the packet scheduling framework sufficient? Who cares if there is a single TX "delivery point" to the driver, as long as the driver knows how to differentiate queues. Jeff ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: in-driver QoS 2004-06-07 19:38 ` Fwd: in-driver QoS Jeff Garzik @ 2004-06-07 20:28 ` Vladimir Kondratiev 2004-06-07 22:58 ` Andi Kleen 0 siblings, 1 reply; 3+ messages in thread From: Vladimir Kondratiev @ 2004-06-07 20:28 UTC (permalink / raw) To: netdev; +Cc: Jeff Garzik, James Ketrenos Jeff, Point is, wireless will support QoS on link level. Ethernet have no QoS on link, thus one Tx queue was sufficient. For those QoS discipline, parameters are chosen by access point. Network stack don't know these parameters. BTW, how could driver tell to the stack what QoS should be employed? If stack do not provide exactly the same QoS as driver need, driver's one will not work. For generic 802.11 wireless stack, it should be framework for the driver to use 4 Tx queues for diff serv (separate start/stop...), and also some hooks for integrated service. Otherwise, like with current, simple 802.11 w/o TGe and other extensions, each driver will need to reinvent the wheel. I know very little about ATM, but it have QoS, both diff serv and int serv. May be it is worth to borrow from it? Vladimir. On Monday 07 June 2004 22:38, Jeff Garzik wrote: > Vladimir Kondratiev wrote: > > skb->priority help determining Tx queue, but fundamental problem is with > > single Tx queue from network stack. Any smart queuing/scheduling etc. > > made by driver, will render useless while network stack provides single > > Tx queue. > > The packet schedulers already have multiple queues, why isn't the packet > scheduling framework sufficient? > > Who cares if there is a single TX "delivery point" to the driver, as > long as the driver knows how to differentiate queues. > > Jeff ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: in-driver QoS 2004-06-07 20:28 ` Vladimir Kondratiev @ 2004-06-07 22:58 ` Andi Kleen 0 siblings, 0 replies; 3+ messages in thread From: Andi Kleen @ 2004-06-07 22:58 UTC (permalink / raw) To: Vladimir Kondratiev; +Cc: netdev, Jeff Garzik, James Ketrenos > I know very little about ATM, but it have QoS, both diff serv and int serv. > May be it is worth to borrow from it? ATM and IP diffserv just use the qdisc framework in the kernel. -Andi ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-06-07 22:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200406072217.31924.vkondra@mail.ru>
2004-06-07 19:38 ` Fwd: in-driver QoS Jeff Garzik
2004-06-07 20:28 ` Vladimir Kondratiev
2004-06-07 22:58 ` Andi Kleen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).