Closed guessaname closed 2 years ago
Glad to see this in-depth question.
Actually this is our design choice: the queue 0 can stop ongoing retransmission of other queue. Because we think that those traffic that is schedule into queue 0 by Linux are very high priority and critical, so we don’t want to delay them a lot. Scarify some reliability of those traffic in other queue, because they are not that critical/prioritized.
Above is our understanding and design choice. In a real WiFi chip there are lots of details like this. Of course you can try to change this according to your need.
Thanks for your reply.
One more question. How can we know it is the retransmission of other queues rather than queue 0 itself? We cannot tell from it with this condition “retrans_in_progress==1“ per my understanding.
Thanks.
Associate with each packet from driver to FPGA, there is a parameter called queue_idx. (and also sequence number, etc.). You can identify the packet being re-transmitted is from which queue.
Thank you so much for your detail explaination. It really helped me.
You are welcome.
Dear Xianjun,
I have a question on the design of the retransmission in module "xpu" and "tx_intf”. We see the former retransmission can be stopped with another new transmission in queue 0, while other queues cannot be. What's the case for this? And why new transmission can go only when it's not in retransmission state for other queues (1,2,3) ??
Thanks. Lei