All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: linux-3.0.x regression with ipv4 routes having mtu
Date: Mon, 19 Dec 2011 14:52:59 +0100	[thread overview]
Message-ID: <20111219135259.GK6348@secunet.com> (raw)
In-Reply-To: <4EEB5602.2060806@iki.fi>

On Fri, Dec 16, 2011 at 04:30:26PM +0200, Timo Teräs wrote:
> On 12/16/2011 02:21 PM, Steffen Klassert wrote:
> > 
> > "ip route flush cache" does not even flush the routing cache,
> > it just markes the routing cache as invalid by changing the
> > rt_genid which make the old routes invisible. And since we don't
> > have rt_check_expire() anymore, we have to wait until we have
> > collected gc_thresh (1024) useless routes before rt_garbage_collect()
> > starts to remove some of them (btw. is this intentional).
> > 
> > I think we need a trigger in rt_cache_invalidate() that expires
> > all cached pmtu values similar to the routing cache entries.
> > For a moment I thought we could just reset the __rt_peer_genid
> > value back to zero to mark all cached pmtu values as expired,
> > but that's apparently not save to do. So I came to no conclusion
> > how to fix this today. Any ideas?
> 
> Oh, right. This problem is secondary. As long as the mtu value is
> reflected properly, I'll be happy :)
> 

Well, "ip route flush cache" flushed the cached pmtu informations
in 2.6.38 and before, now it does not do it anymore. I guess
some users rely on the old behaviour, so it would be nice if we
could restore it. I think we can fix this by adding a pmtu_genid,
exactly in the same way as we have now the redirect_genid.
I'll give this a try.

  reply	other threads:[~2011-12-19 13:57 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 [this message]
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
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=20111219135259.GK6348@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.