All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Holger Brunck <holger.brunck@keymile.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: napi layer and packet throttling
Date: Fri, 24 May 2013 13:36:49 +0100	[thread overview]
Message-ID: <1369399009.3469.273.camel@deadeye.wl.decadent.org.uk> (raw)
In-Reply-To: <519F1698.3050301@keymile.com>

On Fri, 2013-05-24 at 09:28 +0200, Holger Brunck 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.

Soft IRQs are then handled in a ksoftirqd thread, which is scheduled
like any other task (though it has high priority).

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

This is not the job of the driver (beyond using NAPI in the first
place).

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

      parent reply	other threads:[~2013-05-24 12:36 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
2013-05-24  9:39       ` Holger Brunck
2013-05-24 12:36     ` Ben Hutchings [this message]

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=1369399009.3469.273.camel@deadeye.wl.decadent.org.uk \
    --to=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.