lots of useless recvfrom() calls

[Lennert Buytenhek]

On Thu, Jun 07, 2018 at 10:31:35AM +0300, Lennert Buytenhek wrote:

> Maybe the more interesting comparison would be dns_ioevent() versus
> dns_ioevent_mmsg(), for the edge triggered poll loop case, because
> recvmmsg() does allow avoiding the useless final EAGAIN recvfrom()
> for every poll iteration.

I did some microbenchmarks for this, comparing the recvfrom-until-EAGAIN
and recvmmsg loops, where the number of buffers passed to recvmmsg is 2,
with one outstanding query:

x stock.user
+ mmsg.user
    N           Min           Max        Median           Avg        Stddev
x 5048          0.13          0.93          0.56    0.55809033    0.10621073
+ 5141          0.14          0.89          0.54    0.54154834   0.098355817
Difference at 99.5% confidence
	-0.016542 +/- 0.00626489
	-2.96404% +/- 1.12256%
	(Student's t, pooled s = 0.102323)

and:

x stock.system
+ mmsg.system
    N           Min           Max        Median           Avg        Stddev
x 5048          0.36          2.52           1.5     1.5105784    0.29788439
+ 5141          0.37          2.47          1.53     1.5359872      0.297833
Difference at 99.5% confidence
	0.0254087 +/- 0.0182369
	1.68205% +/- 1.20728%
	(Student's t, pooled s = 0.297858)

In other words, using recvmmsg() with two buffers saves ~2.9% user time
over recvfrom-until-EAGAIN (probably due to the halving of the number of
system calls), but uses ~1.6% more system time (presumably because the
kernel recvmmsg handling code is slower than that of recvfrom).  I'll
leave the test running for a while longer to get better intervals, but
since the numbers seem better overall, it probably means that we can
silently use recvmmsg() instead of recvfrom() behind the scenes if it
is available.

I'll do some tests with different recvmmsg buffer counts to see whether
there is a measurable performance difference there, and I'll try to
figure out how likely it is that we'll receive a given number of DNS
replies in one poll cycle for a given number of oustanding queries.
Based on that, we can probably decide on what the best way to go is,
and I should be able to produce a patchset that does the right thing
for level triggered and edge triggered poll methods.