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

[Zhu Yi <yi.zhu@intel.com>]

On Thu, 2007-06-14 at 07:48 -0400, jamal wrote:
> I dont have much time to followup for sometime to come. I have left my
> answer above. To clarify, incase i wasnt clear, I am saying:
> a) It is better to have the driver change via some strategy of when to
> open the tx path than trying to be generic. This shifts the burden to
> the driver.
> b) given the behavior of wireless media (which is very different from
> wired ethernet media), you need a different strategy. In response to
> Guy's question, I gave the example of being able to use management
> frames to open up the tx path for VO (even when you dont know VO
> packets
> are sitting on the qdisc); alternatively you could use a timer etc.
> Theres many ways to skin the cat (with apologies to cat
> lovers/owners).
> i.e you need to look at the media and be creative.
> Peters DCE for example could also be handled by having a specific
> strategy. 

OK. You tried so much to guess the traffic flow pattern in the low level
driver, which could be implemented straightforward in the Qdisc. The pro
is the Qdisc API is untouched. But the cons are:

1. driver becomes complicated (as it is too elaborate in the queue
wakeup strategies design)
2. duplicated code among drivers (otherwise you put all the queue
management logics in a new layer?)
3. it's not 100% accurate. there has to be some overhead, more or less
depends on the queue wakeup strategy the driver selected.

Time for voting?

Thanks,
-yi