All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: hans.schillstrom@ericsson.com, daniel.lezcano@free.fr,
	netdev@vger.kernel.org, Octavian Purdila <opurdila@ixiacom.com>
Subject: Re: BUG ? ipip unregister_netdevice_many()
Date: Thu, 14 Oct 2010 11:35:31 -0700	[thread overview]
Message-ID: <m1lj60oc5o.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20101014.080907.189690627.davem@davemloft.net> (David Miller's message of "Thu, 14 Oct 2010 08:09:07 -0700 (PDT)")

David Miller <davem@davemloft.net> writes:

> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Wed, 13 Oct 2010 22:20:28 -0700
>
>> With the network namespace support we limit the scope of the test of
>> the invalidate to just a single network namespace, and as such
>> rt_is_expired stops being true for every cache entry.  So we cannot
>> unconditionally throw away entire chains.
>> 
>> All of which can be either done by network namespace equality or by
>> rt_is_expired().  Although Denis picked rt_is_expired() when he made
>> his change.
>
> Right, and I choose to use namespace equality which will completely
> compile into no code at all when namespace support is not in the
> kernel.
>
> Therefore, making the non-namespace case equivalent and as efficient
> as it always was.

Almost you still have the hash list inversion, which means you have
to at look at the rtable entry even on a one list long hash chain.
Perhaps I am looking at it wrong but once you look at the entries
I don't see the difference in the number of cache line faults
between one variant of the code and the other.

>> The only place it makes a noticable difference in practice is what
>> happens when we do batched deleletes of lots of network devices in
>> different network namespaces.
>> 
>> During batched network device deletes in fib_netdev_event we do
>> rt_cache_flush(dev_net(dev), -1) for each network device.  and then a
>> final rt_cache_flush_batch() to remove the invalidated entries.  These
>> devices can be from multiple network namespaces, so I suspect that is
>> a savings worth having.
>
> How can it make a real difference even in this case?  We'll obliterate
> all the entries, and then on subsequent passes we'll find nothing
> matching that namespace any more.
>
> Show me performance tests that show it makes any difference, please.

Octavian did you happen to measure the performance difference when you
added batching of routing table flushes?

>> So if we are going to change the tests we need to do something with
>> rt_cache_flush_batch().  Further I do not see what is confusing about
>> a test that asks if the routing cache entry is unusable.  Is
>> rt_cache_expired() a bad name?
>
> It's not a bad name, it's just an unnecessary test that we don't need
> to even make in this specific place.

As long as we do something that is correct in the batched flush case
I am happy either way.

Eric

  reply	other threads:[~2010-10-14 18:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07  8:48 BUG ? ipip unregister_netdevice_many() Hans Schillstrom
2010-10-08 11:19 ` Daniel Lezcano
2010-10-08 11:53   ` Hans Schillstrom
2010-10-08 12:28     ` Hans Schillstrom
2010-10-08 15:53       ` Daniel Lezcano
2010-10-08 16:17         ` Daniel Lezcano
2010-10-08 16:58           ` Eric W. Biederman
2010-10-08 17:29             ` Daniel Lezcano
2010-10-08 17:47               ` Daniel Lezcano
2010-10-08 16:45       ` Eric W. Biederman
2010-10-08 17:20         ` David Miller
2010-10-08 17:32           ` Eric W. Biederman
2010-10-12 20:05             ` David Miller
2010-10-13 11:19               ` Jarek Poplawski
2010-10-13 21:58                 ` David Miller
2010-10-14  6:41                   ` Hans Schillstrom
2010-10-13 22:16               ` Daniel Lezcano
2010-10-13 23:23                 ` David Miller
2010-10-14  3:57                   ` Eric Dumazet
2010-10-14 23:28                     ` Paul E. McKenney
2010-10-14  4:40               ` Eric W. Biederman
2010-10-14  4:50                 ` David Miller
2010-10-14  5:20                   ` Eric W. Biederman
2010-10-14 15:09                     ` David Miller
2010-10-14 18:35                       ` Eric W. Biederman [this message]
2010-10-08 16:51   ` Eric W. Biederman
2010-10-08 16:06 ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2010-10-14 19:21 Octavian Purdila

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=m1lj60oc5o.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=daniel.lezcano@free.fr \
    --cc=davem@davemloft.net \
    --cc=hans.schillstrom@ericsson.com \
    --cc=netdev@vger.kernel.org \
    --cc=opurdila@ixiacom.com \
    /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.