On Thu, 12 Oct 2006 17:45:54 -0700 "Yang, Steve" <[EMAIL PROTECTED]> 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. - 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
