On Tue, 2016-05-10 at 16:52 -0400, David Miller wrote: > From: Rik van Riel <r...@redhat.com> > Date: Tue, 10 May 2016 16:50:56 -0400 > > > On Tue, 2016-05-10 at 16:45 -0400, David Miller wrote: > >> From: Paolo Abeni <pab...@redhat.com> > >> Date: Tue, 10 May 2016 22:22:50 +0200 > >> > >> > On Tue, 2016-05-10 at 09:08 -0700, Eric Dumazet wrote: > >> >> On Tue, 2016-05-10 at 18:03 +0200, Paolo Abeni wrote: > >> >> > >> >> > If a single core host is under network flood, i.e. ksoftirqd > is > >> >> > scheduled and it eventually (after processing ~640 packets) > will > >> let the > >> >> > user space process run. The latter will execute a syscall to > >> receive a > >> >> > packet, which will have to disable/enable bh at least once > and > >> that will > >> >> > cause the processing of another ~640 packets. To receive a > >> single packet > >> >> > in user space, the kernel has to process more than one > thousand > >> packets. > >> >> > >> >> Looks you found the bug then. Have you tried to fix it ? > >> ... > >> > The ksoftirq and the local_bh_enable() design are the root of > the > >> > problem, they need to be touched/affected to solve it. > >> > >> That's not what I read from your description, processing 640 > packets > >> before going to ksoftirqd seems to the be the absolute root > problem. > > > > What would a fix for that look like? > > > > Keep track of the number of processed incoming packets, > > and the number of packets handed off, and defer to > > ksoftirqd earlier if the statistics suggest packets are > > getting dropped on the floor? > > Not by packet count but by something more easily to measure and > scalable to fairness like processing time.
I need to get back to fixing irq & softirq time accounting, which does not currently work correctly in all time keeping modes... -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part