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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
