Add tx_provide to ethernet driver handle_irq

[Courtney3141]

This PR adds a call to to tx_provide() after tx_return() in the handle_irq() function in the ethernet drivers. This prevents against a potential deadlock (in the worst case) or delayed transmission (in the best case).

Since the HW rings are smaller than the number of transmit buffers in the system, the following trace of execution is problematic:

1. TX virt has HW_RING_SIZE + x buffers to transmit. It transfers the buffers into the driver's active queue. It then notifies the driver.

2. Driver transfers HW_RING_SIZE buffers into the HW ring, leaving x buffers remaining in its active ring.

3. Ethernet device transmits HW_RING_SIZE buffers, sends an IRQ to the driver.

4. Driver receives the IRQ, calls tx_return().

After this sequence of execution, the remaining x buffers do not necessarily get sent. Since the driver will not re-check the active ring unless notified again by the TX virtualiser, and the TX virtualiser believes that the driver is already aware of the remaining x buffers, so it will not notify the driver again unless the client happens to send another packet (in this case it will notify prompted by the transfer of the other packet into the active ring).

The fix in this PR stops this from occurring by forcing the driver to re-check the active ring each time packets have been re-transmitted.

Note that this PR is based off #252, and should be merged secondary to that.

[Ivan-Velickovic]

Can you also change the virtIO net driver to call rx_provide and tx_provide? I think that we can run into the same scenario you're describing in that driver as well.

[Courtney3141]

Yes, I can add it to that driver too - although I don't think rx_provide() is a necessity to avoid the above deadlock (I'll explain as I did above).

1. RX virt has HW_RING_SIZE + x free buffers to give to the driver. It transfers the buffers into the driver's free queue then notifies.

2. Driver transfers HW_RING_SIZE buffers into the HW ring, leaving x buffers remaining in its free ring.

3. Device receives HW_RING_SIZE packets, sends an IRQ to the driver.

4. Driver receives the IRQ, calls rx_return().

But this results in the RX virt transferring the packets to the client, which necessarily results in the client eventually returning the free buffers back to the RX virt, which ultimately results in the RX virt adding more buffers to the driver's free ring, and notifying the driver again. This notification then makes the driver aware of the x buffers still sitting in the free ring, as well as the newly added buffers.

The difference between these two scenarios is that in the TX case, the TX virtualiser does not necessarily send another "active buffers available" notification unless the client subsequently decides to sent another packet (an event that can't be depended on, especially if it believes it already sent a packet and hasn't received a reply).

Where as in the RX case, it is dependable behaviour for the client to return free RX buffers back to the virtualiser after they have been processed. In fact, RX virtualisers are assumed to be interfacing with copy components, which are trusted, and can therefore be depended upon to return free buffers which eventually triggers another "buffers available" notification to the driver.

So the reason I didn't add rx_provide() to the handle_irq() function in the meson driver is because it is not necessary to avoid deadlocks, and when I've tested in the past it doesn't seem to improve performance (it has always been in the IMX driver since before I started working on the code).

[Ivan-Velickovic]

Sure, makes sense.