On Wed, 2007-05-09 at 22:06 -0700, Mandeep Singh Baines wrote: > jamal ([EMAIL PROTECTED]) wrote:
> > If you read the paper: There are no issues with high throughput - NAPI > > kicks in. > > The challenge to be overcome is at low traffic, if you have a real fast > > processor your cpu-cycles-used/bits-processed ratio is high.... > > I'm not sure cpu-cycles-used/bits-processed is the correct metric to use. > An alternative would be to look at cpu-cycles-used/unit-time (i.e. > CPU utilization or load) for a given bit-rate or packet-rate. I wasnt explicit but we are saying the same thing. The paper is more specific: if you make the packet count used constant - this translates to a unit of time given low traffic rate. If you fix the time, cpu-cycles are easier to extrapolate from. > This would make an interesting graph. If you are to plot a cpu-util vs packet rate, on most modern hardware you will see a spike before you hit the MLFRR and then utilization will go down and slowly start going up. > At low packet-rate, CPU utilization is low so doing extra work per packet > is probably OK. Thats the arguement weve used in the past ;-> Unfortunately, with the relative cost of IO going up you cant keep making that arguement (at least thats the position presented in the paper). Your mileage may vary. If you are running a machine dishing out bulk transfers probably not a big deal. If you are doing database transactions, you loose in benchmarks etc. > Utilizing 2% of CPU vesus 1% is negligible. But at higher > rate, when there is more CPU utilization, using 40% of CPU versus 60% is > significant. I think the absolute different in CPU utilization is more > important than the relative difference. iow, 2% versus 1%, even though > a 2x difference in cpu-cycles/packet, is negligible compared to 40% > versus 60%. Refer to above. > Using a timer might also behave better in a tick-less (CONFIG_NO_HZ) > configuration. good point. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
