Re: skb data uncacheable ??

From: Nagendra Singh Tomar
Date: Mon Apr 12 2004 - 23:33:32 EST

I went ahead and added such an API and the performance was _not_ _great_.
I feel the reason for this is the presence of skb_shared_info at the end
of the skb->data. Since this skb_shared_info needs to be accessed at least
a couple of times we get hurt badly if that lies in the non-cacheable
Other bigger thing is the access to the various protocol headers.
Since currently these also lie in skb->data we need to access skb->data
even for devices that do Rx checksum verification (and hence allow us to
leave the data payload untouched). If we can have a strategy in which we
keep first 128 bytes say (precisely max possible header size) in a
cacheable region and the rest, that is pure data, in uncacheable region,
we can see some gain.

The most important question: Is it worth all this ? DO we gain much if we
prevent pollution of the data cache, by doing these tricks.

Comments are welcome.


On Mon, 5 Apr 2004, Nagendra Singh Tomar wrote:

> Hi,
> I was wondering why we do not have a provision for making the skb->data
> point to uncacheable memory, something like alloc_skb_noncacheable(),
> which allocates skbuffs from a pool of uncacheable memory.
> This might be useful for smart devices that do the checksum validation in
> h/w and thus do not ask for the stack to touch the data part of received
> packets. This data part is touched just once when it is copied to user
> buffers. Why pollute the CPU cache with data which is accessed just once ?
> If something similar to this is already there, pls let me know.
> Thanx,
> tomar
> PS: Pls CC to my email-id.
> -- You have moved the mouse. Windows must be restarted for the
> changes to take effect.


-- You have moved the mouse. Windows must be restarted for the
changes to take effect.

To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at