netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@oss.sgi.com
Subject: Re: Set truesize in pskb_expand_head
Date: Fri, 24 Sep 2004 16:45:40 -0700	[thread overview]
Message-ID: <20040924164540.2d750572.davem@davemloft.net> (raw)
In-Reply-To: <20040924233713.GA8001@gondor.apana.org.au>

On Sat, 25 Sep 2004 09:37:13 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Sat, Sep 25, 2004 at 09:35:55AM +1000, herbert wrote:
> > 
> > Dave, it hasn't been charged yet...
> 
> Well at least not in the netlink case.  But you're that we can't do this
> in general.  I'll adjust it right after the pskb_expand_head call then.

I still am hesitant about your idea.

You're willing to do a very likely re-alloc every transaction
where as I'm suggesting a single allocation for the socket at
creation time which is used for every transaction on that
socket.

Let's talk more precisely, perhaps I'm missing something,
my scheme:

   Single PAGE_SIZE scratch buffer per socket, results in one
   allocation at socket creation time, and one SKB allocation
   while building a response.

your scheme:

   Allocate full PAGE_SIZE SKB for each netlink transaction,
   reallocate data area at end of building each transaction.

So, two data area kmalloc()'s per netlink response compared
to one for mine.

Your scheme doesn't even avoid the copy.  What's the advantage?
Furthermore my per-socket PAGE_SIZE scratch area is likely to
get very good cache hit rates making the copy very inexpensive.

Comments?

  reply	other threads:[~2004-09-24 23:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-24 23:20 Set truesize in pskb_expand_head Herbert Xu
2004-09-24 23:33 ` David S. Miller
2004-09-24 23:35   ` Herbert Xu
2004-09-24 23:37     ` Herbert Xu
2004-09-24 23:45       ` David S. Miller [this message]
2004-09-25  0:05         ` Herbert Xu
2004-09-27 19:27           ` David S. Miller
2004-09-27 21:29             ` Herbert Xu

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=20040924164540.2d750572.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@oss.sgi.com \
    /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).