You are not logged in.
Pages: 1
Hello,
I need to track the packet sojourn time in the Wireless Transmit Queue. For this purpose, I am thinking of modifying the structure "tx_frame_info_t" to add a field containing a timestamp and using "get_system_time_usec()" to update this timestamp with the actual queuing time in the "enqueue_after_tail" function of "wlan_mac_queue.c". Is it safe to add this field or there is a better way to get the packet sojourn time in the queue?
Offline
This functionality is already provided in the reference code. The TX_HIGH log entry contains three time fields:
* timestamp: this is the MAC time when the packet is enqueued
* time_to_accept: this is the time delta in microseconds between the timestamp (enqueue time) and when CPU Low accepts the packet as the next Tx packet
* time_to_done: this is the time delta in microseconds between the acceptance time and the completion of the Tx process
You can use the existing time_to_accept value to know how long a given packet spends in the Tx queue before being passed to the lower MAC.
Offline
Thank you for your help. However, I need to get the packet sojourn time, not for logging issues, but for implementing a buffer management algorithm inside "wlan_mac_queue.c". From your reply, I understand that the MAC timestamp of packet creation "timestamp_create" in the structure "tx_frame_info_t" represents the queuing time of the packet.
Offline
The TX_HIGH log entry uses data from the tx_frame_info_t struct. The TX_HIGH.timestamp field uses the tx_frame_info.timestampe_create field (implemented in wlan_mac_entries.c). Your C code can refer to the tx_frame_info.timestampe_create and compare it to the current MAC time to calculate how long any packet has been in its queue.
Offline
Thank you for this clarification. I appreciate your help. I just have two more questions considering the Tx Queue:
1. In "wlan_mac_queue.c", I don't see any function that drops a specific packet from the queue. There is only "purge_queue" function that drops all packets. Is there any functionality or a function to do so? In fact, I need this functionality to implement my algorithm of buffer management.
2. Usually, in WiFi commercial devices, the queuing policy is DropTail, which means when the queue is filled to its maximum capacity, the newly arriving packets are dropped until the queue has enough room to accept incoming traffic. For WARPv3, is it the same? What happens when we don't have enough space in the buffer?
Offline
nader wrote:
1. In "wlan_mac_queue.c", I don't see any function that drops a specific packet from the queue. There is only "purge_queue" function that drops all packets. Is there any functionality or a function to do so? In fact, I need this functionality to implement my algorithm of buffer management.
We didn't write a specific function to drop an element from the queue because doing so is just a normal doubly-linked list operation with dl_entry_remove(). Once you have the dl_entry* for the particular packet you want to drop, you can just remove it from its queue's dl_list and add it to the "free" dl_list so it can be used for a new packet in the future.
As a concrete example, look at these two lines in purge_queue(). All purge_queue() does is loop over every entry and dequeue each followed by a call to queue_checkin() to move it back into the free pool. If you have a particular packet you want to remove, you can write something similar to dequeue_from_head using the atomic dl_list operations.
nader wrote:
2. Usually, in WiFi commercial devices, the queuing policy is DropTail, which means when the queue is filled to its maximum capacity, the newly arriving packets are dropped until the queue has enough room to accept incoming traffic. For WARPv3, is it the same? What happens when we don't have enough space in the buffer?
Yes, the default implementation implements the same behavior. Our implementation actually artificially limits the size of the queue to avoid bufferbloat. Each queue to a particular STA (or the multicast or management queues) is limited by MAX_TX_QUEUE_LEN (which is 150 packets in the default design). In reality, the overall limit is defined by how many dl_entry structs we can fit in the 40kB of AUX BRAM that we've set aside for this. That number is 3413 packets (each dl_entry is 12 bytes). So, long story short, if you don't care about bufferbloat, you can raise MAX_TX_QUEUE_LEN up to 3413 for a single queue. But also keep in mind that the AP has multiple queues that all draw from that same 3413. If there are 10 associated STAs, then there can be up to 10*MAX_TX_QUEUE_LEN packets being queued in addition to another MAX_TX_QUEUE_LEN for the mcast queue and MAX_TX_QUEUE_LEN for the management queue.
Offline
Pages: 1