When an application is trying to send faster than the underlying network hardware can handle, outgoing frames will be generated (by kernel) and dropped (by drivers) unnecessarily.
To prevent frames from being generated while output is blocked, I will add an "output blocked" indicator flag inside the network drivers. Output generators such as the tcp_output function can check this flag before generating output frame(s).
Additionally, the network drivers will be updated to have a pending transmit frame queue, for a small amount of frames that arrive after the flag has been raised.
The driver will then independently transmit these frames as soon as a transmit descriptor(s) becomes available, before lowering the flag again.
My rationale behind putting the pending queue inside network drivers:
We are unable to resolve the issue at hand without updating network drivers, as they will currently relentlessly free any frames that arrive when the hardware is unable to accept more outgoing data.
The driver knows best when the hardware is (un)able to transmit more frames. A solution in kernel would just add more unnecessary overhead going back and forth between the two.
When an application is trying to send faster than the underlying network hardware can handle, outgoing frames will be generated (by kernel) and dropped (by drivers) unnecessarily.
1. To prevent frames from being generated while output is blocked, I will add an "output blocked" indicator flag inside the network drivers. Output generators such as the tcp_output function can check this flag before generating output frame(s).
2. Additionally, the network drivers will be updated to have a pending transmit frame queue, for a small amount of frames that arrive after the flag has been raised.
The driver will then independently transmit these frames as soon as a transmit descriptor(s) becomes available, before lowering the flag again.
My rationale behind putting the pending queue inside network drivers:
- We are unable to resolve the issue at hand without updating network drivers, as they will currently relentlessly free any frames that arrive when the hardware is unable to accept more outgoing data.
- The driver knows best when the hardware is (un)able to transmit more frames. A solution in kernel would just add more unnecessary overhead going back and forth between the two.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When an application is trying to send faster than the underlying network hardware can handle, outgoing frames will be generated (by kernel) and dropped (by drivers) unnecessarily.
To prevent frames from being generated while output is blocked, I will add an "output blocked" indicator flag inside the network drivers. Output generators such as the tcp_output function can check this flag before generating output frame(s).
Additionally, the network drivers will be updated to have a pending transmit frame queue, for a small amount of frames that arrive after the flag has been raised.
The driver will then independently transmit these frames as soon as a transmit descriptor(s) becomes available, before lowering the flag again.
My rationale behind putting the pending queue inside network drivers: