[RFT] net80211 TX serialisation, take #4

[PseudoCylon]

On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> The trouble with using a queue is that things will dequeue frames out
> of order, bceause multiple dequeue contexts (ie, each call to
> driver_start / driver_transmit) will execute in-parallel.

Actually, to prevent that, there is an extra queue.

To begin
driver_queue:packet1--packet2--3--4--...
working_queue:empty
hadware_queue:empty


After multiple thread dequeue
lock dequeue enqueue unlock
lock dequeue enqueue unlock

They look like,
driver_queue:2--3--4--...
working_queue:1--2 (the lock preserves the order)
hardware_queue: empty


If a thread has packet #1 finished first, there is no problem.

If a thread has packet #2 finished first, it will try to dequeue the
packet #1 (head of the queue) from the working_queue. But the packet
isn't marked as "completed", so it will just return.

Queue still look like
driver_queue:2--3--4--...
    (of course, other threads are processing remaining packets,
    but to simplify, no change in driver_queue.)
working_queue: 1--2
hardware: empty


Later, once the thread with #1 finished processing, it will
lock while (completed) {dequeue enqueue} unlock

At the end, queue look like,
driver_queue:2--3--4--...
working_queue: empty
hardware_queue: 1--2 (the lock preserves the order)


Just wanted to clarify. I will soon test the latest txlock patch.


AK