| To: | Leonid Grossman <leonid.grossman@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: RFC: NAPI packet weighting patch |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Wed, 22 Jun 2005 20:06:55 +0200 |
| Cc: | hadi@xxxxxxxxxx, "'Donald Becker'" <becker@xxxxxxxxx>, "'Andi Kleen'" <ak@xxxxxxx>, "'Rick Jones'" <rick.jones2@xxxxxx>, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx |
| In-reply-to: | <200506221801.j5MI11xS021866@xxxxxxxxxxxxxxxxx> |
| References: | <1119458226.6918.142.camel@xxxxxxxxxxxxxxxxxxxxx> <200506221801.j5MI11xS021866@xxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
> Outside of the filters capability, from the (granted, pretty limited) > testing we see some noticeable improvement from providing status bits but it > is not as big as I would expect, > It looks like the headers are still being touched somewhere... We will look > at this some more. The headers are read of course in the main stack. No way around that. It basically helps you only when you can space the prefetch for the header out long enough that the data is in cache when you need it. However it is tricky because CPUs have only a limited load queue entries and doing too many prefetches will just overflow that. This can be done by batching L2 packet processing, but doing so is not good for your latency. -Andi |
| Previous by Date: | RE: RFC: NAPI packet weighting patch, Leonid Grossman |
|---|---|
| Next by Date: | Re: RFC: NAPI packet weighting patch, jamal |
| Previous by Thread: | RE: RFC: NAPI packet weighting patch, Leonid Grossman |
| Next by Thread: | Re: RFC: NAPI packet weighting patch, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |