Thread (41 messages) 41 messages, 8 authors, 2008-08-27

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help