From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 29 Nov 2006 17:51:46 +1100
> I'm just emphasising that LL_MAX_HEADER is by no means the *maximum* > header size in a Linux system. But it is the maximum "link level" singular header size. It is MAX_HEADER which is the hack and the main issue. What MAX_HEADER's setting is trying to do is optimistically allocate enough for a single level of tunnelling. It does not handle nested tunneling at all, of course. > As to getting rid of those ifdefs, here is one idea. We keep a > read-mostly global variable that represents the actual current > maximum LL header size. Everytime a new device appears (or if > its hard header size changes) we update this variable if needed. > > Hmm, we don't actually update the hard header size should the > underlying device change for tunnels. Good thing the tunnels > only use that as a hint and reallocate if necessary :) > > This is not optimal in that it never decreases, but it's certainly > better than a compile-time constant (e.g., people using distribution > kernels don't necessarily use tunnels). I like this idea for the most part. It also deals nicely with, as you alude to, how the MAX_HEADER scheme uses the space even if you don't configure any tunnels at all. Actually, I wonder how antiquated this all is. I bet we could get rid of MAX_HEADER, then if we have to realloc headroom, we adjust some per-device header thing which will behave like your global value idea does. On the next allocation, we'll do the right thing. Although I cannot come up with a scheme that works without reintroducing another net_device pointer to sk_buff, which seems necessary to handle arbitrary nesting. :-/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
