| To: | jdmason@xxxxxxxxxx |
|---|---|
| Subject: | Re: RFC: NAPI packet weighting patch |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Thu, 02 Jun 2005 15:12:12 -0700 (PDT) |
| 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: | <200506021651.49013.jdmason@xxxxxxxxxx> |
| References: | <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <20050602143126.7c302cfd@xxxxxxxxxxxxxxxxx> <200506021651.49013.jdmason@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
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. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH][5/5] RapidIO support: net driver over messaging, Stephen Hemminger |
|---|---|
| Next by Date: | Re: RFC: NAPI packet weighting patch, Robert Olsson |
| Previous by Thread: | Re: RFC: NAPI packet weighting patch, Jon Mason |
| Next by Thread: | Re: RFC: NAPI packet weighting patch, Jon Mason |
| Indexes: | [Date] [Thread] [Top] [All Lists] |