Re: [patch] Performance enhancement patches for SB1250 MAC

[Stephen Hemminger <shemminger@osdl.org>]

On Thu, 12 Oct 2006 17:45:54 -0700
"Yang, Steve" <steve.yang@windriver.com> 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.