netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Hisham Kotry" <hkotry@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: skb diet
Date: Sat, 15 Apr 2006 21:22:01 +0200	[thread overview]
Message-ID: <200604152122.01914.ak@suse.de> (raw)
In-Reply-To: <baebb9a00604150417h1ffb3f97g102253dca0b3a53e@mail.gmail.com>

On Saturday 15 April 2006 13:17, Hisham Kotry wrote:
> I just read David S. Miller's skb redundancy page and in it he seems to suggest
> taking an approach similar to that of BSD's mbufs to reduce the skb's
> size. I was going to do some janitor work on the network stack and I
> thought that maybe I could start by adding a tag list to the skb
> similar to BSD's mbuf tags and change the code to store its private
> variables in tags rather than in skb->cb. That should save 40 bytes
> per skb and maybe later the tc and nf related variables could go in
> tags too. The transition shouldn't be hard for the most part, many
> users of skb->cb use macros like FRAG_CB(skb) so I could redefine
> those macros to search the tag-list for the appropriate tag and return
> its contents. Is this approach acceptable or is there a consensus on
> another approach?

Where would that tag list be stored if you want to remove the 
40 bytes of ->cb?

In general I don't think it will help much even if you find
a magic way to store it without using memory @) because
->cb is already private to each layer, so it's only the single 40 bytes
which is reused as needed.

You seem to think they accumulate which is not the case.

Linux 2.0 did something like this, but that was removed for good 
reasons. Now TCP always clones skbs before sending it out.

And optimizing for uncommon cases (not TCP) doesn't seem too useful.

-Andi

  reply	other threads:[~2006-04-15 19:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-15 11:17 skb diet Hisham Kotry
2006-04-15 19:22 ` Andi Kleen [this message]
2006-04-16 11:43   ` bert hubert
2006-04-16 12:56   ` Hisham Kotry
2006-04-16 15:16     ` Andi Kleen
2006-04-17  5:25       ` David S. Miller

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=200604152122.01914.ak@suse.de \
    --to=ak@suse.de \
    --cc=hkotry@gmail.com \
    --cc=netdev@vger.kernel.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).