Re: Gigabit Performance 2.4.19-preX - Excessive locks, calls, waits

["Jeff V. Merkey" <jmerkey@vger.timpanogas.org>]

On Mon, Mar 04, 2002 at 06:34:33PM +0000, Alan Cox wrote:
> > > Thats up to the network adapter. In fact the Linux drivers mostly do 
> > > keep preloaded with full sized buffers and only copy if the packet size
> > > is small (and copying 1 or 2 cache lines isnt going to hurt anyone)
> > 
> > There's an increase in latency.  For my application, I have no 
> 
> A very tiny one (especially if you keep a small buffer pool around too).
> To copy a packet is 2 cache line loads, which will dominate, some
> writes that you wont be able to measure, and a writeback you won't be
> able to instrument without a bus analyser.
> 
> For receive paths its up to the driver. The copy to smaller buffer is
> something the driver can choose to do. It and it alone decide what skbuff
> to throw at the kernel core
> 
> The bigger ring helping is interesting but itself begs a question. Do you
> ever dirty rather than merely reference skbuff data. In that case a bigger

Actually, I am plugging in my own data blocks into the skbuff->data
pointer from the drivers themselves.  When the driver allocates an 
skbuff, I use an alternate cache allocator to load the buffer 
into the skbuff, and I leave the two attached.  skb_release_data does
not release one of my data blocks.  These blocks are 4K aligned so 
I am not in the middle of a cache line (I think) in the data portion
when DMA is initiated.

> ring may simply be hiding the fact that the recycled skbuff has dirty
> cached data that has to be written back. Does the combination of hardware

This is probably happening.  I have an Arium here now, and am hooking
it up.  I can get memory bus traces and provide what's actually 
happening on the bus.  I do not ever DMA into a partial cache line.

Jeff

> you have do the right thing when it comes to the invalidating  - and do
> you ever DMA into a partial cache line ?

> 
> Alan