On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd <adr...@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

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

They look like,
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
    (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,
working_queue: empty
hardware_queue: 1--2 (the lock preserves the order)

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

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to