* 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).