netdev - Re: linux-3.0.x regression with ipv4 routes having mtu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Dec 2011 09:47:37 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
Cc:	timo.teras@....fi, netdev@...r.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu

On Thu, Dec 22, 2011 at 01:51:27PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@...unet.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?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html