Re: netif_rx packet dumping

[Andi Kleen <ak@muc.de>]

> > You could also use a xor list in theory. But I'm not sure it's worth it.
> > Increasing cb by 4 bytes shouldn't be a very big issue.
> 
> Going from "40" to "44" takes 64-bit platforms onto another cache line
> for struct sk_buff, as I stated in another email.
> 
> And every time I let this happen, I get an email from David Mosberger because
> it shows up in performance tests on ia64. :-)

Ok, then use a XOR list or trim some other field.

There are some other savings possible e.g. from a quick look:
- skb->list is afaik totally unnecessary and probably even unused.
- struct timeval could be an optimized structure using 32bit
for the sub second part. 
(would need moving it somewhere else, otherwise alignment doesn't help)
- Are really three device pointers needed? Perhaps things can
be a bit optimized here.
- Hippi could be finally changed to use skb->cb instead of its
private field.
- is skb->security still needed? It should be obsolete with ->sec_path, no?
Would only help together with the timestamp optimization.

Of course these all wouldn't change the number of cache lines significantly,
but it would possible allow other optimizations that need new fields.

-Andi