The router test has buffer-bloat issues, and can't be run with the minimal number of buffers required to operate the VirtioNet driver (and the networking stack, in general), because it buffers on the transmit side of the networking stack its routing to.
The minimal number of buffers currently for VirtioNet is 256, which is only 0.5mb on heap. This works well for all normal servers and performance tests.
Of course, routers actually do have quite large buffers normally, but it shouldn't be required that the OS uses eg. 32mb buffers just to also accommodate high-speed routing.
That means we either need to solve the buffer-bloat issue, or have a way to re-allocate (resize) bufferstores during construction (which shouldn't be too hard, but doesn't solve the problem) or ... other solutions.
GCE uses much more buffers than normal, probably for this reason, but we can avoid it by making it possible to create, for example, a custom bufferstore and tell the stack to use that instead.
This is because old packets in flight does still need to return to the old bufferstore, so we have to be careful not to replace the old one with a new one, and instead just use a pointer to select another bufferstore for all future buffers.
Alternatively, we can replace the current bufferstore if we do it during the construction of the networking stack.
https://en.wikipedia.org/wiki/Bufferbloat
The router test has buffer-bloat issues, and can't be run with the minimal number of buffers required to operate the VirtioNet driver (and the networking stack, in general), because it buffers on the transmit side of the networking stack its routing to.
The minimal number of buffers currently for VirtioNet is 256, which is only 0.5mb on heap. This works well for all normal servers and performance tests.
Of course, routers actually do have quite large buffers normally, but it shouldn't be required that the OS uses eg. 32mb buffers just to also accommodate high-speed routing.
That means we either need to solve the buffer-bloat issue, or have a way to re-allocate (resize) bufferstores during construction (which shouldn't be too hard, but doesn't solve the problem) or ... other solutions.
GCE uses much more buffers than normal, probably for this reason, but we can avoid it by making it possible to create, for example, a custom bufferstore and tell the stack to use that instead.
This is because old packets in flight does still need to return to the old bufferstore, so we have to be careful not to replace the old one with a new one, and instead just use a pointer to select another bufferstore for all future buffers.
Alternatively, we can replace the current bufferstore if we do it during the construction of the networking stack.
https://en.wikipedia.org/wiki/Bufferbloat