[Dnsmasq-discuss] [PATCH]

[Simon Kelley]

On 10/09/2021 09:37, Dominik DL6ER wrote:

> I agree this is a good solution, patch attached. I hope to have caught
> all places (I don't have the dependencies to build all possible
> combinations myself).
> 

Ah, thank you! I combined that with the one that started this thread and
committed them.

I have a tool which builds with all the possible single compile-time
options, and a good selection of combinations (every possible one would
take WAY to long) and it passes fine.

> On Thu, 2021-09-09 at 23:35 +0100, Simon Kelley wrote:
>> querystr becomes a local function to cache.c or just gets rolled into
>> log_query().
> 
> I did the former. Merging it into log_query() would make an already
> complex routine even longer.

Ack.


> 
> 
> Concerning performance: The loop can at most iterate over 89 entries
> before it says: "Didn't find". However, for the vast vast majority of
> cases, the match will be in the first 30ish (AAAA and SRV) as query
> types behind those are not very likely to be seen. The loop breaks as
> soon as the match is found. Looking at the gcc11 x86_64 -O2 assembly,
> there are no surprises, only very few assembler instructions per
> iteration are needed. The next type integers in the table can always be
> found 16 bytes after the former. Hence, we just need
> 
> .FOR_LOOP
>         add     rax, 1
>         cmp     rax, 89
>         je      .NOT_FOUND
>         mov     rdx, rax
>         movsx   rcx, eax
>         sal     rdx, 4
>         cmp     DWORD PTR typestr[rdx], r1d
>         jne     .FOR_LOOP
> 	[... stuff if found ...]
> 
> Given we call library functions like strlen() and sprintf(), our loop
> here is surely not any kind of bottleneck. Even if it'd be even larger.

Agreed. It's pretty difficult to get into trouble with O(N) where N is
constant and magnitude three.


Cheers,

Simon.



tagged 2.87-test1 just to get 2.87 into the version string.


Petr - I shall work though your coverity-originated patches as I get
time in the next day or two.