WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2017-Jan-19 08:22:05

nader
Member
Registered: 2016-May-24
Posts: 22

Detecting the broadcast queue

Hi,

The wireless transmit queue manages many packets at once via a series of queues. Multicast and management packets are added to their own dedicated queues. My question is how to differentiate between the broadcast queue from normal user's queues in the MAC 802.11 Ref design.

My second question is about dynamic buffer sizing. The 802.11 Reference Design limits the maximum size of any given user's queue to MAX_TX_QUEUE_LEN = 150 packets which is constant. In case we want to implement an algorithm of dynamic buffer sizing using a scheduler, how we can do it safely without affecting the design?

Thank you.

Offline

 

#2 2017-Jan-19 11:20:44

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Detecting the broadcast queue

nader wrote:

The wireless transmit queue manages many packets at once via a series of queues. Multicast and management packets are added to their own dedicated queues. My question is how to differentiate between the broadcast queue from normal user's queues in the MAC 802.11 Ref design.

The queues are all implemented as an array of doubly-linked lists called "tx_queues". Each user gets an index into that array for their particular queue dl_list. Additionally, multicast and management packets each get their own index. The AP's index mapping is in wlan_mac_ap.h. Multicast packets will show up in tx_queues[0]. Unicast packets to users will show up in tx_queues[1+AID] (note: AID 0 is not a valid AID, so this mapping will not step on the management queue in tx_queues[1]).

nader wrote:

My second question is about dynamic buffer sizing. The 802.11 Reference Design limits the maximum size of any given user's queue to MAX_TX_QUEUE_LEN = 150 packets which is constant. In case we want to implement an algorithm of dynamic buffer sizing using a scheduler, how we can do it safely without affecting the design?

The number 150 is pretty arbitrary soft limit to avoid bufferbloat and can be safely changed even on a user-by-user basis. The harder limit on the number of total queue entries across all unicast, multicast, and management queues is 3413.

The MAX_TX_QUEUE_LEN definition gets turned into a runtime variable called "max_queue_size". That's the value that is checked prior to enqueueing anything. You can change that value with a scheduler or you can generalize that to a per-user array of queue sizes.

Offline

 

#3 2017-Jan-20 16:09:12

nader
Member
Registered: 2016-May-24
Posts: 22

Re: Detecting the broadcast queue

Thank you for your instructive reply. I have just another question regarding the scheduler. Can the scheduler call a function with arguments (I don't see this behavior in the code: the callback function is without arguments)? I need this because I have to maintain the algorithm variables for each queue and the callback in the scheduler should recognize which queue we are currently working with?

Offline

 

#4 2017-Jan-21 11:26:29

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Detecting the broadcast queue

It can't directly call a function with arguments, no. But there are a couple of ways around this:

A) If you don't want to modify framework code, you could exploit the fact that the return value of wlan_mac_schedule_event_repeated is an ID value that is provided as the single argument to your callback. Given this, you could rig up some global variables where your function could look up the arguments you would have provided to the callback directly. It's a little roundabout, but it would effectively give you the behavior you want.

B) A more formal solution would be to do the following:

     1) Add a "(void*)arguments" to the definition of the wlan_sched struct
     2) Add a "(void*)arguments" to the arguments of wlan_mac_schedule_event_repeated(). In that function you can then fill in the "arguments" element of the "wlan_sched" struct with the new argument.
     3) Finally, you could pass "curr_sched_ptr->arguments" to sched_callback as the second argument. There are many uses of the scheduler throughout the design that do not expect the second argument you just added, but I don't believe that would cause any problems.

Offline

 

Board footer