From: "devendra.aaru" <devendra.aaru@gmail.com>
To: Holger Brunck <holger.brunck@keymile.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>, netdev@vger.kernel.org
Subject: Re: napi layer and packet throttling
Date: Fri, 24 May 2013 14:50:42 +0530 [thread overview]
Message-ID: <CAHdPZaPChc_EUW_Y+Dvu16nsAGZpe00BRm08-2NW=p+8hDt1yA@mail.gmail.com> (raw)
In-Reply-To: <519F1698.3050301@keymile.com>
On Fri, May 24, 2013 at 12:58 PM, Holger Brunck
<holger.brunck@keymile.com> wrote:
> Hi Ben,
>
> 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.
>
> Regards
> Holger
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-05-24 9:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 11:52 napi layer and packet throttling Holger Brunck
2013-05-23 22:27 ` Ben Hutchings
2013-05-24 7:28 ` Holger Brunck
2013-05-24 9:20 ` devendra.aaru [this message]
2013-05-24 9:39 ` Holger Brunck
2013-05-24 12:36 ` Ben Hutchings
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='CAHdPZaPChc_EUW_Y+Dvu16nsAGZpe00BRm08-2NW=p+8hDt1yA@mail.gmail.com' \
--to=devendra.aaru@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=holger.brunck@keymile.com \
--cc=netdev@vger.kernel.org \
/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.