netdev
[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: Jon Mason <jdmason@xxxxxxxxxx>
Date: Tue, 31 May 2005 18:28:43 -0500
Cc: mitch.a.williams@xxxxxxxxx, hadi@xxxxxxxxxx, shemminger@xxxxxxxx, netdev@xxxxxxxxxxx, Robert.Olsson@xxxxxxxxxxx, john.ronciak@xxxxxxxxx, ganesh.venkatesan@xxxxxxxxx, jesse.brandeburg@xxxxxxxxx
In-reply-to: <20050531.151443.74564699.davem@xxxxxxxxxxxxx>
Organization: IBM
References: <1117241786.6251.7.camel@xxxxxxxxxxxxxxxxxxxxx> <200505311707.54487.jdmason@xxxxxxxxxx> <20050531.151443.74564699.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote:
> From: Jon Mason <jdmason@xxxxxxxxxx>
> Date: Tue, 31 May 2005 17:07:54 -0500
>
> > Of course some performace analysis would have to be done to determine the
> > optimal numbers for each speed/duplexity setting per driver.
>
> per cpu speed, per memory bus speed, per I/O bus speed, and add in other
> complications such as NUMA
>
> My point is that whatever experimental number you come up with will be
> good for that driver on your systems, not necessarily for others.
>
> Even within a system, whatever number you select will be the wrong
> thing to use if one starts a continuous I/O stream to the SATA
> controller in the next PCI slot, for example.
>
> We keep getting bitten by this, as the Altix perf data continually shows,
> and we need to absolutely stop thinking this way.
>
> The way to go is to make selections based upon observed events and
> mesaurements.

I'm not arguing against a /proc entry to tune dev->weight for those sysadmins 
advanced enough to do that.  I am arguing that we can make the driver smarter 
(at little/no cost)  for "out of the box" users.

<Prev in Thread] Current Thread [Next in Thread>