netdev - Re: [RFC PATCH 00/29] Phase 2 of fib

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:	Tue, 24 Feb 2015 22:53:00 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	alexander.h.duyck@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC PATCH 00/29] Phase 2 of fib_trie updates

From: Alexander Duyck <alexander.h.duyck@...hat.com>
Date: Tue, 24 Feb 2015 12:47:55 -0800

> This patch series implements the second phase of the fib_trie changes.  I
> presented on these and the previous changes at Netdev01 and netconf.  The
> slides for the Netdev01 presentation can be found at
> https://www.netdev01.org/docs/duyck-fib-trie.pdf.
> 
> I'm currently debating if I should just submit the entire patch-set as-is
> or if I should hold off on submitting the last 10 patches as they currently
> have a potential performance impact in the case of a large number of
> entries placed in the local table.  Specifically I have seen that removing
> an interface in the case of 8K local subnets being configured on it
> resulted in the time for a dummy interface being removed increasing from
> about .6 seconds to 2.4 seconds.  I am not sure how common of a use-case
> something like this would be.  I have not seen the same issue if I assign
> 8K routes to the interface as I believe the fib_table_flush aggregates them
> all in to one resize action.
> 
> The entire series reduces the total look-up time by another 20-35% versus
> what is currently in the 4.0-rc1 kernel.  So for example a set of routing
> look-ups which took 140ns in the 4.0-rc1 kernel will now only take about
> 105ns after these patches.

I did a quick once-over for these changes and conceptually they look
fine.

Why are sequences of removals so much more costly now?  Is it because
of the maintainence of the information in the parent when rebalancing?

In any event, I'll say two things:

1) You should submit these changes in smaller batches anyways.
   It's easier to review and get small sets of transformations
   tested as a unit.

2) For the device removal case, we can batch the inet addr removal
   based route delete operations, and thus mitigate the rebalancing
   costs.
--
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