From: "David S. Miller" <davem@davemloft.net>
To: Valdis.Kletnieks@vt.edu
Cc: kaber@trash.net, alan@lxorguk.ukuu.org.uk, torvalds@osdl.org,
linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: PATCH: kmalloc packet slab
Date: Mon, 27 Dec 2004 14:58:07 -0800 [thread overview]
Message-ID: <20041227145807.73803fa8.davem@davemloft.net> (raw)
In-Reply-To: <200412272250.iBRMo2Qb011114@turing-police.cc.vt.edu>
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:
>
> > 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.
next prev parent reply other threads:[~2004-12-27 22:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1104156983.20944.25.camel@localhost.localdomain>
2004-12-27 17:17 ` PATCH: kmalloc packet slab Patrick McHardy
2004-12-27 22:23 ` David S. Miller
2004-12-27 22:50 ` Valdis.Kletnieks
2004-12-27 22:58 ` David S. Miller [this message]
2004-12-28 0:51 ` Alan Cox
2004-12-28 6:01 ` Dave Jones
2004-12-30 18:00 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041227145807.73803fa8.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=Valdis.Kletnieks@vt.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).