Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler
From: Jarek Poplawski <hidden>
Date: 2008-08-22 22:18:23
jamal wrote, On 08/22/2008 04:30 PM: ...
There are two issues at stake: 1) egress Multiq support and the desire to have concurency based on however many cpus and hardware queues exist on the system. 2) scheduling of the such hardware queues being executed by the hardware (and not by software). Daves goal: #1; run faster than Usain Bolt.
Looks fine.
What we were solving at the time: #2. My view was to solve it with minimal changes. #1 and #2 are orthogonal. Yes, there is religion: Dave yours is #1. Intels is #2; And there are a lot of people in intels camp because they bill their customers based on qos of resources. The wire being one such resource.
If we can guarentee that current, automatic steering gives always the best performance than David seems to be right. But I doubt it, and that's why I think such a simple, manual control could be useful. Especially if it doesn't add much overhead.
Therefore your statement that these schemes exist to "enforce fairness amongst the TX queues" needs to be qualified mon ami;-> The end parts of Animal Farm come to mind: Some animals have more rights than others;->
Sure, but shouldn't this other kind of fairness be applied on lower levels? Cheers, Jarek P.