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 r
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 defaul
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 p
> 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 c
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
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 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/
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 que
> 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" par
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 a
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
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
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 s
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 cle
> 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 to
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 wire
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.
>
> 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 th
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 inf
> 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 sa
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 th
> > 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 th
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 a
> 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
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 differe
> 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
> 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 provi
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 to them - becau
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
> multiqu
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 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:
> 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
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
> 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
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
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
ok, Auke-jan H; Leech, Christopher; [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 olde
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
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 will display if multiqueue is on or off.
S
39 matches
Mail list logo
