We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The recvfrom test in udp_sink is probably identical to recv, because as it doesn't request the source address.
recvfrom
recv
Based on discussion: https://lore.kernel.org/netdev/[email protected]
From: Jesper Dangaard Brouer - Sent: 28 November 2019 11:12 ...
Can you test recv() as well? Sure: 9e3c8b86a2d662
Can you test recv() as well?
Sure: 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 think it might be faster than read().
Slightly, but same speed as recvfrom.
From: David Laight [email protected]
I notice that you recvfrom() code doesn't request the source address. So is probably identical to recv().
The text was updated successfully, but these errors were encountered:
netoptimizer
No branches or pull requests
The
recvfrom
test in udp_sink is probably identical torecv
, because as it doesn't request the source address.Based on discussion:
https://lore.kernel.org/netdev/[email protected]
From: Jesper Dangaard Brouer - Sent: 28 November 2019 11:12
...
From: David Laight [email protected]
The text was updated successfully, but these errors were encountered: