From: Steffen Klassert <steffen.klassert@secunet.com>
To: David Miller <davem@davemloft.net>
Cc: timo.teras@iki.fi, netdev@vger.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu
Date: Fri, 23 Dec 2011 09:47:37 +0100 [thread overview]
Message-ID: <20111223084737.GU6348@secunet.com> (raw)
In-Reply-To: <20111222.135127.1577166695312077920.davem@davemloft.net>
On Thu, Dec 22, 2011 at 01:51:27PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Thu, 22 Dec 2011 11:25:26 +0100
>
> > Actually, I'm getting some doubts on the concept of caching
> > the metrics on the inetpeer. How should we handle the case when
> > we have multiple routes with different metrics to the same
> > destination? As it is, we can cache just one of them on the
> > inetpeer.
>
> In such cases the metrics won't be perfect.
>
> Actually, we have two kinds of metrics and it might be best in the
> long term to seperate them out explicitly.
>
> We have "loose" metrics (such as all the TCP measurements) which,
> if incorrect, will lead to suboptimal performance but will not
> dramatically effect connectivity.
>
> Then we have "strict" metrics like PMTU information and redirects,
> which could have more fatal consequences if wrong.
>
> The core issue is I want to keep these things tied only to destination
> address, it is the only sane way to get the routing cache removed.
>
> Sockets and the packet forwarding path in the future will be using
> routes that cover whole subnets, or even the default route. There
> will be no "rt->rt_dst" and there will also be not attached inetpeer.
>
> The inetpeer, or something like it, will be managed seperately.
> Therefore metrics will need to be calculated using both objects (rt
> and inetpeer).
>
> This is one of the longer term design issues we face in the routing
> cache removal and for which I don't have exact plans for yet. I'm
> still concentrating on "ref-less" neighbour entries, so once I finish
> that work I can think more seriously about metrics in a world without
> the routing cache.
Ok, so let's try to keep the things working as good as possible at this
intermediate stage and see how it evolves. I know that you want to remove
the routing cache, but I did not care too much in the beginning. So I
missed the reason why you want to do that. Could you please give a short
explaination or point me to where I can find this informations?
next prev parent reply other threads:[~2011-12-23 8:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 15:54 linux-3.0.x regression with ipv4 routes having mtu Timo Teräs
2011-12-14 17:50 ` David Miller
2011-12-14 17:57 ` Eric Dumazet
2011-12-14 18:22 ` Timo Teräs
2011-12-15 13:49 ` Steffen Klassert
2011-12-16 12:21 ` Steffen Klassert
2011-12-16 14:30 ` Timo Teräs
2011-12-19 13:52 ` Steffen Klassert
2011-12-19 20:09 ` David Miller
2011-12-20 8:03 ` Steffen Klassert
2011-12-19 21:10 ` David Miller
2011-12-20 6:53 ` Timo Teräs
2011-12-20 7:03 ` David Miller
2011-12-20 7:18 ` Steffen Klassert
2011-12-20 18:35 ` David Miller
2011-12-21 8:56 ` Steffen Klassert
2011-12-21 20:56 ` David Miller
2011-12-22 10:25 ` Steffen Klassert
2011-12-22 18:51 ` David Miller
2011-12-23 8:47 ` Steffen Klassert [this message]
2011-12-23 9:00 ` David Miller
2011-12-23 8:58 ` Steffen Klassert
2012-02-02 10:01 ` Steffen Klassert
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=20111223084737.GU6348@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=timo.teras@iki.fi \
/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.