[Dnsmasq-discuss] Fix RNG entropy reuse, replace SURF with ChaCha8

[Geert Stappers]

On Wed, Oct 09, 2024 at 12:03:12PM +0300, Leonid Evdokimov wrote:
> > I have seen the patches. But I could not seen the improvement they bring.
> 
> Ah, sorry, my bad, I've not provided enough context. Thanks for the reminder.
 
     :-)


> As I've said earlier, my goal is to support a use-case of having a
> list of ≈400'000 domains in --server and --ipset lists while running
> on a low-end OpenWRT router having 64 MiB of RAM (or running similar
> code on iPhone VPN app supporting split tunneling). The meta-goal is
> to provide one more tool to the software toolset supporting state
> censorship circumvention...

Acknowledge


> Other projects like Pi-Hole and router-level ad-blockers
> might benefit from this code, but it's hard for me to gauge.

Time will tell

 
> I've developed a few patch stacks to achieve the goal:
> - cleaning up code to reduce RAM usage with low-hanging fruits like
> struct padding elimination. I've observed 30% smaller RSS overhead for
> my use-case
> - further RSS reduction: domain strings interning to store a domain
> duplicated between --server and --ipset just once
> - improving startup latency from several seconds to hundreds of
> milliseconds inlining qsort()
> - trading 1% of RSS for 20x faster domain lookup: replacing bsearch()
> with a mix of hash table lookup and binary search
> - increase code size a bit and gain a bit more speed using a CPU
> cache-aware binary search
> - moving those thousands of domains into a mmap()'able read-only trie
> file trading a bit of lookup latency for another ~3x memory reduction
> - fixing bugs if/when I spot them
> 
> Some of these stacks are ready for review, some are at
> working-prototype stage, string interning and cache-aware bsearch are
> yet to be written.
> 
> I've decided to submit all those patch stacks starting with the least
> controversial one, fixing a probably-minor security bug and improving
> code size a bit.
> 
> My goal of this specific submission is to reduce my local patch-stack
> to ease further rebasing & merging.
> 
> I would be happy to see those patches either merged or declined
> explicitly, but it's not up to me to decide. :-)

So true.


To prevent the patches getting lost in the mailinglist archive,
have I saved them in a local branch. What would be a good name
for that git branch? My plan is to make the carrying git repository
public available.


Groeten
Geert Stappers
-- 
Silence is hard to parse