On Tue, Jan 17, 2006 at 02:55:31PM -0500, jamal wrote:
> On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote:

> so if i understood correctly:
> You have a master netdevice which underneath it has child netdevices?

I'm not sure what exactly "child netdev" means, but it sounds like
something that could be indeed what the stack is using. The master
netdev has a queue and all other netdevs do not use their own queue
(i.e., they share the one used in the master netdev and all TX frames go
through that).

> >  Each
> > virtual interface do not include own queue and outgoing frames are
> > queued through the master device (again, this is something that matches
> > with VLAN implementation).

> If i understood you correctly, what you are doing is certainly
> reasonable. Instead of restructuring the netdevice layer to deal with
> with multiple independent h/ware tx queues you've added a mother device
> which does intermidiate queueing. 

The master netdev collects all TX frames and the special 802.11-aware
qdisc takes care of scheduling them, e.g., based on WMM access
categories to independent hardware TX queues.

> >  For WMM, the frames in different classes
> > would need to be scheduled from all virtual interfaces together, not
> > just separately. Would there be a better way of doing this without using
> > a master netdev and qdisc/netsched?

> I havent been following the thread so i dont understand this problem.
> Can you explain it in details?

Simon wrote some more details on related topic. The way I see this is
that there can be multiple virtual netdevs (e.g., multiple virtual APs)
using the same wlan radio. The frames for all these virtual APs should
be able to share the same scheduling procedure, e.g., to allow voice
calls get high priority regardless of which virtual AP is sending the
frames for these traffic flows. Being able to set this all with existing
tc tool for the master netdev looks like quite clean way of handling
this.

-- 
Jouni Malinen                                            PGP id EFC895FA
-
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

Reply via email to