netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: herbert@gondor.apana.org.au
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
Date: Mon, 29 Mar 2010 15:15:39 -0700 (PDT)	[thread overview]
Message-ID: <20100329.151539.216335891.davem@davemloft.net> (raw)
In-Reply-To: <20100328143235.GA16694@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 28 Mar 2010 22:32:35 +0800

> Instead of placing the metrics into the inetpeer, we create a new
> global cache for them (let's call it the metrics cache for now).
> However, we don't actually populate this cache every time we create
> an rt object.  Instead, we only create an entry in this cache
> when an event requires it, e.g., when we receive a PMTU message.
> 
> In order for this to then propagate to the rt objects, we increment
> a genid in the inetpeer cache for the corresponding host.  This
> genid is then checked by the rt object every time.  When it is
> out of step, the rt object can perform a lookup in the metrics cache
> to get the latest data.
> 
> Of course once an rt object has a pointer to an entry in the metrics
> cache it doesn't need to check the genid anymore, until the metrics
> data expires at which point this process can be repeated.

Interesting idea, but there is the issue of how to fill in
new metrics cache entries when these requests come in later.

We'd have to retain a pointer to the routing table fib entry.
This is because the fib entry states what the initial metric
values need to be for cached routes.

So we'd need a pointer to the fib_info in the routing cache entry, and
this pointer would need to grab a reference to the fib_info.  And this
subsequently leads to the question of what to do for route changes
(f.e. hold the fib_info around until all the route cache entries drop
their references and have a dead state in the fib_info struct that can
be checked, and if we find it dead what can we even do as the route
we're working with might be cached in a socket or similar)

The other option is to relookup the FIB, but we'd then have to
validate that the route cache entry we're working with matches
precisely still, and also this lookup alone going to have non-trivial
cost :-)

It's really depressing how hard it is to untangle the way we have
things currently setup, isn't it. :-)


  parent reply	other threads:[~2010-03-29 22:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-28  3:31 [PATCH RFC] inetpeer: Support ipv6 addresses David Miller
2010-03-28  4:06 ` David Miller
2010-03-28  8:22 ` Herbert Xu
2010-03-28 12:53   ` David Miller
2010-03-28 13:11     ` Herbert Xu
2010-03-28 13:40       ` David Miller
2010-03-28 13:59         ` Herbert Xu
2010-03-28 14:32           ` Herbert Xu
2010-03-29 15:08             ` Herbert Xu
2010-03-29 22:15             ` David Miller [this message]
2010-03-30 12:34               ` Herbert Xu
2010-03-29 22:21           ` David Miller
2010-03-31  5:43           ` Eric W. Biederman
2010-03-31  5:44           ` Eric W. Biederman

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=20100329.151539.216335891.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    /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).