[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1182219120.4092.143.camel@debian.sh.intel.com>
Date: Tue, 19 Jun 2007 10:12:00 +0800
From: Zhu Yi <yi.zhu@...el.com>
To: hadi@...erus.ca
Cc: Patrick McHardy <kaber@...sh.net>,
David Miller <davem@...emloft.net>,
peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: [PATCH] NET: Multiqueue network device support.
On Mon, 2007-06-18 at 11:16 -0400, jamal wrote:
> > 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)
>
> I am assuming by "come" you mean from the stack (example an ssh packet)
> as opposed from the outside.
Right.
> > 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.
>
> Congestion periods are the only time any of this stuff makes sense.
We are talking about the period from the time PHL is full to the time it
can accept more packets again. How to design the queue wakeup policy in
this period is the question.
> Ok, so let me repeat what i said earlier:
>
> Once a packet is in the DMA ring, we dont take it out. If a high prio
> packet is blocking a low prio one, i consider that to be fine. If otoh,
> you receive a management detail from the AP indicating that LP has its
> priority bumped or HP has its prio lowered, then by all means use that
> info to open up the path again. Again, that is an example, you could use
> that or schemes (refer to my expression on cats earlier).
No, this is not my question. Mine was much simpler. We don't need to
consider the wireless dynamic priority change case at this time. Just
tell me what you suppose the driver to do (stop|start queue) when the
hardware PHL is full but PHH is empty?
Thanks,
-yi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists