Message-Id: <1178666902.4055.28.camel@localhost>
Date:	Tue, 08 May 2007 19:28:22 -0400
From:	jamal <hadi@...erus.ca>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	"Zhu, Yi" <yi.zhu@...el.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	jgarzik@...ox.com, cramerj <cramerj@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Leech, Christopher" <christopher.leech@...el.com>,
	davem@...emloft.net
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

On Tue, 2007-08-05 at 08:35 -0700, Waskiewicz Jr, Peter P wrote:

> But the point is that although the DCE spec inspired the development of
> these patches, that is *not* the goal of these patches.  As Yi stated in
> a previous reply to this thread, the ability for any hardware to control
> its queues at the stack level in the kernel is something that is missing
> in the kernel.  If the hardware doesn't want to support it, then the
> patches as-is will not require anything to change in drivers to continue
> working as they do today.

Wireless offers a strict priority scheduler with statistical transmit
(as opposed to deterministic offered by the linux strict prio qdisc);
so wireless is not in the same boat as DCE.

> Bottom line: these patches are not for a specific technology.  I
> presented that spec to show a possible use case for these patches.  Yi
> presented a use case he can use in the wireless world.  I will be
> posting another use case shortly using ATA over Ethernet.
> 

Once you run the ATA over ethernet with your approach, please repeat the
test with a single ring in hardware and an equivalent qdisc in linux.
I dont believe you will see any difference - Linux is that good.
This is not to say i am against your patches, I am just for optimizing
for the common.

> > I dont believe wireless needs anything other than the simple 
> > approach i described. The fact that there an occasional low 
> > prio packet may endup going out first before a high prio due 
> > to the contention is non-affecting to the overall results.
> 
> I don't see how we can agree that having any type of
> head-of-line-blocking of a flow is or is not a problem.  

But where is this head-of-line blocking coming from?
Please correct me if am wrong:
If i had 4 hardware rings/queues in a wireless NIC with 4 different
WMM priorities all filled up (I would say impposible to achieve but for
the sake of discussion assume possible), then 
there is still a probability that a low prio packet will be sent first
before a high prio one. It all depends on the probabilistic nature of
the channel availability as well as the tx opportunity and backoff
timings.

> You believe it
> isn't an issue, but this is a gap that I see existing in the stack
> today.  As networking is used for more advanced features (such as ndb or
> VoIP), having the ability to separate flows from each other all the way
> to the wire I see is a huge advantage to ensure true QoS.
> 

You dont believe Linux has actually been doing QoS all these years
before DCE? It has. And we have been separating flows all those years
too. 
Wireless with CSMA/CA is a slightly different beast due to the shared
channels; its worse but not very different in nature than the case where
you have a shared ethernet hub (CSMA/CD) and you keep adding hosts to it
- we dont ask the qdiscs to backoff because we have a collision.
Where i find wireless intriguing is in the case where its available
bandwidth adjusts given the signal strength - but you are talking about
HOLs not that specific phenomena.

cheers,
jamal


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists