From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org,
"Daniel Krüger" <daniel.krueger@systec-electronic.com>
Subject: Re: wrong CAN frame order in network layer due to SMP?
Date: Wed, 30 Nov 2016 08:23:41 +0100 [thread overview]
Message-ID: <2577568.MH2UfL0Ils@ws-stein> (raw)
In-Reply-To: <45353231-7efa-7feb-b52d-569a88317cdf@hartkopp.net>
On Tuesday 29 November 2016 20:48:09, Oliver Hartkopp wrote:
> Hello Alexander,
>
> On 11/29/2016 11:30 AM, Alexander Stein wrote:
> > On Monday 28 November 2016 21:36:09, Oliver Hartkopp wrote:
> >> IIRC Wireshark puts the PF_PACKET socket into some special 'tpacket'
> >> mode and I don't know whether this has any impact on frame ordering.
> >>
> >> At least you may check for:
> >> https://github.com/linux-can/can-tests/blob/master/tst-packet.c
> >>
> >> ... if there's a difference between PF_PACKET and PF_CAN with your OOO
> >> setup.
> >
> > Nope, apparently there is no difference. Got similar results.
> >
> > On a side note: I captured an 30 seconds iperf3 run with wireshark 2.2.2
> > using the "ASIX Electronics Corp. AX88179 Gigabit Ethernet" adapter
> > (driver: ax88179_178a).
> > AFAICS this driver (well usbnet in the end) doesn't use NAPI either and
> > therefore unsurprisingly I got OOO of TCP frames.
> > IMHO this is not acceptable at all.
>
> Did you have a TCP socket on the receiving host as endpoint for your
> communication?
Yep. straight iperf3 run. Here is a snippet from the wireshark capture:
82102 0.759823467 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79054502 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82103 0.759823627 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79055950 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82104 0.759831475 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79057398 Win=677760 Len=0 TSval=411321994 TSecr=409657
82105 0.759823818 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79057398 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82106 0.759823894 192.168.8.7 192.168.8.128 TCP 34564→5201 [ACK] Seq=79058846 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82107 *REF* 192.168.8.128 192.168.8.7 TCP 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657
82108 -0.000012137 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78738838 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82109 0.000003981 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#1] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78738838 SRE=78740286
82110 -0.000011999 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78740286 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82111 0.000007932 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#2] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321994 TSecr=409657 SLE=78740286 SRE=78741734
82112 0.000066782 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78741734 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82113 0.000069480 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#3] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78741734 SRE=78743182
82114 0.000066949 192.168.8.7 192.168.8.128 TCP [TCP Out-Of-Order] 34564→5201 [ACK] Seq=78743182 Ack=1 Win=29312 Len=1448 TSval=409657 TSecr=411321992
82115 0.000071730 192.168.8.128 192.168.8.7 TCP [TCP Dup ACK 82107#4] 5201→34564 [ACK] Seq=1 Ack=79060294 Win=677760 Len=0 TSval=411321995 TSecr=409657 SLE=78743182 SRE=78744630
192.168.8.128 is the receiver
192.168.8.128 is the sender
direct connection without any switch
TCP is used
I put a time ref at packet 82107 so you can see more easily the negative relative timestamp of some following packets.
> Maybe this could be named a 'general regression' then. And when this is
> fixed our problem hopefully gets fixed too ;-)
I guess the network guys will also say: Use NAPI. IMHO there shouldn't be an API which allows OOO in the first place.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
prev parent reply other threads:[~2016-11-30 7:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 15:49 wrong CAN frame order in network layer due to SMP? Alexander Stein
2016-11-25 11:46 ` Oliver Hartkopp
2016-11-28 9:01 ` Alexander Stein
2016-11-28 20:36 ` Oliver Hartkopp
2016-11-29 10:30 ` Alexander Stein
2016-11-29 19:48 ` Oliver Hartkopp
2016-11-30 7:23 ` Alexander Stein [this message]
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=2577568.MH2UfL0Ils@ws-stein \
--to=alexander.stein@systec-electronic.com \
--cc=daniel.krueger@systec-electronic.com \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).