From: Jesper Dangaard Brouer <brouer@redhat•com>
To: Rick Jones <rick.jones2@hpe•com>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Eric Dumazet <eric.dumazet@gmail•com>,
brouer@redhat•com
Subject: Re: Netperf UDP issue with connected sockets
Date: Wed, 16 Nov 2016 23:40:22 +0100 [thread overview]
Message-ID: <20161116234022.2bad179b@redhat.com> (raw)
In-Reply-To: <7c4b43a4-74bf-1ee2-6f0d-17783b5d8fcb@hpe.com>
On Wed, 16 Nov 2016 09:46:37 -0800
Rick Jones <rick.jones2@hpe•com> wrote:
> On 11/16/2016 04:16 AM, Jesper Dangaard Brouer wrote:
> > [1] Subj: High perf top ip_idents_reserve doing netperf UDP_STREAM
> > - https://www.spinics.net/lists/netdev/msg294752.html
> >
> > Not fixed in version 2.7.0.
> > - ftp://ftp.netperf.org/netperf/netperf-2.7.0.tar.gz
> >
> > Used extra netperf configure compile options:
> > ./configure --enable-histogram --enable-demo
> >
> > It seems like some fix attempts exists in the SVN repository::
> >
> > svn checkout http://www.netperf.org/svn/netperf2/trunk/ netperf2-svn
> > svn log -r709
> > # A quick stab at getting remote connect going for UDP_STREAM
> > svn diff -r708:709
> >
> > Testing with SVN version, still show __ip_select_ident() in top#1.
>
> Indeed, there was a fix for getting the remote side connect()ed.
> Looking at what I have for the top of trunk I do though see a connect()
> call being made at the local end:
>
> socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 4
> getsockopt(4, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
> getsockopt(4, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
> setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(4, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> setsockopt(4, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0
> setsockopt(4, SOL_IP, IP_RECVERR, [1], 4) = 0
> brk(0xe53000) = 0xe53000
> getsockname(4, {sa_family=AF_INET, sin_port=htons(59758),
> sin_addr=inet_addr("0.0.0.0")}, [16]) = 0
> sendto(3,
> "\0\0\0a\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\10\0\0\0\0\0\0\0\321\377\377\377\377"...,
> 656, 0, NULL, 0) = 656
> select(1024, [3], NULL, NULL, {120, 0}) = 1 (in [3], left {119, 995630})
> recvfrom(3,
> "\0\0\0b\0\0\0\0\0\3@\0\0\3@\0\0\0\0\2\0\3@\0\377\377\377\377\0\0\0\321"...,
> 656, 0, NULL, NULL) = 656
> write(1, "need to connect is 1\n", 21) = 21
> rt_sigaction(SIGALRM, {0x402ea6, [ALRM], SA_RESTORER|SA_INTERRUPT,
> 0x7f2824eb2cb0}, NULL, 8) = 0
> rt_sigaction(SIGINT, {0x402ea6, [INT], SA_RESTORER|SA_INTERRUPT,
> 0x7f2824eb2cb0}, NULL, 8) = 0
> alarm(1) = 0
> connect(4, {sa_family=AF_INET, sin_port=htons(34832),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) =
> 1024
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) =
> 1024
> sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) =
> 1024
>
> the only difference there with top of trunk is that "need to connect"
> write/printf I just put in the code to be a nice marker in the system
> call trace.
>
> It is a wild guess, but does setting SO_DONTROUTE affect whether or not
> a connect() would have the desired effect? That is there to protect
> people from themselves (long story about people using UDP_STREAM to
> stress improperly air-gapped systems during link up/down testing....)
> It can be disabled with a test-specific -R 1 option, so your netperf
> command would become:
>
> netperf -H 198.18.50.1 -t UDP_STREAM -l 120 -- -m 1472 -n -N -R 1
Using -R 1 does not seem to help remove __ip_select_ident()
Samples: 56K of event 'cycles', Event count (approx.): 78628132661
Overhead Command Shared Object Symbol
+ 9.11% netperf [kernel.vmlinux] [k] __ip_select_ident
+ 6.98% netperf [kernel.vmlinux] [k] _raw_spin_lock
+ 6.21% swapper [mlx5_core] [k] mlx5e_poll_tx_cq
+ 5.03% netperf [kernel.vmlinux] [k] copy_user_enhanced_fast_string
+ 4.69% netperf [kernel.vmlinux] [k] __ip_make_skb
+ 4.63% netperf [kernel.vmlinux] [k] skb_set_owner_w
+ 4.15% swapper [kernel.vmlinux] [k] __slab_free
+ 3.80% netperf [mlx5_core] [k] mlx5e_sq_xmit
+ 2.00% swapper [kernel.vmlinux] [k] sock_wfree
+ 1.94% netperf netperf [.] send_data
+ 1.92% netperf netperf [.] send_omni_inner
> >
> > (p.s. is netperf ever going to be converted from SVN to git?)
> >
>
> Well.... my git-fu could use some work (gentle, offlinetaps with a
> clueful tutorial bat would be welcome), and at least in the past, going
> to git was held back because there were a bunch of netperf users on
> Windows and there wasn't (at the time) support for git under Windows.
>
> But I am not against the idea in principle.
Once you have learned git, you will never go back to SVN. Just do it! :-)
Here are even nice writeups of how to convert and preserve history:
http://john.albin.net/git/convert-subversion-to-git
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2016-11-16 22:40 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 14:59 High perf top ip_idents_reserve doing netperf UDP_STREAM Jesper Dangaard Brouer
2014-09-03 15:17 ` Eric Dumazet
2016-11-16 12:16 ` Netperf UDP issue with connected sockets Jesper Dangaard Brouer
2016-11-16 17:46 ` Rick Jones
2016-11-16 22:40 ` Jesper Dangaard Brouer [this message]
2016-11-16 22:50 ` Rick Jones
2016-11-17 0:34 ` Eric Dumazet
2016-11-17 8:16 ` Jesper Dangaard Brouer
2016-11-17 13:20 ` Eric Dumazet
2016-11-17 13:42 ` Jesper Dangaard Brouer
2016-11-17 14:17 ` Eric Dumazet
2016-11-17 14:57 ` Jesper Dangaard Brouer
2016-11-17 16:21 ` Eric Dumazet
2016-11-17 18:30 ` Jesper Dangaard Brouer
2016-11-17 18:51 ` Eric Dumazet
2016-11-17 21:19 ` Jesper Dangaard Brouer
2016-11-17 21:44 ` Eric Dumazet
2016-11-17 23:08 ` Rick Jones
2016-11-18 0:37 ` Julian Anastasov
2016-11-18 0:42 ` Rick Jones
2016-11-18 17:12 ` Jesper Dangaard Brouer
2016-11-21 16:03 ` Jesper Dangaard Brouer
2016-11-21 18:10 ` Eric Dumazet
2016-11-29 6:58 ` [WIP] net+mlx4: auto doorbell Eric Dumazet
2016-11-30 11:38 ` Jesper Dangaard Brouer
2016-11-30 15:56 ` Eric Dumazet
2016-11-30 19:17 ` Jesper Dangaard Brouer
2016-11-30 19:30 ` Eric Dumazet
2016-11-30 22:30 ` Jesper Dangaard Brouer
2016-11-30 22:40 ` Eric Dumazet
2016-12-01 0:27 ` Eric Dumazet
2016-12-01 1:16 ` Tom Herbert
2016-12-01 2:32 ` Eric Dumazet
2016-12-01 2:50 ` Eric Dumazet
2016-12-02 18:16 ` Eric Dumazet
2016-12-01 5:03 ` Tom Herbert
2016-12-01 19:24 ` Willem de Bruijn
2016-11-30 13:50 ` Saeed Mahameed
2016-11-30 15:44 ` Eric Dumazet
2016-11-30 16:27 ` Saeed Mahameed
2016-11-30 17:28 ` Eric Dumazet
2016-12-01 12:05 ` Jesper Dangaard Brouer
2016-12-01 14:24 ` Eric Dumazet
2016-12-01 16:04 ` Jesper Dangaard Brouer
2016-12-01 17:04 ` Eric Dumazet
2016-12-01 19:17 ` Jesper Dangaard Brouer
2016-12-01 20:11 ` Eric Dumazet
2016-12-01 20:20 ` David Miller
2016-12-01 22:10 ` Eric Dumazet
2016-12-02 14:23 ` Eric Dumazet
2016-12-01 21:32 ` Alexander Duyck
2016-12-01 22:04 ` Eric Dumazet
2016-11-17 17:34 ` Netperf UDP issue with connected sockets David Laight
2016-11-17 22:39 ` Alexander Duyck
2016-11-17 17:42 ` Rick Jones
2016-11-28 18:33 ` Rick Jones
2016-11-28 18:40 ` Rick Jones
2016-11-30 10:43 ` Jesper Dangaard Brouer
2016-11-30 17:42 ` Rick Jones
2016-11-30 18:11 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161116234022.2bad179b@redhat.com \
--to=brouer@redhat$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rick.jones2@hpe$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox