Re: Fwd: in-driver QoS

[Vladimir Kondratiev <vkondra@mail.ru>]

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