All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: "Andi Kleen" <andi@firstfloor.org>,
	netdev <netdev@vger.kernel.org>,
	"?? ??" <yoshfuji@linux-ipv6.org>,
	"Yumiko SUGITA" <yumiko.sugita.yf@hitachi.com>,
	"\"??@RedHat\"" <haoki@redhat.com>,
	"David Miller" <davem@davemloft.net>,
	"Herbert Xu" <herbert@gondor.apana.org.au>
Subject: Re: [RFC/PATCH 3/3] UDP memory usage accounting (take 2): measurement
Date: Mon, 01 Oct 2007 22:52:27 +0900	[thread overview]
Message-ID: <4700FB9B.1060304@hitachi.com> (raw)
In-Reply-To: <20070928143710.GA16747@2ka.mipt.ru>

Evgeniy Polyakov wrote:
> On Fri, Sep 28, 2007 at 10:41:31PM +0900, Satoshi OSHIMA
(satoshi.oshima.fk@hitachi.com) wrote:
>> This patch introduces memory usage measurement for UDP.
>>
>> These 3 points were updated.
>>
>> - UDP specific codes in IP layer were removed.
>>
>> - atomic_sub() in a loop was removed
>>
>> - accounting during socket destruction
>
> Another approach is to account only at the highest UDP layer and having
> datagram skb destructor just like it is done in TCP, but this approach
> is also resonable.


This patch set try to introduce a memory accounting by the page
because TCP does. And ip_append_data() merges payloads to a sk_buff
if previous sk_buff has enough space. The problem is that
udp_append_data() doesn't recognize whether this merge happens or not.

If the accounting must be in UDP layer, we need to change
the interface of ip_append_data() to know this merge happens.

Once the interface is changed, we have to maintain other
protocol stacks to keep up with the change.

But I didn't want to do it to keep this patch set small
in the first step.


> I already told that patches 1 and 3 have broken indent, please fix that.

Oops! I will fix that.


> A hint: when you are about to submit something network related for
inclusion,
> and strongly believes it is ready, it can be a not that bad idea to add
> David Miller <davem@davemloft.net> to copy list, he can complain about
> backlog and so on, but will read you mail twice :) but do not tell anyone.

Thank you for your advice. I will do that!

Satoshi Oshima

      reply	other threads:[~2007-10-01 13:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 13:41 [RFC/PATCH 3/3] UDP memory usage accounting (take 2): measurement Satoshi OSHIMA
2007-09-28 14:37 ` Evgeniy Polyakov
2007-10-01 13:52   ` Satoshi OSHIMA [this message]

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=4700FB9B.1060304@hitachi.com \
    --to=satoshi.oshima.fk@hitachi.com \
    --cc=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=haoki@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=johnpol@2ka.mipt.ru \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=yumiko.sugita.yf@hitachi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.