[Top] [All Lists]

Re: I need sk_buff frag_list info.

To: Mark Wisner <markwiz@xxxxxxxxxx>
Subject: Re: I need sk_buff frag_list info.
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 18 Mar 2002 13:45:49 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <OFCB6FC471.B4D7F12B-ON85256B80.004245CE@xxxxxxxxxxxxxxx>
References: <OFCB6FC471.B4D7F12B-ON85256B80.004245CE@xxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/
On Mon, Mar 18, 2002 at 07:34:39AM -0500, Mark Wisner wrote:
>  I know netif_rx() expects an SKB with all the data in one contiguous
> buffer. I want to avoid the overhead of an additional memcpy() in the

In 2.4 it doesn't anymore, but only some networking protocols support 
it (TCP/UDP/RAW). The others just always fallback to copying
if they cannot deal with a multi paged skb.

> I would like to allocate receive SKBs  with a 4K buffer in each. If a
> packet comes in that uses more than 1 SKB/buffer, I would like to link the
> additional SKBs to the first one and send it up with netif_rx().

This should work with a paged skb. 
As a warning it is not a very common use case though, there are few if 
any drivers that do it. So the stack should support it, but it may not
be the best tested path in the stack. 

> This is an extreme case but it also has applications when handling smaller
> packets. For example, many embedded applications are memory constrained. If
> an application developer knows most of the Ethernet traffic is less than
> 512 bytes, he/she would want to allocate 512 Byte buffers. If a larger than
> 512 byte packet comes in, it would be received over multiple buffers.
> If it is correct , Linux will in reality only allocate buffers of multiples
> of 2K, this may be inefficient and it could put Linux at a disadvantage
> when competing against other embedded OSs.

No Linux doesn't allocate buffers only in multiple of 2Ks. It just currently
rounds buffer sizes to the next power of two.

You can easily change it by changing the kmalloc size array in mm/slab.c.
It just usually doesn't buy you much because the fundamental unit is the
hardware page size, normally 4K, and e.g. when you define a 1.5K kmalloc
size it doesn't fit very well into 4K and requires multipage allocations
which has its own problems. For smaller sizes that fit better into 4K
you can add it if the rounding to power of two is a big problem
for you (the power of two sizes are not any inherent properties of the 
allocator, it can work with any sizes, just a somewhat stupid default list that 
should be probably changed. Tuning it for specific embedded applications
makes definitely sense.) 

> Andi, what is "RTFS"?

Read the Fine Source.


<Prev in Thread] Current Thread [Next in Thread>