I gave you two opportunities to bail out of this discussion, i am gonna take that your rejection to that offer implies you my friend wants to get to the bottom of this i.e you are on a mission to find the truth. So lets continue this.
On Wed, 2007-20-06 at 13:51 +0800, Zhu Yi wrote: > No, because this is over-engineered. > Furthermore, don't you think the > algorithm is complicated and unnecessary (i.e. one timer per h/w queue)? The (one-shot) timer is only necessary when a ring shuts down the driver. This is only for the case of wireless media. Standard Wired Ethernet doesnt need it. Note: You are not going to convince me by throwing cliches like "this is over-engineering" around. Because it leads to a response like "Not at all. I think Sending flow control messages back to the stack is over-engineering. " And where do we go then? > Do you think the driver maintainer will accept such kind of workaround > patch? Give me access to your manual for the chip on my laptop wireless which is 3945ABG and i can produce a very simple patch for you. Actually if you answer some questions for me, it may be good enough to produce such a patch. > You did too much to keep the Qdisc interface untouched! What metric do you want to define for "too much" - lines of code? Complexity? I consider architecture cleanliness to be more important. > Besides, the lower THL you choose, the more CPU time is wasted in busy > loop for the only PL case; Your choice of THL and THH has nothing to do with what i am proposing. I am not proposing you even touch that. What numbers do you have today? What i am saying is you use _some_ value for opening up the driver; some enlightened drivers such as the tg3 (and the e1000 - for which i unashamedly take credit) do have such parametrization. This has already been proven to be valuable. The timer fires only if a ring shuts down the interface. Where is the busy loop? If packets go out, there is no timer. > the higher THL you choose, the slower the PH > packets will be sent out than expected (the driver doesn't fully utilize > the device function -- multiple rings, I dont think you understood: Whatever value you choose for THL and THH today, keep those. OTOH, the wake threshold is what i was refering to. > which conlicts with a device driver's intention). I dont see how given i am talking about wake thresholds. > You can never make a good trade off in this model. Refer to above. > I think I have fully understood you, Thanks for coming such a long way - you stated it couldnt be done before unless you sent feedback to the stack. > but your point is invalid. The > Qdisc must be changed to have the hardware queue information to support > multiple hardware queues devices. > Handwaving as above doesnt add value to a discussion. If you want meaningful discussions, stop these cliches. cheers, jamal - 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
