On Thu, 2007-10-05 at 11:02 +0800, Zhu Yi wrote:
The difference is the hub provides the same transmission chance for all
the packets but in wireless, high priority packets will block low
priority packets transmission. You can argue there is still chances a
low priority packet is sent first
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.
Again, you're comparing these patches with DCE, which is not the intent.
It's something I presented that can
On Thu, 2007-10-05 at 11:22 -0700, Waskiewicz Jr, Peter P wrote:
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.
Again, you're comparing these patches
On Thu, 2007-05-10 at 08:35 -0400, jamal wrote:
So we may be agreeing then?
In other words, if you had both low prio and high prio in WMM
scheduler
(in wireless hardware) then the station favors a higher priority
packet
over at low priority packet at ALL times.
IOW:
Given the default
On Fri, 2007-11-05 at 09:58 +0800, Zhu Yi wrote:
Good, we agree on this.
Good start.
Now let's solve the problem.
Lets take it slowly, because i think i wasnt getting anywhere with
Peter. See if you make sense of what i am saying maybe we can make
progress.
When the low priority ring
On Tue, 2007-05-08 at 09:28 -0400, jamal wrote:
Those virtual devices you have right now. They are a hack that needs to
go at some point.
Actually, if we're talking about mac80211, the master device we have
that does the qos stuff must go, but the other virtual devices need to
stay for WDS/AP
On Tue, 2007-05-08 at 19:28 -0400, jamal wrote:
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
The difference is the hub
On Fri, 2007-05-04 at 23:22 +0200, Johannes Berg wrote:
On Fri, 2007-05-04 at 13:43 -0700, Waskiewicz Jr, Peter P wrote:
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
Somehow I didn't see the mails inbetween. Let me think.
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
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
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
Let me see if i got this right:
This new standard sends _flow control_ packets per 802.1p value?
Yes.
Sounds a bit fscked. I am assuming that the link flow control
is still on (not that i am a big fan).
No, it is not. They're mutually exclusive.
Is Datacenter ethernet the name of the
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 4 May 2007 13:01:10 -0700
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!
Why is it better for hardware to make the next packet to send decision?
For wired
On Thu, 3 May 2007 14:03:07 -0700
Waskiewicz Jr, Peter P [EMAIL PROTECTED] wrote:
Lets come up with some terminology; lets call multiqueue what
the qdiscs do; lets call what the NICs do multi-ring.
Note, i have thus far said you need to have both and they
must be in sync.
I agree
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
From: Waskiewicz Jr, Peter P [EMAIL PROTECTED]
Date: Fri, 4 May 2007 13:43:43 -0700
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.
One reason is that you're sort of making it clear
On Fri, 2007-05-04 at 13:43 -0700, Waskiewicz Jr, Peter P wrote:
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.
Not much of an if there, I'm pretty sure at least some
Lets come up with some terminology; lets call multiqueue what
the qdiscs do; lets call what the NICs do multi-ring.
Note, i have thus far said you need to have both and they
must be in sync.
I agree with the terminology.
This maybe _the_ main difference we have in opinion.
Like i said
On Thu, 2007-03-05 at 14:03 -0700, Waskiewicz Jr, Peter P wrote:
Here is a paper that describes what exactly we're trying to do:
http://www.ieee802.org/3/ar/public/0503/wadekar_1_0503.pdf. Basically
we need the ability to pause a queue independantly of another queue.
Ok, this is useful info
On Tue, 2007-01-05 at 16:04 -0700, Waskiewicz Jr, Peter P wrote:
I am just gonna delete stuff you had above here because i think you
repeat those thoughts below. Just add back anything missed.
I will try to make this email shorter, but i am not sure i will
succeed;-
1) You want to change the
On Fri, 2007-27-04 at 08:45 -0700, Waskiewicz Jr, Peter P wrote:
On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote:
I agree, that to be fair for discussing the code that you
should look
at the patches before drawing conclusions.
I appreciate the fact you have
a
On Tue, 2007-01-05 at 11:27 -0700, Waskiewicz Jr, Peter P wrote:
My patches have been under discussion for
a few months, and the general approach has been fairly well-accepted.
The comments that David, Patrick, and Thomas have given were more on
implementation, which have been fixed and are
If that queue is stopped, the qdisc will never get called to run and
-dequeue(), and hard_start_xmit() will never be called.
yes, that is true (and the desired intent)
That intent is not what we want with our approach. The desired intent
is to have independent network flows from the
On Fri, 2007-27-04 at 08:45 -0700, Waskiewicz Jr, Peter P wrote:
On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote:
I agree, that to be fair for discussing the code that you should look at
the patches before drawing conclusions.
I appreciate the fact you have
a different
On Thu, 2007-26-04 at 17:57 +0200, Patrick McHardy wrote:
The reason for suggesting to add a TC option was that these patches
move (parts of) the scheduling policy into the driver since it can
start and stop individual subqueues, which in turn cause single
bands of prio not to be dequeued
On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote:
jamal wrote:
On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
We have plans to write a new qdisc that has no priority given to any
skb's being sent to the driver. The reasoning for providing a
multiqueue
jamal wrote:
Heres the way i see it from a user perspective:
If a NIC has 3 hardware queues; if that NIC supports strict
priority
(i.e the prio qdisc) which we already support, there should
be no need
for the user to really explicitly enable that support.
It should be transparent
On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
-Original Message-
The previous version of my multiqueue patches I sent for consideration
had feedback from Patrick McHardy asking that the user be able to
configure the PRIO qdisc to run with multiqueue support or not.
jamal wrote:
On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
The previous version of my multiqueue patches I sent for consideration
had feedback from Patrick McHardy asking that the user be able to
configure the PRIO qdisc to run with multiqueue support or not. That is
why TC
jamal wrote:
On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
The previous version of my multiqueue patches I sent for
consideration
had feedback from Patrick McHardy asking that the user be able to
configure the PRIO qdisc to run with multiqueue support or
not.
Waskiewicz Jr, Peter P wrote:
I wouldn't object to putting this into a completely new scheduler
(sch_multiqueue) though since the scheduling policy might be
something completely different than strict priority.
We have plans to write a new qdisc that has no priority given to any
skb's being
Waskiewicz Jr, Peter P wrote:
I wouldn't object to putting this into a completely new scheduler
(sch_multiqueue) though since the scheduling policy might
be something
completely different than strict priority.
We have plans to write a new qdisc that has no priority
given to any
On Apr 25 2007 10:45, Waskiewicz Jr, Peter P wrote:
BTW, is there any reason this is being cced to lkml?
Since this change affects how tc interacts with the qdisc layer, I cced
lkml.
Fine with me, at least I get to know that tc could break :)
Jan
--
-
To unsubscribe from this list: send
On Tue, 2007-24-04 at 21:05 -0700, Stephen Hemminger wrote:
Peter P Waskiewicz Jr wrote:
Only if this binary compatiable with older kernels.
It is not. But i think that is a lesser problem, the bigger question is:
Why would you need to change a qdisc just so you can support egress
multiqueues?
; [EMAIL PROTECTED]
Subject: Re: [PATCH] IPROUTE: Modify tc for new PRIO
multiqueue behavior
On Tue, 2007-24-04 at 21:05 -0700, Stephen Hemminger wrote:
Peter P Waskiewicz Jr wrote:
Only if this binary compatiable with older kernels.
It is not. But i think that is a lesser problem
Peter P Waskiewicz Jr wrote:
From: Peter P Waskiewicz Jr [EMAIL PROTECTED]
Modified tc so PRIO can now have a multiqueue parameter passed to it. This
will turn on multiqueue behavior if a device has more than 1 queue. Also,
running tc qdisc ls dev dev will display if multiqueue is on or off.
36 matches
Mail list logo
