Thread (1 message) 1 message, 1 author, 2006-10-13

Re: [patch] Performance enhancement patches for SB1250 MAC

From: Stephen Hemminger <hidden>
Date: 2006-10-13 21:35:16

On Thu, 12 Oct 2006 17:45:54 -0700
"Yang, Steve" [off-list ref] wrote:
Stephen,

I assume the "expense" you referred to is the reserved SK cache buffers.


1. The SKB_CACHE does hold on to buffers which would
   otherwise be returned to the system (although the
   number it holds on to is limited and configurable).
   These buffers are only returned with certainty
   at module unload time, although with normal traffic
   most of them would be recycled pretty quick.  I think
   the cache was implemented as a stack, rather than a
   FIFO, which could cause a few buffers to be held for
   quite a while under light loads.

2. SKB_CACHE, just like NAPI, is also a configurable
   option. Systems that need the performance have the
   option of turning this on, at the expense of small
   number of buffers; other systems which don't care
   much about networking performance can leave this
   option off.

3. Can you elaborate other possible issues that you
   touch upon (memory starvation/race, etc.)?

Regards, 
Steve Yang
Several drivers have tried to do this in the past, but the consensus
has been that this is a bad idea. 

Your code captures transmit skb's and uses them for receive. Why is
this a good idea? It is a maintenance nightmare, it breaks a lot of
the cleanup/initialization of skb's and means who ever changes something
like TSO has to go looking at some driver that is doing squirrley games.

Plus, your cache requires two extra lock round trips is seems.
The cost of alloc_skb should be trivial.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help