public inbox for netdev@vger.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$(echo .)com \
    --cc=andi@firstfloor$(echo .)org \
    --cc=davem@davemloft$(echo .)net \
    --cc=haoki@redhat$(echo .)com \
    --cc=herbert@gondor$(echo .)apana.org.au \
    --cc=johnpol@2ka$(echo .)mipt.ru \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=yoshfuji@linux-ipv6$(echo .)org \
    --cc=yumiko.sugita.yf@hitachi$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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