On Fri, 2007-06-15 at 06:49 -0400, jamal wrote: > Hello Yi, > > On Fri, 2007-15-06 at 09:27 +0800, Zhu Yi wrote: > > > 1. driver becomes complicated (as it is too elaborate in the queue > > wakeup strategies design) > > I am not sure i see the complexity in the wireless driver's wakeup > strategy. I just gave some suggestions to use management frames - they > dont have to be literally that way. > > > 2. duplicated code among drivers (otherwise you put all the queue > > management logics in a new layer?) > > There will be some shared code on drivers of same media on the > netif_stop/wake strategy perhaps, but not related to queue management. > > > 3. it's not 100% accurate. there has to be some overhead, more or less > > depends on the queue wakeup strategy the driver selected. > > Why is it not accurate for wireless? I can see the corner case Patrick > mentioned in wired ethernet but then wired ethernet doesnt have other > events such as management frames (actually DCE does) to help.
Would you respond the question I asked early, in your model how to define the queue wakeup strategy in the driver to deal with the PHL full situation? Consider about 1) both high prio and low prio packets could come (you cannot predict it beforehand) 2) the time for PHL to send out a packet to the wireless medium is relative long (given the medium is congested). If you can resolve it in an elegant way, I'm all ears. Thanks, -yi - 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
