David Miller wrote: > From: Patrick McHardy <[EMAIL PROTECTED]> > Date: Thu, 19 Jul 2007 12:11:10 +0200 > > >>The easiest fix would be to use egress_subqueue[1] in struct >>net_device, but I think that may cause warnings with newer gccs >>when using a constant index that is > 0. OTOH using constant >>indices doesn't seem to make much sense for the subqueue array. >> >>Arkadiusz, does this patch fix the problem? > > > I've applied this, but long term we should either: > > 1) Make loopback_dev dynamically allocated just like every > other netdev, so make loopback_init() a postcore_initcall() > to make sure that is setup early enough. > > Then have to walk over the tree making everything able > to handle the fact that it's a pointer. Several data > structures are compile time initialized to "&loopback_dev" > for example, and therefore will have to be transformed into > a run-time initialization. > > 2) Pick some arbitrary limit for the queues, and just have that > many of them allocated in every netdev. > > I like #2 because it allows us to get back the netdev_priv() > optimization.
Yes, some constant limit definitely makes sense. The Tx batching patches motivated me to work through struct net_device with pahole and I have some patches that rearrange it to save about 64 bytes and move some members from very unfortunate positions to better ones, but they still leave two 32 byte holes on SMP (with 64 byte cachelines). Plugging one of these with a statically sized subqueue array would be perfect since one of the holes is within the Tx cachelines anyway (at least for now, until we add subqueue locks ..). Its 2.6.24 material though, and I very much hope they will clash with Stephen's plans to introduce struct net_device_ops. - 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
