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 region. 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. Thanx, tomar 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. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
