Strategies for writing top/bottom half NIC interrupt handlers

[ghaerr]

Pursuant to the discussion in ELKS ghaerr/elks#2506 (comment), I thought to discuss some ideas I've had about rewriting the NIC drivers for maximum performance, while keeping interruptions to other device drivers at a minimum.

The first concept I'm thinking would be to use two (new) bottom half handlers - NETRX_BH and NETTX_BH. when marked with mark_bh, these would run the bottom half receive or transmit handler registered by the individual driver from the init_bh call at init time. In this way, separate paths would be run for RX vs TX handling. (And some NICs don't use TX interrupts, right?)

As an example of how this might work, consider the current WD interrupt handler:

static void wd_int(int irq, struct pt_regs * regs)
{
    word_t stat;

    outb(0, WD_8390_PORT + EN0_IMR);/* Block interrupts,
                     * should not be required since the IRQ line
                     * is held high until all unmasked bits have
                     * been cleared. This is experimental.
                     */
    while (1) {
        stat = inb(WD_8390_PORT + EN0_ISR);
        //printk("/%02x;", stat&0xff);
        if (!(stat & ENISR_ALL))
            break;
        if (stat & ENISR_OFLOW) {
            printk(EMSG_OFLOW, dev_name, stat, netif_stat.oflow_keep);
            wd_clr_oflow(netif_stat.oflow_keep);
            netif_stat.oflow_errors++;
            continue; /* Everything has been reset, skip rest of the loop */
        }
        if (stat & ENISR_RX) {
            wake_up(&rxwait);
            outb(ENISR_RX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX) {
            wake_up(&txwait);
            //inb(WD_8390_PORT + EN0_TSR);  /* should be read every time */
            outb(ENISR_TX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_RX_ERR) {
            printk(EMSG_RXERR, dev_name, inb(WD_8390_PORT + EN0_RSR));
            netif_stat.rx_errors++;
            outb(ENISR_RX_ERR, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX_ERR) {
            netif_stat.tx_errors++;
            printk(EMSG_TXERR, dev_name, inb(WD_8390_PORT + EN0_TSR));
            outb(ENISR_TX_ERR, WD_8390_PORT + EN0_ISR);
        }
        if (stat & (ENISR_RDC|ENISR_COUNTERS)) {  /* Remaining bits - should not happen */
            // FIXME: Need to add handling of the statistics registers
            // On 8216 cards, the RDC bit is set with every RX interrupt
            // even when the RDC interrupt has been masked.
            //printk("eth: RDC/Stat error, status 0x%x\n", stat);
            outb(ENISR_RDC|ENISR_COUNTERS, WD_8390_PORT + EN0_ISR);
        }
    }
    outb(ENISR_ALL, WD_8390_PORT + EN0_IMR);

}

This could be rewritten as:

static word_t stat; // save across top/bottom half execution

static void wd_int(int irq, struct pt_regs * regs)
{
    //outb(0, WD_8390_PORT + EN0_IMR); // Don't block interrupts, should not be needed

        stat = inb(WD_8390_PORT + EN0_ISR);
        if (stat & (ENISR_RX|ENISR_RX_ERR|ENISR_OFLOW) {
            mark_bh(NETRX_BH);
            //does this re-enable RX interrupts? If so, move it to bottom half
            //outb(ENISR_RX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX) {
            mark_bh(NETTX_BH);
            //does this re-enable TX interrupts? If so, move it to bottom half
            //outb(ENISR_TX, WD_8390_PORT + EN0_ISR);
        }
    //outb(ENISR_ALL, WD_8390_PORT + EN0_IMR); // should not be needed
}

The PIC prevents another NIC interrupt while the top half is running. If the NIC itself might interrupt again outside the top-half, before the bottom half executes, then separate rxstat and txstat variables are probably required. In general, anything that might change in the NIC controller register between the top and bottom half handlers will have to be saved by the top half. Ideally a structure is used so that the driver doesn't have tons of global variables.

If both an RX and TX PIC interrupt occur during kernel code execution, then both would run before either 1) returning to user mode from any interrupt, or 2) in the next call to schedule(), which occurs continuously if the idle task is running. If the interrupt occurred during kernel code execution, including during a bottom half execution, execution will be delayed until the kernel finally finishes up and returns to user mode via 1) above.

It doesn't appear that the WD driver disables interrupts while reading NIC data, unlike the NE2K and EL3 drivers. Is that because the WD has special hardware allowing for such operation, do the NE2K/EL3 drivers actually need interrupts disabled?

[ghaerr]

Regarding kernel code execution and handlers, another thing to be aware of regarding critical sections and/or the need to disable interrupts, is:

• If the system is executing any kernel code, it may be interrupted at any time by a top half handler, but will never be interrupted by a bottom half handler.

That is, if for instance the kernel is in the middle of executing a NIC read entry point, an RX or TX interrupt could interrupt it (as is the case prior). However, on return from that PIC interrupt, any and all interrupted kernel code will continue execution to completion, prior to do_bottom_half being called by _irqit or schedule. That's also the case for the bottom half handlers themselves - they will always run to completion prior to any other kernel code running (except for top half handlers, of course).

Of course, even a top half handler can be interrupted by a higher priority PIC hardware interrupt. In the cases where multiple interrupts are stacked, each top half handler runs to completion (from the highest to lowest priority, naturally), then any interrupted non-handler kernel code is resumed, then the bottom half handlers run, then either the idle task or the (current or next scheduled) application is resumed.

The kernel has always been protected from being reentered - so IMO the interrupt disabling in some of the NIC drivers isn't required, unless there would be interference from a hardware interrupt. That hasn't changed. But now with bottom half handlers, the device driver writer can be assured that code moved out of an old (or top half) handler to a bottom half won't ever run before the previous kernel code (read in this case) finishes running.

I don't understand NIC chips well enough to understand the whole situation, but it would seem to me that almost all of the current interrupt disabling should be able to be removed. And of course, should disabling be required, that would be found out rather quickly in one of your "long" networking testing suites you run.

[Mellvik]

Thanks for opening this issue, @ghaerr.
I suspect this is going to be a long and interesting one!

Pursuant to the discussion in ELKS ghaerr/elks#2506 (comment), I thought to discuss some ideas I've had about rewriting the NIC drivers for maximum performance, while keeping interruptions to other device drivers at a minimum.

The first concept I'm thinking would be to use two (new) bottom half handlers - NETRX_BH and NETTX_BH. when marked with mark_bh, these would run the bottom half receive or transmit handler registered by the individual driver from the init_bh call at init time. In this way, separate paths would be run for RX vs TX handling. (And some NICs don't use TX interrupts, right?)

If I've understood things (TH/BH things that is) correctly this far, the registration (and maybe reregistration) of the handlers will have to be in _open/_close unless we create different entries per driver, in order to preserve the capability to switch between ethernet interfaces on a live system. (All NICs use TX interrupts.)

As an example of how this might work, consider the current WD interrupt handler:

static void wd_int(int irq, struct pt_regs * regs)
{
    word_t stat;

    outb(0, WD_8390_PORT + EN0_IMR);/* Block interrupts,
                     * should not be required since the IRQ line
                     * is held high until all unmasked bits have
                     * been cleared. This is experimental.
                     */
    while (1) {
        stat = inb(WD_8390_PORT + EN0_ISR);
        //printk("/%02x;", stat&0xff);
        if (!(stat & ENISR_ALL))
            break;
        if (stat & ENISR_OFLOW) {
            printk(EMSG_OFLOW, dev_name, stat, netif_stat.oflow_keep);
            wd_clr_oflow(netif_stat.oflow_keep);
            netif_stat.oflow_errors++;
            continue; /* Everything has been reset, skip rest of the loop */
        }
        if (stat & ENISR_RX) {
            wake_up(&rxwait);
            outb(ENISR_RX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX) {
            wake_up(&txwait);
            //inb(WD_8390_PORT + EN0_TSR);  /* should be read every time */
            outb(ENISR_TX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_RX_ERR) {
            printk(EMSG_RXERR, dev_name, inb(WD_8390_PORT + EN0_RSR));
            netif_stat.rx_errors++;
            outb(ENISR_RX_ERR, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX_ERR) {
            netif_stat.tx_errors++;
            printk(EMSG_TXERR, dev_name, inb(WD_8390_PORT + EN0_TSR));
            outb(ENISR_TX_ERR, WD_8390_PORT + EN0_ISR);
        }
        if (stat & (ENISR_RDC|ENISR_COUNTERS)) {  /* Remaining bits - should not happen */
            // FIXME: Need to add handling of the statistics registers
            // On 8216 cards, the RDC bit is set with every RX interrupt
            // even when the RDC interrupt has been masked.
            //printk("eth: RDC/Stat error, status 0x%x\n", stat);
            outb(ENISR_RDC|ENISR_COUNTERS, WD_8390_PORT + EN0_ISR);
        }
    }
    outb(ENISR_ALL, WD_8390_PORT + EN0_IMR);

}

This could be rewritten as:

static word_t stat; // save across top/bottom half execution

static void wd_int(int irq, struct pt_regs * regs)
{
    //outb(0, WD_8390_PORT + EN0_IMR); // Don't block interrupts, should not be needed

        stat = inb(WD_8390_PORT + EN0_ISR);
        if (stat & (ENISR_RX|ENISR_RX_ERR|ENISR_OFLOW) {
            mark_bh(NETRX_BH);
            //does this re-enable RX interrupts? If so, move it to bottom half
            //outb(ENISR_RX, WD_8390_PORT + EN0_ISR);
        }
        if (stat & ENISR_TX) {
            mark_bh(NETTX_BH);
            //does this re-enable TX interrupts? If so, move it to bottom half
            //outb(ENISR_TX, WD_8390_PORT + EN0_ISR);
        }
    //outb(ENISR_ALL, WD_8390_PORT + EN0_IMR); // should not be needed
}

The PIC prevents another NIC interrupt while the top half is running. If the NIC itself might interrupt again outside the top-half, before the bottom half executes, then separate rxstat and txstat variables are probably required. In general, anything that might change in the NIC controller register between the top and bottom half handlers will have to be saved by the top half. Ideally a structure is used so that the driver doesn't have tons of global variables.

If both an RX and TX PIC interrupt occur during kernel code execution, then both would run before either 1) returning to user mode from any interrupt, or 2) in the next call to schedule(), which occurs continuously if the idle task is running. If the interrupt occurred during kernel code execution, including during a bottom half execution, execution will be delayed until the kernel finally finishes up and returns to user mode via 1) above.

It doesn't appear that the WD driver disables interrupts while reading NIC data, unlike the NE2K and EL3 drivers. Is that because the WD has special hardware allowing for such operation, do the NE2K/EL3 drivers actually need interrupts disabled?

I generally agree with this, @ghaerr, bit I don't see the point in splitting RX and TX. In fact I think that is creating a problem, because the BH interrupt handler must loop until all interrupts have been serviced. This means handling 'interrupts' (or events rather) occurring while processing in the loop. Events rather than interrupts because they are not (and should not be) registered by the PIC, but set the corresponding bit in the ISR.

Am I making sense here?

What I'm noticing working on the WD driver - in lieu of the new understanding/thinking about interrupts in the system, is that the overall flow is much clearer. This is a very good thing. I believe we will come out of this endeavour with a significantly cleaned up system.

[Mellvik]

Regarding kernel code execution and handlers, another thing to be aware of regarding critical sections and/or the need to disable interrupts, is:

• If the system is executing any kernel code, it may be interrupted at any time by a top half handler, but will never be interrupted by a bottom half handler.

That is, if for instance the kernel is in the middle of executing a NIC read entry point, an RX or TX interrupt could interrupt it (as is the case prior). However, on return from that PIC interrupt, any and all interrupted kernel code will continue execution to completion, prior to do_bottom_half being called by _irqit or schedule. That's also the case for the bottom half handlers themselves - they will always run to completion prior to any other kernel code running (except for top half handlers, of course).

Of course, even a top half handler can be interrupted by a higher priority PIC hardware interrupt. In the cases where multiple interrupts are stacked, each top half handler runs to completion (from the highest to lowest priority, naturally), then any interrupted non-handler kernel code is resumed, then the bottom half handlers run, then either the idle task or the (current or next scheduled) application is resumed.

I'm following you on this, @ghaerr, and I think this should be fine. All NICs except one have buffers and thus no real time requirements. There exception is the Lance NIC, which DMAs data directly to/from main memory, and MUST be handled with the same attention as serial IO - with a small FIFO. We'll attend to that when we get there.

The kernel has always been protected from being reentered - so IMO the interrupt disabling in some of the NIC drivers isn't required, unless there would be interference from a hardware interrupt. That hasn't changed. But now with bottom half handlers, the device driver writer can be assured that code moved out of an old (or top half) handler to a bottom half won't ever run before the previous kernel code (read in this case) finishes running.

I agree on this and like I've observed a couple of times recently, I think we're going to find a number of protected areas that don't really need protection. In many drivers, including disk and floppy. That said, I just cane across a section, just a few instructions, in the WD driver that seem to need clr_irq/set_irq still. The wd_rx_stat() function accesses 8390 data that may be in the middle of being updated. I need to think through this one again to see if there is a better way of doing what we're doing. There usually is.

I don't understand NIC chips well enough to understand the whole situation, but it would seem to me that almost all of the current interrupt disabling should be able to be removed. And of course, should disabling be required, that would be found out rather quickly in one of your "long" networking testing suites you run.

Yes. They are very different and a lot of careful 'threading' is necessary to get it right. Hardware is fun. I'm rather looking forward to it. Energy permitting.

[ghaerr]

I don't see the point in splitting RX and TX. In fact I think that is creating a problem, because the BH interrupt handler must loop until all interrupts have been serviced.

Am I making sense here?

Yes. I wasn't aware that the interrupt handler has to loop until all bits are serviced. So - a single NET_BH sounds much better!

in lieu of the new understanding/thinking about interrupts in the system, is that the overall flow is much clearer. This is a very good thing.

Great news! After reviewing the NIC drivers myself and seeing lots of embedded complexity, agreed that rewriting some of the NIC drivers for simplicity is probably a good idea, and shouldn't be too much an effort, hopefully.

I just cane across a section, just a few instructions, in the WD driver that seem to need clr_irq/set_irq still. The wd_rx_stat() function accesses 8390 data that may be in the middle of being updated.

Agreed that anything that is touched by a top half handler needs to be carefully considered. But disabling interrupts around a small section really isn't a big deal, a much larger concern is the very long DMA read/write loop occurring with interrupts disabled, which shouldn't be required with a more comprehensible flow combined with bottom half handlers.

With regards to the business of actually getting the drivers rewritten - I found when updating the timer interrupt, in general just block cut and pasting code from top half to bottom half worked quite well, and removed any problems of having to rewrite a lot of code requiring lots of testing. If the code is literally copied to a new routine en mass, it becomes a bit more like a top-level refactoring than re-engineering. With the bottom half guaranteed not to be interrupted by another bottom half, and the top half not doing much other than looking at a few status bits, the change should be pretty straightforward.

[ghaerr]

I found when updating the timer interrupt,

Actually now that I think of it, when "rewriting" the timer interrupt routine, I started by renaming irq_timer (top half) to timer_bh, then just moved a very ew statements out, "up" into the original irq_timer routine. In that way, very little control flow changed, leaving little to worry about for major testing. The system would either work well, or not at all.

All the timer top half does now is increment jiffies, then mark_bh(TIMER_BH). The net effect was almost no code changed, but almost all the timer "interrupt" code now executed outside of PIC pre-EOI time, thus removing most critical section worries.

I am thinking you might be able to do exactly the same thing for the NIC drivers, which would provide an immediately working NIC driver using bottom halves, and then more slowly strip out protections and/or rewrite sections, with the driver fully operational. This reminds me of the old software saying that it's so much easier to see the success of a medical operation by operating while the patient is still alive.

[Mellvik]

@ghaerr, it's useful to let things sink in for a while.

I find this discussion both interesting and useful as it forces new angles on old problems here and there, maybe more often than not. Anyway - here are some thoughts related (mostly) to moving the NIC drivers over to the new interrupt regime:

• Given the observation I made above, most NICs have buffers and thus no real time handling requirements, the 'old style' (which applies to all 3 ELKS NIC drivers) drivers may be used with the new regime pretty much as is. I'm not arguing against rewriting or cleanups etc., just pointing out the facts.
  • The ISR only needs to clear the NIC's interrupt mask, then mark_bh() and return, IOW let the BH do all the work
  • Clearing the IMR is important because we don't want the NIC to field another interrupt until the BH is done.
  • About the loop in the ISR: As you know the loop is (in mose cases) a big case sequence to handle each possible interrupt reason (each bit in the Interrupt Service Register) in turn. It then loops back to check whether new events have occurred by reading the Service Register again, which happens rarely except under heavy load.
  • How this works is slightly different from one NIC to the next but conceptually the same.
• The Lance has no buffer and uses DMA (even a MFM disk has a sector buffer) so the Lance is more like the floppy driver, it has real time requirements. That said, there is still very little that has to be done in the TH of the driver. Only reads are critical and all that needs to be done in TH is to set up the DMA channel and let go (off the top of my head). The rest is BH stuff. BTW, I have intentionally (and for now) avoided XT-class 8bit ISA support in the Lance which means that CPU performance should not complicate things. At some point, running floppy, Lance and MFM disk, all using DMA, may be an interesting experiment, in particular on a 4.77MHz system. It should work ...
• Introducing NIC level buffering changes the picture in that the amount of work done in the BH part per interrupt is higher since the ISR actually moves data. It also makes the boundaries cleaner: Kernel I/O deals with buffers instead of going all the way down to the hardware, which at times requires 'protection' or 'synchronization'. Since the TLVC ne driver already has this, we'll soon see how this works out in practice.
• Overall, there are very few cases in the 'NIC section' which require interrupt protection. DMA channel setup (Lance only) is an obvious one. The one from the wd driver mentioned earlier in this thread is about to go, replaced by a global status variable like the one used in the ne driver for exactly the same purpose. What we're left with is primarily the sections where the ISR and the kernel read/writes touch the same registers/pointers in a NIC, like the buffer pointers in the 8390 based units. With NIC buffering even these are history.

IOW - I think we're looking at a step by step process, and one I'm very much looking forward to.

[ghaerr]

Glad you're having fun thinking about these things in a new light, hopefully that can allow you see what code really needs to execute at exactly what points in time, and use that to simplify the entire NIC code base. When realizing how things best fit, I try to encapsulate pieces using (new) functions, which can then both mirror the execution of top/bottom/axillary code fragments, and provide better top-down clarity as to driver function.

For instance, the dma_read etc functions are really just fmemcpy-like functions that use I/O ports instead. Having a set of these named fiocpyw, fiocpyb, iocpyw, iocpyb, etc would really help get rid of a lot of the ASM routines which are hard to follow and potentially bug-prone. Then, the NIC driver read/write routines start looking more like regular character device routines, for example.

Speaking of details buried in ASM, I noticed a few things while researching dma_read for this post (in nek2-asm.S). First, the routine tries to handle both bytes and words - this could be moved to a single C routine fiocpy, which then calls the appropriate fiocbpyw or fiocpyb in ASM, just like the fmemcpy kernel routine does. This keeps things simpler to understand, and should be able to be shared by all NIC drivers, rather than writing special ASM ones for each. The driver 8/16-bit setting then controls which of the two routines to call, rather than a global buried in an ASM routine.

The second thing I noticed in dma_read is that there's code to fast buzz-loop doing nothing (in check_dma_r), waiting for a NIC controller flag to indicate finished. Does the NIC hardware actually require that a driver buzz-loop in either a top or bottom half handler? It would seem to me that's another design aspect for consideration here. What we want is for the hardware to tell us when something is completed, and then schedule another function to handle it. In this case, if the hardware actually has to be polled, a kernel timer can be scheduled to callback a driver function, which can then wakeup a task or schedule a bottom half for continued execution. All of this is a lot harder to do from ASM than from C.

I think we're looking at a step by step process

Definitely agree. Lots of small steps and multiple commits keeps the patient alive during major surgery!

[Mellvik]

@ghaerr,
I just read through the ne2k asm code, there is definitely a number of things to improve/remove/clean up. There are certainly functions that with slight adjustments may be shared among drivers. the asm routines for the ee16 and the el3 drivers are identical and could easily be used by the ne2k driver too (port-to-memory, memory-to-port). This is a great opportunity to get this off the fix list. It may be a good idea to create library insw/insb/outsw/outsb routines and share them with the IDE driver. For all I know, you may already have that in ELKS.

The second thing I noticed in dma_read is that there's code to fast buzz-loop doing nothing (in check_dma_r), waiting for a NIC controller flag to indicate finished. Does the NIC hardware actually require that a driver buzz-loop in either a top or bottom half handler? It would seem to me that's another design aspect for consideration here.

Good point, it's actually much simpler than that. This loop can likely just be removed. This is PIO, so when the loop is finished, we're done and ready to continue. Unless the CPU is very fast, the Remote DMA Complete bit in the ISregister will be set immediately and there is no looping. On a fast cpu, the loop may run a few times to give the 8390 time to do whatever housekeeping necessary. My guess is that no one will notice its absence. Big Linux simply resets the RDC bit in the ISR after finishing the PIO loop. I'll comment it out and test on my fastest machine when I get there.

[ghaerr]

@Mellvik, you might be interested in my latest deep dive: an additional task for "free", moving the idle task out of the task array in ghaerr/elks#2531. After this work and adding bottom half handling, I'm seeing kernel startup, interrupts and task switching in ways I hadn't ever fully realized!

[ghaerr]

@Mellvik
I wanted to alert you to a new finding ghaerr/elks#2533 with regards to bottom half handler execution.

It's a bit complicated to fully explain, but bottom half handlers are usually not executed directly after their top half hardware interrupt. Instead, they're executed only after any previously interrupted kernel code is fully completed. Some testing with the system under heavy load showed the timer bottom half being delayed from 20-80ms (2-8 timer ticks) while other processes were running.

Because of this, I started thinking that this could be a disaster for NIC drivers, since that kind of delay could slow down network speeds tremendously, not to mention possibly getting packet reception overruns, etc. So, in ghaerr/elks#2534 I implemented "high priority" BH handlers which will run immediately after the interrupt stack is unwound, effectively no delay unless other top-halves are already executing, after which the BH handler will always run.

There may be more restrictions on exactly what routines can be called from a high priority BH handler, as it essentially runs like a top half interrupt handler, but after the PIC EOI. Certainly wake_up can be called, however.

Bottom line is we will both need to experiment and see what is required for max system throughput, with both options easily exercised merely by setting a high-priority mask bit for the handler. The good news is that moving to bottom half NIC handlers will always free up opportunities for other device drivers to run without their priority being restricted by their PIC-controlled IRQ number, regardless.

Basically, the entire system is being opened up to more possibilities, just like it was when the direct DF driver was first developed to run as an asynchronous device driver, and not allowing block I/O to stop other user or kernel processes from running. I'm looking forward to seeing what is possible with the interrupt system now evolving in the same fashion!

[Mellvik]

Again very interesting thoughts (and numbers) @ghaerr. My immediate thought is that the priority mechanism you're suggesting is a good thing, possibly necessary. In my head,that becomes something akin to my first and very simplistic thoughts about how to handle this challenge: to let the driver issue an EOI when the critical stuff was completed and then continue to completion.

What you have now is an order of magnitude more sophisticated and flexible, and - like you point out - invites to creativity instead of locking us up in historical structures.

As to NIC performance, my first thought was that it doesn't matter - but it does, even for the traditional (unbuffered) drivers, and only because of wake_up(). So unless there is some magic trick that can make wakeup less of a 'burden', all asynch drivers really need your 'high-priority-BH'.

Again I'm very much looking forward to start testing NICs (and the system in general) with the new TH/BH regime. Like you said - possibly in a different thread - likely the most significant ll-OS change in a loong time. It changes not functionality but behavior.

[Mellvik]

Thanks for sharing, @ghaerr - very interesting indeed.

@Mellvik, you might be interested in my latest deep dive: an additional task for "free", moving the idle task out of the task array in ghaerr/elks#2531. After this work and adding bottom half handling, I'm seeing kernel startup, interrupts and task switching in ways I hadn't ever fully realized!

Fascinating simplicity - there is much to like about this in addition to the freed-up task slot! Great work.

[ghaerr]

Thanks for your comments @Mellvik.

let the driver issue an EOI when the critical stuff was completed and then continue to completion.

After much testing and further experimentation, I came to the same conclusion. I pushed a commit in ghaerr/elks#2534 that effectively makes all bottom half handlers "high priority", meaning all marked bottom halves will be executed immediately after hardware PIC top half interrupts are completed, before returning from the original interrupt. This guarantees the fastest possible processing, and device drivers don't have to be concerned with multiple types of bottom half handlers.

We still get the benefit of allowing the ordering of bottom half handlers to be prioritized separately from the hardware PIC's IRQ ordering. I've already put NETIRQ_BH as higher priority than TIMER_BH, which means network packet processing will take precedence calculating process CPU times, for instance.