On Mon, 27 Dec 2004 14:23:50 PST, "David S. Miller" said:
If we are really going to do something like this, it should
be calculated properly and be determined per-interface
type as netdevs are registered.
Would you prefer to see this done for all interface types if we do it
at all, or would a special-case for 1 or 2 types that can use a slab
without being wasteful be an acceptable solution? (Let's face it - if
3.95 objects fit in each slab, we may not want to do it...)
On Mon, 27 Dec 2004 17:50:01 -0500
Valdis.Kletnieks@vt.edu wrote:
On Mon, 27 Dec 2004 14:23:50 PST, "David S. Miller" said:
quoted
If we are really going to do something like this, it should
be calculated properly and be determined per-interface
type as netdevs are registered.
Would you prefer to see this done for all interface types if we do it
at all, or would a special-case for 1 or 2 types that can use a slab
without being wasteful be an acceptable solution? (Let's face it - if
3.95 objects fit in each slab, we may not want to do it...)
It's not even just device MTU based (which can change dynamically
at run time), it's also based upon the PMTU for various paths.
As for wastefulness, that's a good question. Adding a mechanism
to do kmalloc slabs dynamically doesn't sound all that wise. That
would undo all the inlining tricks.
Probably a better idea is to provide a way to attach a slab to
an SKB's data area so that we can have per-device SLABs for this
kind of stuff (and if all "ethernet" devices want to share the
same SLAB, that's fine too, but it won't help all ethernet drivers
for reasons outlined in my previous email).
We added something similar for the Xen folks, and it's in Linus's
BK tree right now. It's named alloc_skb_from_cache().
What I'd really like to see is device based determination of the
correct slab to use. Unfortunately, dev_alloc_skb() doesn't take
a netdev argument, which is truly offensive. Otherwise we could
just stick the necessary logic there.