Date: Thu, 17 Apr 2008 10:05:37 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: freebsd-net@freebsd.org, Dieter <freebsd@sopwith.solgatos.com>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: bge dropping packets issue Message-ID: <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> In-Reply-To: <20080417145652.J71628@fledge.watson.org> 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> <20080417145652.J71628@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 17, 2008 at 9:59 AM, Robert Watson <rwatson@freebsd.org> wrote: > 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. That was my original guess! :D! > (2) Even with interrupt moderation, livelock can occur because there is no > facility to limit the CPU use assigned to sources of network load. So this provides the OS to optionally throttle heavy network load in order to ensure liveliness as I understand you. > 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, alright, this all makes sense. So it seems to me that the first step to salvation in my world is to turn off DEVICE_POLLING and rely on the interrupt coalescing that exists on the card. My only concern if this does work is what impact this has on the overall system. -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820804170705l9c196d9rff45fa4919ace8c>