From: Hideo AOKI <haoki@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org,
tyasui@redhat.com, mhiramat@redhat.com,
satoshi.oshima.fk@hitachi.com, billfink@mindspring.com,
andi@firstfloor.org, johnpol@2ka.mipt.ru,
shemminger@linux-foundation.org, yoshfuji@linux-ipv6.org,
yumiko.sugita.yf@hitachi.com, haoki@redhat.com
Subject: Re: [PATCH 2/4] [CORE]: datagram: basic memory accounting functions
Date: Thu, 20 Dec 2007 23:18:54 -0500 [thread overview]
Message-ID: <476B3EAE.4070809@redhat.com> (raw)
In-Reply-To: <20071220.034304.212231150.davem@davemloft.net>
Hello,
Thank you so much for your comments.
David Miller wrote:
> All of these other functions are identical copies of the stream
> counterparts, they should all be consolidated.
>
> I still see a lot of special casing, instead of large pieces of common
> code.
>
> There should be one core set of functions that handle the memory
> accounting, regardless of socket type. Maybe there is one spot where
> something like sk->prot->doing_memory_accounting is tested, but that's
> it.
I understood. I'll re-write my patch set to make memory accounting
core functions.
> Also, the memory accounting is done at different parts in
> the socket code paths for stream vs. datagram. This is why
> everything is inconsistent, and, a mess.
Could you tell me more detailed information?
Does this comment mean interface and usage of memory accounting functions?
If so, I'll consolidate functions like sk_stream_set_owner_r() and
sk_stream_free_skb(). And, I may have to use memory accounting functions in
memory allocating functions like sk_stream_alloc_pskb() as possible
instead of inside of socket operating functions.
Or, does the comment mean that send buffer accounting in IP layer
(e.g. ip_append_data()) is wrong?
Anyway, in next patch set, I'm going to consolidate mem_schedule
functions and mem_reclaim functions. To do so, some of memory
accounting functions for stream protocols will be renamed or
be moved to core/sock.c from core/stream.c.
I would like to know what kind of enhancement must be needed for
memory accounting core functions.
Again, thank you for taking your time to review this feature.
Best regards,
Hideo
--
Hitachi Computer Products (America) Inc.
next prev parent reply other threads:[~2007-12-21 4:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 2:33 [PATCH 0/4] [UDP]: memory accounting and limitation (take 11) Hideo AOKI
2007-12-18 2:38 ` [PATCH 1/4] [UDP]: fix send buffer check Hideo AOKI
2007-12-20 11:31 ` David Miller
2007-12-21 3:43 ` Hideo AOKI
2007-12-18 2:38 ` [PATCH 2/4] [CORE]: datagram: basic memory accounting functions Hideo AOKI
2007-12-19 3:21 ` Hideo AOKI
2007-12-20 11:43 ` David Miller
2007-12-21 4:18 ` Hideo AOKI [this message]
2007-12-21 4:31 ` David Miller
2007-12-22 0:22 ` Hideo AOKI
2007-12-18 2:38 ` [PATCH 3/4] [UDP]: add udp_mem, udp_rmem_min and udp_wmem_min Hideo AOKI
2007-12-18 2:38 ` [PATCH 4/4] [UDP]: memory accounting in IPv4 Hideo AOKI
2007-12-20 11:44 ` David Miller
2007-12-21 3:58 ` Hideo AOKI
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=476B3EAE.4070809@redhat.com \
--to=haoki@redhat.com \
--cc=andi@firstfloor.org \
--cc=billfink@mindspring.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=johnpol@2ka.mipt.ru \
--cc=mhiramat@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=satoshi.oshima.fk@hitachi.com \
--cc=shemminger@linux-foundation.org \
--cc=tyasui@redhat.com \
--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.