On Saturday 02 February 2008, Tomas Winkler wrote: > On Feb 1, 2008 11:43 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > Any thoughts on this patch? The only thing it should really actually > > change is removing the IBSS beacon queue configuration, but as I've > > explained previously that really has to be done by the driver because we > > don't know whether the driver even uses queues for beaconing... Also we > > never reset that info. > > > > Also, I'm wondering, iwl4965 has 16 queues, can it use 4 for regular WMM > > and the other 12 for aggregation? And how does it configure the access > > parameters for aggregation? I don't see conf_tx() calls anywhere for > > that. > > > > 4965 has 4 queues which are used for regular WMM. Only 11 queues > might be used for aggregation, but in AP mode we might map one of the > queues to after beacon multicast traffic. Just out of interest, and I don't know about the iwl4965 driver specifics, but how will you make sure those frames are send after the beacon? Does the beacon trigger an interrupt after each interval which allows you to queue the frames or is some other approach used? I am asking because I am not sure how I should implement such a thing for the rt2x00 drivers that don't have a device ATIM queue (which automatically sends the frames after the beacon was send). > One queue is reserved for communicating with FW. The number my differ > on further NICs. > > All the traffic queues 4 WMM + 11 AGG are served according regular WMM > policy, 4 AC - these are configured by conf_tx. The aggregation > queues are needed for handling ordering of frames correctly and not > for on media prioritizing > > Sorry but I have to review your patch later > Thanks > Tomas - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
