From: Kelly Daly <[EMAIL PROTECTED]> Date: Thu, 4 May 2006 12:59:23 +1000
> We DID write an infrastructure to resolve this issue, although it is more > complex than the dynamic descriptor scheme for userspace. And we want to > keep this simple - right? Yes. I wonder if it is possible to manage the buffer pool just like a SLAB cache to deal with the variable lifetimes. The system has a natural "working set" size of networking buffers at a given point in time and even the default net channel can grow to accomodate that with some kind of limit. This is kind of what I was alluding to in the past, in that we now have globals limits on system TCP socket memory when really what we want to do is have a set of global generic system packet memory limits. These two things can tie in together. Note that this means we need a callback in the SKB to free the memory up. For direct net channels to a socket, you don't need any callbacks of course because as you mentioned you know the buffer lifetimes. People want such a callback anyways in order to experiment with SKB recycling in drivers. Note that some kind of "shrink" callback would need to be implemented. It would only be needed for the default channel. We need to seriously avoid needing something like this over the socket net channels because that is serious complexity. Finally... if we go the global packet memory route, we will need hard and soft limits. There is a danger in such a scheme of not being able to get critical control packets out (ACKs, etc.). Also, there are all kinds of classification and drop algorithms (see RED) which could be used to handle overload situations gracefully. So, are you still sure you want to do away with the descriptors for the default channel? Is the scheme I have outlined above doable or is there some critical barrier or some complexity issue which makes it undesirable? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html