[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46FBFBB1.2020503@redhat.com>
Date: Thu, 27 Sep 2007 14:51:29 -0400
From: Hideo AOKI <haoki@...hat.com>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
CC: Satoshi OSHIMA <satoshi.oshima.fk@...achi.com>,
netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org
Subject: Re: [RFC/PATCH 0/3] UDP memory usage accounting
Hello,
Apologies for late response.
Evgeniy Polyakov wrote:
> Hi.
>
> On Fri, Sep 21, 2007 at 09:18:07PM +0900, Satoshi OSHIMA (satoshi.oshima.fk@...achi.com) wrote:
>> This patch set try to introduce memory usage accounting for
>> UDP(currently ipv4 only).
>>
>> Currently, memory usage of UDP can be observed as the sam of
>> usage of tx_queue and rx_queue. But I believe that the system
>> wide accounting is usefull when heavy loaded condition.
>>
>> In the next step, I would like to add memory usage quota
>> for UDP to avoid unlimited memory consumption problem
>> under DDOS attack.
>
> Could you please desribed such attack in more details?
> Each UDP socket has its queue length which can not be exceeded
> (roughly), no new sockets are created when remote side sends a packet
> (like after special steps in TCP), so where is possibility to eat all
> the mem?
I think Satoshi will answer this question soon.
>> This patch set is for 2.6.23-rc7.
>
> I seriously doubt you want to put udp specific hacks and zillions of
> atomic ops all around the code just to know exact number of bytes eaten
> for UDP.
I'll revise the patch to reduce the number of atomic operations.
> Please use udp specific code (like udp_sendmsg()) for proper accounting
> if you need that, but not hacks in generic ip code.
As far as I know, Satoshi is improving this part right now. Please wait his
response.
Many thanks for your comments.
Best regards,
Hideo Aoki
--
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