3 Dub
2019
3 Dub
'19
12:28
Hi,
We don't have any developer guide. In general, every network card has different
characteristic and features, so it's almost impossible to provide a comprehensive
manual for that.
Daniel
On 4/3/19 11:53 AM, Sergey Petrov wrote:
On Wed, 2019-04-03 at 10:52 +0200, Petr Špaček wrote:
On 03. 04. 19 10:45, Sergey Petrov wrote:
The source machne is about 15% utilized.
./dnsperf -s 10.0.0.4 -d out -n 20 -c 512 -T 512 -t 500 -S 1 -q 1000 -D
get us some performance penalty (260000 rps VS 310000 rps) and more even
distribution across all cores with 100% usages of all eight cores on
last CPU socket. While other CPU socket cores are aproximately 60%
loaded.
Using "-c 1000 -T 1000" parameters of dnsperf i see practicaly the same
core load distribution and even more performance penalty.
Using "-c 16 -T 16" parameters i see 14 0% utilized cores, 16 100%
utilized cores and 2 50% utilized cores with about 300000 rps
The question is that prevents knot thread on 0% used core to serve a
packet arrived with IRQ bounded to another core? May be you have some
developer guide can answer this question?
I perfoms benchmarks with knot-dns as a
authoritative server and dnsperf
as a workload client. Knot server has 32 cores. Interrupts from 10Gb
network card are spreaded across all 32 cores. Knot configured with
64 udp-workers. Each knot thread assigned to one core. So there are at
least two knot threads assigned to one core. Then i start dnsperf with
command
./dnsperf -s 10.0.0.4 -d out -n 20 -c 103 -T 64 -t 500 -S 1 -q 1000 -D
htop on knot server shows 3-4 cores completly unused. Then i restart
dnsperf unused cores are changes.
That is the reason for unused core?
Well, sometimes dnsperf is too slow :-)
I recommend to check this:
- Make sure dnsperf ("source machine") is not 100 % utilized.
- Try to increase number of sockets used by dnsperf, i.e. -c parameter.
I would try also values like 500 and 1000 to see if it makes any
difference. It might change results significantly because Linux kernel
is using hashes over some packet fields and low number of sockets might
result in uneven query distribution.
Please let us know what are your new results.