WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2017-Feb-11 06:22:34

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

Enqueue routine in "wlan_mac_ap.c"

Hi,

In "wlan_mac_ap.c" file, I am confused about which function actually do the enqueue routine of the packets ("ethernet_receive" or "ltg_event" or "mpdu_rx_process") and which function do the dequeue routine of packets ("poll_tx_queues" or "mpdu_dequeue").

Moreover, if I want to drop a packet in the enqueue process (put some conditions in the enqueue process -> Ex: if(condition) {ENQUEUE PACKET} else {DROP PACKET}), is it safe to change the "enqueue_after_tail" function in "wlan_mac_queue.c"? or it is better to work directly in "wlan_mac_ap.c" functions that do the enqueue routine? In fact, the "enqueue_after_tail" function does not return a flag indicating the success or the failure of the enqueue routine. That means it assume that the packet is actually enqueued after its execution.

Thank you.

Offline

 

#2 2017-Feb-13 09:46:14

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

Re: Enqueue routine in "wlan_mac_ap.c"

nader wrote:

In "wlan_mac_ap.c" file, I am confused about which function actually do the enqueue routine of the packets ("ethernet_receive" or "ltg_event" or "mpdu_rx_process") and which function do the dequeue routine of packets ("poll_tx_queues" or "mpdu_dequeue").

There are many places throughout the codebase that call the enqueue function because there are many entry points into the queue (e.g. an Ethernet reception, an LTG event, a wireless reception like a probe request that requires the transmission of a probe response). Any call to "enqueue_after_tail()" in wlan_mac_ap.c is a context that enques a packet.

"poll_tx_queues()" is the beginning of the dequeue operation. This is where the AP implements the round-robin dequeuing procedure. It alternates between Management and Data frames. Within the class of Data frames, it steps through each user to try to give each fair access to the AP's transmit resources. "mpdu_dequeue()" is near the end of the dequeue operation. This is a callback that the framework executes just prior to giving the frame to CPU_LOW for transmission. It may seem a little circular to bounce back into the AP application at this step, but it's important to let the application have a final chance to modify anything about the packet before it gets passed off to the low-level MAC. The AP uses this context for two independent operations:

(1) If looks back into the queue and sets the MAC_FRAME_CTRL2_FLAG_MORE_DATA bit in the second frame control byte if there are additional packets in the queue. This is important for STAs that implement power savings support. This information can only be known at the time of dequeue.
(2) It determines whether or not the low-level MAC should treat the frame as a "general" transmission that follows the typical unicast DCF rules or whether it should be treated as a special "DTIM multicast" packet that has unique channel access rules. Some initial documentation for this behavior is available here.

nader wrote:

Moreover, if I want to drop a packet in the enqueue process (put some conditions in the enqueue process -> Ex: if(condition) {ENQUEUE PACKET} else {DROP PACKET}), is it safe to change the "enqueue_after_tail" function in "wlan_mac_queue.c"? or it is better to work directly in "wlan_mac_ap.c" functions that do the enqueue routine? In fact, the "enqueue_after_tail" function does not return a flag indicating the success or the failure of the enqueue routine. That means it assume that the packet is actually enqueued after its execution.

It sounds like this is definitely better suited for the application ("wlan_mac_ap.c") rather than the framework's enqueue function. The AP will have full access to whatever it needs to know before deciding to enqueue or not. If it doesn't want to enqueue the packet, then it should just not call "enqueue_after_tail()". Plus, that has the added benefit of not influencing the other applications' use of the framework (i.e. STA & IBSS).

Offline

 

#3 2017-Feb-14 14:14:23

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

Re: Enqueue routine in "wlan_mac_ap.c"

Thank you for your clarifications.

Offline

 

Board footer