[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <476596ED.7040304@redhat.com>
Date: Sun, 16 Dec 2007 16:21:49 -0500
From: Hideo AOKI <haoki@...hat.com>
To: David Miller <davem@...emloft.net>
CC: herbert@...dor.apana.org.au, netdev@...r.kernel.org,
tyasui@...hat.com, mhiramat@...hat.com,
satoshi.oshima.fk@...achi.com, billfink@...dspring.com,
andi@...stfloor.org, johnpol@....mipt.ru,
shemminger@...ux-foundation.org, yoshfuji@...ux-ipv6.org,
yumiko.sugita.yf@...achi.com, haoki@...hat.com
Subject: Re: [PATCH 0/4] [UDP]: memory accounting and limitation (take 10)
David Miller wrote:
> From: Hideo AOKI <haoki@...hat.com>
> Date: Sat, 15 Dec 2007 00:07:44 -0500
>
>> Changelog take 9 -> take 10:
>> * supported using sk_forward_alloc
>> * introduced several memory accounting functions with spin lock
>> * changed detagram receive functions to be able to customize
>> destructor
>> * fixed accounting bugs in previous takes
>
> This is not what Herbert and I meant with our suggestion.
>
> We meant to convert all of UDP and datagram handling to lock
> sockets precisely like TCP does, by calling lock_sock()
> on entry to functions like udp_recvmsg() and release_sock()
> on exit from those functions.
>
> Then in the packet input processing, a sequence, just like
> TCP, such as:
>
> bh_lock_sock_nested(sk);
> if (!sock_owned_by_user(sk)) {
> udp_do_rcv(sk, skb);
> } else
> sk_add_backlog(sk, skb);
>
> Then a suitably defined ->backlog_rcv is hooked up for these
> protocols as well.
>
> Again, use TCP as a guide.
>
> There is much more work involved to implement this properly,
> and make the accounting code sharable with TCP, than the
> simplistic and minimal spin lock code you added here.
>
> Please do this correctly, thank you.
Hello,
I appreciate your suggestions.
I'll try to re-implement locking mechanism like TCP.
Regards,
Hideo
--
Hitachi Computer Products (America) Inc.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists