> Just because they want to standardize, and put it in hardware > doesn't mean it is a good idea and Linux needs to support it!
I gave this as the motivation for the original idea. But these patches have been under scrutiny in the community for months now, and nobody seemed to think they were totally wrong in design, just a few implementation issues. I did not design this specifically for this technology either; this was the original idea, but the idea of allowing the kernel to manage multiple queues on the NIC is the main focus here, which many people seemed to like. What happened that shifted that perception? > Why is it better for hardware to make the "next packet to > send" decision? > For wired ethernet, I can't see how adding the complexity of > fixed number of small queues is a gain. Better to just do the > priority decision in software and then queue it to the > hardware. This seems like the old Token Ring and MAP/TOP > style crap crammed on top of Ethernet. Are you saying it'd be better for the flow control requests per priority to come up into the stack? If you look closely at what I proposed in my patches, it's just an API exposing the queues in the NIC to the kernel. That's all. How the hardware handles it is completely independent to these patches. If hardware exists that wants the granularity to start/stop queues independent of each other and continue to have traffic flow, I really think it should be able to do that. That is all these patches are providing. Jamal and I talked about the original motivation, and so I shared that with the community. I don't want the focus to shift to a proposed standard that could take advantage of these patches; rather, I'd like the focus to remain on the patches themselves, and what they're providing. And if someone can explain to me why 2 months of review and scrutiny of these patches has shifted in another direction, I'd really like to understand that. Thanks, -PJ Waskiewicz - 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
