On Mon, Jun 18, 2001 at 01:46:44PM -0700, Will wrote: > > Anyway, we're playing with the idea... Seems like this could also be a move in the > right direction for driver writers who could benefit by managing their own memory > somewhat (though we don't have enough experience with drivers or specifics of skb > allocation to know for sure who else this could benefit). > > Comments? Does this violate some 'larger vision' for the stack that we're not > seeing? I think it would be a good idea. I'm currently writing a driver for a networking device that happens to make efficient use of the pages it is given for rx packets. Instead of putting only one packet in each page it is given, it treats the list of pages as a continuous buffer into which packets are placed. Without a generic skb destructor mechanism, the driver must allocate memory for each packet received and copy the data from the page(s) the hardware originally dropped the packet into. (We could try to amortize the cost of the copy by performing the checksum at the same time, but when the hardware has already done the checksum for us, the copy is really nothing but overhead) With a more generic skb destructor mechanism, we could skip the copy, and just point the skb at the original pages. And when the skb is destroyed we simply make note of that in our data structures so we know when a page is no longer referenced by an skb and can be queued up for the hardware to use again. So, I'd vote yes, simply because it would allow efficient drivers to be developed for more memory-efficient networking hardware. As for whether or not this "violates vision", I dunno. That's up to the whims of the Vision Police. (Given recent discussions, though, my first guess would be that this will be deemed unacceptable for some reason or another) Thanks --macko - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
