Jesse Brandeburg a écrit :
On Wed, 7 Dec 2005, David S. Miller wrote:
> The different between the cases was not significant and the
> prefetching cases were better than no prefetching. Again, still no
> detriment to performance.
I still think what e1000 is doing is way too aggressive.
I know of at least one platform, sparc64, that doesn't
even have enough prefetch slots on certain chips to support
the number of outstanding prefetches you are issuing.
One, maybe two, prefetches per RX skb processed should be
more than enough. As demonstrated by Robert.
Please reduce the aggressiveness of your prefetching, at
least for the first implementation that goes into the tree.
Ok? We can discuss doing more aggressive things in the
future.
Okay, so I tested with just pktgen sending to a machine with a PCI
Express Intel 82571 server adapter. The stack is just discarding the
data, no routing.
There are 5 prefetches in the e1000_clean_rx_irq_ps function
#1 skb->data
#2 next rx descriptor
#3 next rx buffer_info
#4 next skb
#5 next skb->data
There are _no_ copybreaks in this code
here are my results:
sender sending at ~700000 pkt/s
dual Xeon, 2.8GHz, 1MB cache, 2.6.14
all tests with 6.2.15
no prefetch: 517500
#1: 539000
#1#2: 547500
#1#2#5: 565500
#1#2#3#5: 565100
#1#2#3: 545500
#1#2#3#4: 544200
prefetching the next rx descriptor really helps us. (#2)
prefetching the next skb->data also really helps.
#4#5 as proposed in the patch can not be a win
+ prefetch(next_skb);
+ prefetch(next_skb->data - NET_IP_ALIGN);
because at the time #5 is done, the CPU dont have in its cache next_skb->data
(because the #4 prefetch is the previous instruction)
prefetch(ptr) is mostly a free hint for the CPU.
prefetch(*ptr) can be expensive because of the needed indirection that might
slow down the CPU if *ptr is not yet available in its L1 cache.
in no case did the prefetch hurt anything on this box. I'd prefer
leaving #1#2#5 for now.
Jesse
Eric
-
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
