All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suprasad Mutalik Desai <suprasad.desai@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, davem@davemloft.ne
Subject: Re: Linux stack performance drop (TCP and UDP) in 3.10 kernel in routed scenario
Date: Thu, 5 Jun 2014 07:47:48 +0530	[thread overview]
Message-ID: <CAJMXqXZV+tGPi5_d-ndeLYfx-yV6WiyDRBaqMcs0dYNTKfZHrw@mail.gmail.com> (raw)
In-Reply-To: <20140604.121819.2149110045488849780.davem@davemloft.net>

Hi David,

On Thu, Jun 5, 2014 at 12:48 AM, David Miller <davem@davemloft.net> wrote:
> From: Suprasad Mutalik Desai <suprasad.desai@gmail.com>
> Date: Wed, 4 Jun 2014 14:34:10 +0530
>
>> I guess plain routing scenario was NOT thought through while removing
>> the routing cache code.
>
> It is exactly the scenerio that was considered.
>
> The routing cache was susceptible to trivial denial of service
> attacks, it therefore had to be removed.
>
> It also scaled poorly with large numbers of active flows.

Based on your and Eric's explanation , i clearly understand the
purpose of removing route cache.

But as there was no alternative proposed after removing route cache
mechanism, this is causing a side effect of low throughput in an
embedded router scenario with limited cache and memory resources. With
a limited cache in an embedded router environment checking the routing
table for the dst for every packet (routed scenario) is a heavy
operation which can lead to poor stack  performance.

So, I request you to please suggest on how to address this topic w.r.t
embedded devices ( routers) which has limited memory resources ?

Thanks and Regards,
Suprasad.

  reply	other threads:[~2014-06-05  2:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJMXqXZQ_S27LCZNJDjcQ9jy2qyJ0UT2nk+wdZOTQep+5rQZhQ@mail.gmail.com>
2014-06-04  9:04 ` Fwd: Linux stack performance drop (TCP and UDP) in 3.10 kernel in routed scenario Suprasad Mutalik Desai
2014-06-04 12:34   ` Eric Dumazet
2014-06-04 13:53     ` Suprasad Mutalik Desai
2014-06-04 14:59       ` Eric Dumazet
2014-06-04 16:34         ` Eric Dumazet
2014-06-04 18:03           ` Suprasad Mutalik Desai
2014-06-04 17:41         ` Suprasad Mutalik Desai
2014-06-04 18:26         ` sowmini varadhan
2014-06-04 18:32           ` Neal Cardwell
2014-06-04 18:44           ` Eric Dumazet
2014-06-04 19:18   ` David Miller
2014-06-05  2:17     ` Suprasad Mutalik Desai [this message]
2014-06-05  6:08       ` David Miller
2014-06-05  6:32       ` Eric Dumazet
2014-06-04  9:14 Suprasad Mutalik Desai
2014-06-04 14:12 ` David Laight
2014-06-04 17:46   ` Suprasad Mutalik Desai

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=CAJMXqXZV+tGPi5_d-ndeLYfx-yV6WiyDRBaqMcs0dYNTKfZHrw@mail.gmail.com \
    --to=suprasad.desai@gmail.com \
    --cc=davem@davemloft.ne \
    --cc=davem@davemloft.net \
    --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.