Date: Fri, 27 Mar 2009 11:05:00 +0000 From: Andrew Brampton <brampton+freebsd-net@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-net@freebsd.org Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) Message-ID: <d41814900903270405p19d26d94r7c7351adca05f283@mail.gmail.com> In-Reply-To: <20090327071742.GA87385@onelab2.iet.unipi.it> References: <d41814900903261747v28d3de29t10bb1b8128de635c@mail.gmail.com> <20090327071742.GA87385@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/3/27 Luigi Rizzo <rizzo@iet.unipi.it>: > The load of polling is pretty low (within 1% or so) even with > polling. The advantage of having interrupts is faster response > to incoming traffic, not CPU load. oh, I was under the impression that polling spun in a tight loop, thus using 100% of the processor. After a quick test I see this is not the case. I assume it will get to 100% CPU load if I saturate my network. > > There is nothing difficult in having both active, except figuring > out a good logic for when to disable polling on an interface > that has been quiet for a while. Looking at Linux's logic, it appears to poll until there are no more packets, and thus re-enables interrupts. > > I don't know what is the status of polling these days -- when i > wrote it, the architecture was designed for UP kernels, and I > don't know if/how it has been revised to deal efficiently with > the SMP kernels we have now (in other words: one or multiple > polling loops, interaction with interrupt threads, etc.) So, do you think the interrupt+polling has a place in FreeBSD? Now that I know that Polling doesn't consume 100% of the processor, it might be best to "keep it simple stupid". > > =C2=A0 =C2=A0 =C2=A0 =C2=A0cheers > =C2=A0 =C2=A0 =C2=A0 =C2=A0luigi > Thanks for answer my questions, and thanks for writing polling support in the beginning! Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d41814900903270405p19d26d94r7c7351adca05f283>