On 07/30/16 01:09, Alexander Bluhm wrote: > On Fri, Jul 29, 2016 at 06:46:52PM -0400, Ted Unangst wrote: >> Alexander Bluhm wrote: >>> + /* Avoid user land starvation. */ >>> + yield(); >> >> you don't need to yield here, the task framework should do that for you. > > Perhaps the framework should do that, but it does not. When I run > my splicing test on a qemu virtual machine with vio interfaces, an > interactive shell hangs completely while data is getting spliced > with full load. The yield() keeps it interactive.
The difference is that you yield() after every somove(9) while sched_pause() only fires after two roundrobin() calls which should be ~200ms. > Adding a task increases througput for about 10%. Without the yield() > it might be a bit faster, but hanging userland is really anoying. The approach used in if_netisr() is a bit different. Instead of scheduling one task per mbuf to process we use a single one with a loop. It would be interesting to see if this approach also exposes the sched_yield() problem or if we're just lucky. > I have tested it a year ago on real hardware, the result was the > same. Back then there was a discussion wether a softnet interrupt > would be better. It was a bit faster, but also could starve the > userland. Now we are heading for threads in the network stack, so > I think a task with yield() is the best solution. I am not sure adding a thread that yield() per subsystem is the best solution. That said I agree that executing more code in thread context has its benefit but we're going expose some bugs/limitations of our current scheduling code. So I think that a good understanding of the yield() problem in this case is a step forward.
