[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: Thu, 2 Jun 2005 17:19:46 -0500
Cc: shemminger@xxxxxxxx, john.ronciak@xxxxxxxxx, hadi@xxxxxxxxxx, mitch.a.williams@xxxxxxxxx, netdev@xxxxxxxxxxx, Robert.Olsson@xxxxxxxxxxx, ganesh.venkatesan@xxxxxxxxx, jesse.brandeburg@xxxxxxxxx
In-reply-to: <20050602.151212.35014607.davem@xxxxxxxxxxxxx>
Organization: IBM
References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <200506021651.49013.jdmason@xxxxxxxxxx> <20050602.151212.35014607.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
On Thursday 02 June 2005 05:12 pm, David S. Miller wrote:
> From: Jon Mason <jdmason@xxxxxxxxxx>
> Date: Thu, 2 Jun 2005 16:51:48 -0500
> > Why not have the driver set the weight to 16/32 respectively for the
> > weight (or better yet, have someone run numbers to find weight that
> > are closer to what the adapter can actually use)?  While these
> > numbers may not be optimal for every system, this is much better
> > that the current system, and would only require 5 or so extra lines
> > of code per NAPI enabled driver.
> Why do this when we can adjust the weight in one spot,
> namely the upper level NAPI ->poll() running loop?
> It can measure the overhead, how many packets processed, etc.
> and make intelligent decisions based upon that.  This is a CPU
> speed, memory speed, I/O bus speed, and link speed agnostic
> solution.
> The driver need not take any part in this, and the scheme will
> dynamically adjust to resource usage changes in the system.

Yes, a much better idea to do this generically.  I 100% agree with you.

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