On Wednesday 08 February 2006 01:44, David S. Miller wrote: > From: Ben Greear <[EMAIL PROTECTED]> > Date: Tue, 07 Feb 2006 16:39:52 -0800 > > > Rick Jones wrote: > > > In the realm of straw ideas, how often are netdevs added and removed, > > > and would leaving a tombstone behind consume too much memory? > > > > In certain cases...say, with vlans, you could very often create and > > destroy net devices. I think that giving up and leaking the memory > > is not a good idea. > > I think he's suggesting another thing. Reattach the skb->dev > to some dummy device that always persists, when a device goes > down.
One possible way would be to combine the tombstone with a global generation number. tombstone would be just the netdevice memory itself not freed, but possibly reused. Instead of just having a pointer to struct netdevice in the skb have a pointer and a generation number. Each use checks the generation number and if it doesn't match the net devices throw away the skb because its device is gone. This check is cheap on SMP because it's fully read only and can happen with shared cache lines. Then never free struct net_devices, but only reuse them with higher generation numbers. The "use" could be some central place like dev_queue_xmit() and perhaps some places in netfilter. I don't think every reference of skb->dev would need to check it because most could probably tolerate stale devices Disadvantages: - When the device is freed but not reused yet it must be in a state that it can be safely accessed by all users [should be easy] - If there is some workload that only needs temporarily a lot of devices then the system can never recover to use less for them. Probably not a big issue. - It would need a few bytes in the skb (and possibly other data structures referencing the device) to store the generation count. - The generation number check would add a few cycles, but I guess it's much cheaper than the cache misses from the reference counts. - If the generation count wraps then skbs could be sent to the wrong devices. With 32bit probably not a big issue. -Andi - 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
