netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).