Netdev List
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: eric.dumazet@gmail.com, christoph.paasch@uclouvain.be,
	netdev@vger.kernel.org, ycheng@google.com, ja@ssi.bg
Subject: Re: [PATCH net-next v2 2/5] tcp: metrics: Add source-address to tcp-metrics
Date: Sat, 11 Jan 2014 00:10:59 +0100	[thread overview]
Message-ID: <20140110231059.GA30388@order.stressinduktion.org> (raw)
In-Reply-To: <20140110.173711.1541969326146414340.davem@davemloft.net>

On Fri, Jan 10, 2014 at 05:37:11PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 08 Jan 2014 15:13:46 -0800
> 
> > On Wed, 2014-01-08 at 23:43 +0100, Christoph Paasch wrote:
> >> Hello Eric,
> >> 
> >> On 08/01/14 - 09:55:51, Eric Dumazet wrote:
> >> > On Wed, 2014-01-08 at 16:05 +0100, Christoph Paasch wrote:
> >> > > We add the source-address to the tcp-metrics, so that different metrics
> >> > > will be used per source/destination-pair. We use the destination-hash to
> >> > > store the metric inside the hash-table. That way, deleting and dumping
> >> > > via "ip tcp_metrics" is easy.
> >> > 
> >> > Note that this has the following problem :
> >> > 
> >> > Some applications use a set of source IP addresses to overcome the 64K
> >> > port limitation.
> >> 
> >> Ok, did not know about that.
> >> 
> >> > tcp_metrics uses a hard-coded TCP_METRICS_RECLAIM_DEPTH value of 5,
> >> > meaning that cache wont be able to store more than 5 source IP addresses
> >> > (reaching one particular remote IP).
> >> 
> >> Maybe we could do something like the below (yet untested). That way we allow
> >> up to 32 entries with the same destination but different source and still
> >> only 5 with different destinations.
> >> 
> >> I guess 32 * 64K connections is enough. :)
> >> We could also make TCP_METRICS_RECLAIM_DEPTH(_DST) a tunable.
> > 
> > Well, not sure if this is a problem anyway, and if we want extra
> > complexity for this rare use case, considering tcp metrics for
> > high number of flows sharing a common path is unlikely to be useful
> > (with exception of Fast Open, but again it must be rare)
> 
> I think we are overthinking this, even for the aforementioned case.
> 
> If people report that this is a real problem they are hitting, and
> not just with constructed test cases, we can work on a solution.

I was thinking if this would be a problem then one could switch to not
use the source address but something like the interface group index as
the additional match. Seems to fit into the weak end host model.

Greetings,

  Hannes

  reply	other threads:[~2014-01-10 23:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 15:05 [PATCH net-next v2 0/5] Make tcp-metrics source-address aware Christoph Paasch
2014-01-08 15:05 ` [PATCH net-next v2 1/5] tcp: metrics: rename tcpm_addr to tcpm_daddr Christoph Paasch
2014-01-08 15:05 ` [PATCH net-next v2 2/5] tcp: metrics: Add source-address to tcp-metrics Christoph Paasch
2014-01-08 17:55   ` Eric Dumazet
2014-01-08 22:43     ` Christoph Paasch
2014-01-08 23:13       ` Eric Dumazet
2014-01-10 22:37         ` David Miller
2014-01-10 23:10           ` Hannes Frederic Sowa [this message]
2014-01-08 15:05 ` [PATCH net-next v2 3/5] tcp: metrics: New netlink attribute for src IP and dumped in netlink reply Christoph Paasch
2014-01-08 15:05 ` [PATCH net-next v2 4/5] tcp: metrics: Delete all entries matching a certain destination Christoph Paasch
2014-01-08 15:05 ` [PATCH net-next v2 5/5] tcp: metrics: Allow selective get/del of tcp-metrics based on src IP Christoph Paasch
2014-01-10 22:38 ` [PATCH net-next v2 0/5] Make tcp-metrics source-address aware David Miller

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=20140110231059.GA30388@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=christoph.paasch@uclouvain.be \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=ja@ssi.bg \
    --cc=netdev@vger.kernel.org \
    --cc=ycheng@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox