Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:41:19 -0700 (PDT)
Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168])
	by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52LfFXq028972
	for <netdev@oss.sgi.com>; Thu, 2 Jun 2005 14:41:15 -0700
Received: from localhost ([127.0.0.1] ident=davem)
	by sunset.davemloft.net with esmtp (Exim 4.50)
	id 1DdxQ3-00058E-Ju; Thu, 02 Jun 2005 14:40:03 -0700
Date: Thu, 02 Jun 2005 14:40:03 -0700 (PDT)
Message-Id: <20050602.144003.35660495.davem@davemloft.net>
To: shemminger@osdl.org
Cc: john.ronciak@intel.com, hadi@cyberus.ca, jdmason@us.ibm.com,
        mitch.a.williams@intel.com, netdev@oss.sgi.com,
        Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com,
        jesse.brandeburg@intel.com
Subject: Re: RFC: NAPI packet weighting patch
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <20050602143126.7c302cfd@dxpl.pdx.osdl.net>
References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408>
	<20050602143126.7c302cfd@dxpl.pdx.osdl.net>
X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-archive-position: 1991
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@davemloft.net
Precedence: bulk
X-list: netdev
Content-Length: 1077
Lines: 25

From: Stephen Hemminger <shemminger@osdl.org>
Date: Thu, 2 Jun 2005 14:31:26 -0700

> For networking the problem is worse, the "right" choice depends on workload
> and relationship between components in the system. I can't see how you could
> ever expect a driver specific solution.   

I totally agree, even the mere concept of driver-centric decisions
in this area is pretty bogus.

> And for other workloads, and other systems (think about the Altix with
> long access latencies), your numbers will be wrong. Perhaps we need
> to quit trying for a perfect solution and just get a "good enough" one
> that works.

I don't understand why nobody is investigating doing this stuff
by generic measurements that the core kernel can perform.

The generic ->poll() runner code can say, wow it took N-usec to
process M packets, perhaps I should adjust the weight.

I haven't seen one concrete suggestion along those lines, yet that is
where the answer to this kind of stuff is.  Those kinds of solutions
are completely CPU, memory, I/O bus, network device, and workload
independant.