[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b71441bb2fa14bc7b583de643a1ccf8b@AcuMS.aculab.com>
Date: Thu, 28 Nov 2019 16:37:01 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jesper Dangaard Brouer' <brouer@...hat.com>
CC: 'Marek Majkowski' <marek@...udflare.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
network dev <netdev@...r.kernel.org>,
kernel-team <kernel-team@...udflare.com>,
Paolo Abeni <pabeni@...hat.com>
Subject: RE: epoll_wait() performance
From: Jesper Dangaard Brouer
> Sent: 28 November 2019 11:12
...
> > Can you test recv() as well?
>
> Sure: https://github.com/netoptimizer/network-testing/commit/9e3c8b86a2d662
>
> $ sudo taskset -c 1 ./udp_sink --port 9 --count $((10**6*2))
> run count ns/pkt pps cycles payload
> recvMmsg/32 run: 0 2000000 653.29 1530704.29 2351 18 demux:1
> recvmsg run: 0 2000000 631.01 1584760.06 2271 18 demux:1
> read run: 0 2000000 582.24 1717518.16 2096 18 demux:1
> recvfrom run: 0 2000000 547.26 1827269.12 1970 18 demux:1
> recv run: 0 2000000 547.37 1826930.39 1970 18 demux:1
>
> > I think it might be faster than read().
>
> Slightly, but same speed as recvfrom.
I notice that you recvfrom() code doesn't request the source address.
So is probably identical to recv().
My test system tends to increase its clock rate when busy.
(The fans speed up immediately, the cpu has a passive heatsink and all the
case fans are connected (via buffers) to the motherboard 'cpu fan' header.)
I could probably work out how to lock the frequency, but for some tests I run:
$ while :; do :; done
Putting 1 cpu into a userspace infinite loop make them all run flat out
(until thermally throttled).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists