In the device driver I am writing I am not getting the performance I am expecting.

in short:
1. get a request.
2. setting up the hardware.
3. "kick" the hardware and wait for it to complete.
4. return "-EINPROGRESS" to caller.

Hardware IRQ.
Top Half:
1. clear and disable interrupt.
2. schedule taste
3. IRQ_HANDLED

Bottom Half (tasklet):
1. check hardware for completed packets.
2. read output from buffer and clear hardware.
3. if full request was processed signal completed to caller
4. check if more requests are pending.
5. if more requests are pending...

I think the problem is in the last step:
I tried:
a) re-enable interrupt and return (cycle starts again after IRQ)
b) re-schedule tasklet and return (saves time to process IRQ)
c) "loop" inside tasklet (no return).

Nothing in the kernel code should ever be waiting for anything. It should all be event-driven.

Top half should process all of the hardware pending requests, queue anything that needs to be handled more slowly, and leave with the interrupts enabled so more hardware requests can arrive. Bottom half should complete anything on the queue that couldn't be handled quickly in the top half. If you are leaving interrupts disabled until the bottom half runs, then the design has a problem, because the bottom half should be running outside of the interrupt context.