Date: Thu, 17 Apr 2008 14:59:53 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Sack <pisymbol@gmail.com> Cc: freebsd-net@freebsd.org, Dieter <freebsd@sopwith.solgatos.com>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: bge dropping packets issue Message-ID: <20080417145652.J71628@fledge.watson.org> In-Reply-To: <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Apr 2008, Alexander Sack wrote:
> First off thanks for the detailed reply Bruce. I have some follow-up
> questions in my quest to learn more about BGE/networking etc.
>
> On Wed, Apr 16, 2008 at 10:53 PM, Bruce Evans <brde@optusnet.com.au> wrote:
>> On Wed, 16 Apr 2008, Alexander Sack wrote:
>>> On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim <jkim@freebsd.org> wrote:
>>
>> First stop using the DEVICE_POLLING packet lossage service...
>
> For my own edification, when do you want use DEVICE_POLLING versus interrupt
> driven network I/O? With all question like these I suppose the answer
> depends on the workload and the interrupt bandwidth of the machine (which
> depends on the type of hardware)...
>
> But why was it added to begin with if standard interrupt driven I/O is
> faster? (was it the fact that historically hardware didn't do interrupt
> coalescing initially)
There are serious functional limitations to the current DEVICE_POLLING code in
the new world order of device drivers, ithread, SMP, etc. Leaving this aside,
here are two reasons why it exists:
(1) Historically, devices did not support interrupt moderation.
(2) Even with interrupt moderation, livelock can occur because there is no
facility to limit the CPU use assigned to sources of network load.
Something interrupt moderation does *not* provide is the ability to schedule
network stack processing at idle priority, or limit CPU use to a percentage of
total CPU in order to leave CPU resources for other activity (such as fixing
the load problem, getting work done, etc). Our device polling infrastructure
needs serious work, and I think quite a bit of it could usefully move to the
interrupt infrastructure layer, but we should be careful to consider some of
the functional aspects to DEVICE_POLLING that do differentiate it (load
management, not just interrupt moderation).
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080417145652.J71628>