netdev - Re: napi layer and packet throttling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <519F3537.8050603@keymile.com>
Date:	Fri, 24 May 2013 11:39:03 +0200
From:	Holger Brunck <holger.brunck@...mile.com>
To:	"devendra.aaru" <devendra.aaru@...il.com>
CC:	Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org
Subject: Re: napi layer and packet throttling

On 05/24/2013 11:20 AM, devendra.aaru wrote:
> On Fri, May 24, 2013 at 12:58 PM, Holger Brunck
>>
>> On 05/24/2013 12:27 AM, Ben Hutchings wrote:
>>> On Thu, 2013-05-23 at 13:52 +0200, Holger Brunck wrote:
>>>> b) Packet-Throttling
>>>> Here the description says "NAPI-compliant drivers can often cause packets to be
>>>> dropped in the network adaptor itself, before the kernel sees them at all."
>>>>
>>>> This is exactly what I need for my usecase. But I don't see any hints how this
>>>> can be implemented with the napi layer.
>>> [...]
>>>
>>> If the RX ring is not cleaned and refilled quickly enough, the network
>>> controller will naturally start to drop packets.  It's not something you
>>> should do explicitly in the driver.
>>>
>>
>> yes. But what if the remaining amount of packets which are getting through the
>> napi_poll function into the linux system are still to many and generate
>> therefore a to high softirq load on the system which leads to the problems I
>> see. Ok I could use a smaller amount of RX ring buffers, but then the system
>> would get more intolerant for RX bursts what I don't want. I would like to
>> protect the system if someone sends continuously a high packet rate to the
>> interface, similar to DoS attacks.
> 
> 
> what if i measure no. of packets over a period of time and find the
> rate of arrival (packets/msec) and if that rate is greater than the
> choosen rate, allow only packets that are in the window that you can
> accept, This window can be time window or the number of packets (like
> 1 packet in 10 usec or 1 packet out of 100 packets). Like wise this
> measurement can be repeated after every full period.
> 

thats similar to what I have implemented in ucc_geth.c for my workspace and yes
whith such a mechanism my problems seems to be fixed. But I still ask myself if
there is a common approach for such a problem already implemented in similar
drivers...

Regards
Holger



--
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