Michael Wu wrote:
On Tuesday 25 January 2005 11:03 pm, Dan Williams wrote:
One of the big item not mentionned by you is the in-kernel
802.11 stack (native frames and management). If done right, I guess it
would mostly be transparent to you...
You know, I was thinking of it and I just forgot to put it on the list.
If you're including madwifi and ipw2x00, we have a grand total of what, 3
or 4 802.11 stacks in the kernel at the same time? (madwifi,
orinoco/hermes, ipw2x00, linux-wlan-ng)
Only orinoco/hermes is in the kernel, and that doesn't really have much of an
802.11 stack, since most things are done in hardware. Madwifi has a fairly
complete 802.11 stack (ported from netbsd), and so does adm8211. Dunno about
ipw2x00.
Do any of these 80.11 stacks (or the upstream linux network stack) have
a solution for WLAN cards with 802.11e (QoS extension) with more than
one HW/firmware transmit queues?
As you may or may not know WLAN cards implementing 802.11e may have more
than one HW/firmware transmit queue (I know of an 802.11a chip with
802.11e extension that have 4 transmit queues in hardware/firmware with
different priority).
As far as I know the linux network stack today only have one qdisc queue
pr. device (struct netdev), so the driver may only stop/start
(netif_stop_queue()/netif_wake_queue()) one queue at a time. This is a
problem for drivers with more than one HW/firmware transmit queues, as
you can not let a full low priority HW queue block the netdev queue.
Is there an existing solution for this problem, or is an
multiqueue-pr-device solution being planned as part of introducing a
common 802.11 stack in the kernel?
--
Roar B. Rotvik
|