Re: [PATCH] NET: Multiqueue network device support.

[jamal <hadi@cyberus.ca>]

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