From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 14:11:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236D8106566B for ; Thu, 17 Apr 2008 14:11:40 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id D30348FC1E for ; Thu, 17 Apr 2008 14:11:39 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so51781ywt.13 for ; Thu, 17 Apr 2008 07:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ucHv7AyvzekaOW0EmDaadcH6StHH1DKvg1owYdT+YOQ=; b=nUDw28HFfMDf5d9MTWVByaiY+/91n7hRV4g+QPrNaOL20Vxu0nLIKsQIVSLzNoC1M55gx9fHgWukrKpqE0UhYbw4cbDUO9HT9Pqq4+QrEwniL0ZRcUf7zqzdRPmUMTYu1wDFThJEEnL9jFG2hEuLtIzLAhL+k7AVWjqSHyYpv9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V+LCoC9OvMS96P66om88RZe8Ey0oZ5/VN0Cye4go0ChBEcXRNNQht7h+pPJyDoEhqabXwH/XhwmQs0qZTlIHYFJ1YKjdwG+DiBwpMehY0Oli8COBc5iYWn7yU7z6E5eU1cWM1ealT9lrIDSSyL8UZp7j1djZ5z7xfR7em4sGfxY= Received: by 10.151.108.19 with SMTP id k19mr1670105ybm.191.1208441137232; Thu, 17 Apr 2008 07:05:37 -0700 (PDT) Received: by 10.151.15.21 with HTTP; Thu, 17 Apr 2008 07:05:37 -0700 (PDT) Message-ID: <3c0b01820804170705l9c196d9rff45fa4919ace8c@mail.gmail.com> Date: Thu, 17 Apr 2008 10:05:37 -0400 From: "Alexander Sack" To: "Robert Watson" In-Reply-To: <20080417145652.J71628@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Cc: freebsd-net@freebsd.org, Dieter , Jung-uk Kim Subject: Re: bge dropping packets issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2008 14:11:40 -0000 On Thu, Apr 17, 2008 at 9:59 AM, Robert Watson 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 > wrote: > > > > > On Wed, 16 Apr 2008, Alexander Sack wrote: > > > > > > > On Wed, Apr 16, 2008 at 4:54 PM, Jung-uk Kim 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