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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).