On Fri, 2005-09-12 at 15:11 -0800, David S. Miller wrote: > From: jamal <[EMAIL PROTECTED]> > Date: Fri, 09 Dec 2005 16:30:24 -0500 > > > indeed sounds interesting until you start hitting clones ;-> > > so dont run a sniffer or do anything of the sort if you want to see > > some good numbers - otherwise I suspect you will get worse numbers than > > the case of current path and skbs being cloned/shared. > > If it gets cloned then it simply degenerates to roughly what > is happening today. We'll simply not allow the driver to > reuse the buffer and it will need to allocate a new one. >
It does sound plausible as being useful;-> Essentially the approach would be the same as Robert's old recycle patch where he doesnt recycle certain skbs - the only difference being in the case of forwarding, the recycle is done asynchronously at EOT whereas this is done synchronously upon return from host path. The beauty of the approach is you dont have to worry about recycling on the wrong CPU ;-> (which has been a big problem for forwarding path) > Or, we could mark SKB's specially when their usage ratio is > low. At clone/share time, we can "cow" the SKB into a smaller > one. > > There are a lot of things we can do to defer reallocation until > it is absolutely necessary and avoid it in most cases. > > In fact, thinking more, if we put the copybreak logic into > the local protocol reception, we can check the cloned/shared > state right then and there and know if we can give it back > or not. > I have to chime in and say for the host stack - I like it ;-> cheers, jamal - 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
