On Tue, 2007-08-05 at 11:45 +0200, Johannes Berg wrote: .. Sorry, I missed a lot of the discussions; I am busyed out and will try to catchup later tonight. I have quickly scanned the emails and I will respond backwards (typically the most effective way to catchup with a thread).
As a summary, I am not against the concept of addressing per-ring flow control. Having said that, i fully understand where DaveM and Stephen are coming from. Making such huge changes to a critical region to support uncommon hardware doesnt abide to the "optimize for the common" paradigm. That is also the basis of my arguement all along. I also agree it is quiet fscked an approach to have the virtual flow control. I think it is driven by some marketing people and i dont really think there is a science behind it. Switched (External) PCI-E which is supposed to be really cheap and hit the market RSN has per-virtual queue flow control, so that maybe where that came from. In any case, that is a digression. Peter, can we meet the goals you strive for and stick to the "optimize for the common"? How willing are you to change directions to achieve those goals? > On Tue, 2007-05-08 at 17:33 +0800, Zhu Yi wrote: > > > Jamal, as you said, the wireless subsystem uses an interim workaround > > (the extra netdev approach) to achieve hardware packets scheduling. But > > with Peter's patch, the wireless stack doesn't need the workaround > > anymore. This is the actual fix. > 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. > Actually, we still need multiple devices for virtual devices? Or which > multiple devices are you talking about here? > Those virtual devices you have right now. They are a hack that needs to go at some point. 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
